Am 01.03.2013 um 03:35 hat Wenchao Xia geschrieben: > δΊ 2013-2-28 18:50, Kevin Wolf ει: > >Am 28.02.2013 um 09:09 hat Wenchao Xia geschrieben: > >>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 > Yes, an API to initialize the data at the beginning, or just write 4K > zero in the progress.... > > >actually be a bug fix, because snapshots might today get references to > >unused VM state clusters that are just leftovers from the last snapshot. > > > In a qcow2 file that have snapA, if user type "savevm snapA", then > qemu will delete old snapA and then create new snapA. > Do you mean that new snapA and old snapA may use the same cluster > that is not cleaned up as zeros? I guess this brings no trouble to old > stream savevm, but will brings trouble to plane savevm in this patch. > If so, I think yes this bug fix can solve the problem.
The scenario I'm thinking of is something like: 1. (qemu) savevm A 2. (qemu) quit 3. qemu-img snapshot -c B test.qcow2 4. qemu-img snapshot -d A test.qcow2 Step 1 creates a snapshot from a running VM, so it writes a lot of VM state data to the image. Step 3 creates another snapshot, however outside of a running qemu, so without VM state. It wrongly gets a reference to all VM state clusters of A, which haven't been overwritten or discarded since snapshot A was taken. When deleting A in step 4, the clusters cannot be freed because they are still referenced by B (which doesn't need them at all) Kevin