Re: [Qemu-devel] [PATCH] [RFC] savevm only saves disk state

[Kevin Wolf <kwolf@redhat.com>]

Am 15.09.2010 20:24, schrieb edison:
> On Thu, Sep 9, 2010 at 7:08 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
>> On 09/09/2010 08:43 PM, disheng.su@gmail.com wrote:
>>>
>>> From: edison<edison@cloud.com>
>>>
>>> Add a new option when "savevm": savevm -n snapshotName, which only takes
>>> snapshot on disk, but doesn't save vm state(memory,cpu,devices...).
>>> Saving vm state on QCOW2 disk will take a long time, per my test, it will
>>> take 1~2 minutes to "savevm" on VM with 1G memory. Even worse, the VM is
>>> wholely stopped at that time, makes "savevm" not that useful.
>>> All we know the side effect of it:) but does it make sense to give user
>>> the choice?
>>>
>>
>> I think it would be better to explore ways to make savevm live.  A round
>> about option would be to combine a disk-only snapshot with a live migration
>> to disk and somehow allow qcow2 to refer to an external memory snapshot.
>>
> 
> My point is we still need an interface to take online snapshot for
> disk-only(flush pending I/O, take QCOW2 snapshot, no savevm, no live
> migration), which is the fastest , lowest down time and easy to
> manage.
> Look like VMware supports such kind of operation: take a snapshot
> without saving memory(http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1015180).
> 
> Of cause, it's better to cooperate with pv driver, or tools inside
> guest, which can hold I/O, flush disk cache, etc. If without such
> co-operation, the bare disk snapshot is just like saving the disk
> state when loosing power, not that bad, right?

I agree that disk-only snapshots probably have their place. We already
create them with qemu-img snapshot -c, so I think it would be
appropriate to expose the option in the monitor, too.

>> A better alternative would be a live snapshot within qcow2.  I think Kevin
>> has some good ideas about how to do this with qcow2 today but provided we
>> had a nice interface to do this, the changes to the live migration code
>> should be fairly straight forward.
> 
> Hi Kevin, any idea about it? Live snapshot is very useful. Do you
> already have ideas/plans about it? I want to take a look at it, make
> it live!

I haven't taken a very close look at this yet, but in theory it should
be really straightforward.

The one thing you need to know is how VM state is saved in qcow2: It is
stored just like the normal data on the virtual disk, but at offsets
greater than the virtual size of the disk, so that guests don't see it.
For example if you have an 8 GB image (virtual size), the VM state might
start at 10 GB.

Currently when you do a savevm, we save the state of all these devices
to the VM state area (using bdrv_save_vmstate()) and then take a disk
snapshot (which magically includes the VM state, because it's just some
data on the disk).

So when making snapshots live, what you need to do is basically a live
migration into this part of the virtual disk (should be very similar to
migrating into an external file, which is possible today). Once the VM
state is saved to the virtual disk, you can take the good old disk
snapshot and you're done.

Kevin