Am 28.02.2013 um 09:09 hat Wenchao Xia geschrieben: > This patch added a new way to savevm: save vmstate as plane contents > instead of stream.
So the idea is that when we introduce internal live snapshots, you don't keep old state in the saved VM state, but you just overwrite it, right? Or actually, the same works (could work?) for migration to file as well. You probably get some improvements of the file size when the migration takes a while, depending on how much of the memory actually has to be saved. You might however end up with a lot more small writes instead of some big ones before, which might hurt performance. Do you have any data about the resulting performance and file size? > This version have following limitation: > 1 in patch 3 only dirty page got written, clean page is not touched, so > it will have trouble when savevm to an old internal snapshot, which > will be fixed later if this approach seems OK. Basically you need a bdrv_zero_vmstate(), right? I think this would actually be a bug fix, because snapshots might today get references to unused VM state clusters that are just leftovers from the last snapshot. > 2 in patch 3 it saves contents according to address regardless about > zero pages, so the size of savevm grows. In my test 128MB guest took > about 21M internal snapshot before, and always took 137MB in this way. > > Although it have above issue, but I'd like to sent the RFC first > to see if this is a good way. Next steps will be make savevm lively, > save vmstate to image files. > > About issue 2, it will be OK if we save vmstate to external image files, > such as a qcow2 file, which may handle the duplicated zeros(I guess so). > in internal snapshot case, the qcow2 internal snapshot need to enhanced > to allow store zeros with little space. Yes, we can use the qcow2 zero flag for this. It works on a qcow2 cluster granularity (i.e. 64k by default), which I hope should be sufficient. Kevin
