[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-block] [PATCH 1/2] Add save-snapshot, load-snaps

From: Denis Plotnikov
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 1/2] Add save-snapshot, load-snapshot and delete-snapshot to QAPI
Date: Tue, 13 Feb 2018 19:14:57 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 13.02.2018 17:43, Kevin Wolf wrote:
Am 13.02.2018 um 15:30 hat Roman Kagan geschrieben:
On Tue, Feb 13, 2018 at 11:50:24AM +0100, Kevin Wolf wrote:
Am 11.01.2018 um 14:04 hat Daniel P. Berrange geschrieben:
Then you could just use the regular migrate QMP commands for loading
and saving snapshots.

Yes, you could. I think for a proper implementation you would want to do
better, though. Live migration provides just a stream, but that's not
really well suited for snapshots. When a RAM page is dirtied, you just
want to overwrite the old version of it in a snapshot [...]

This means the point in time where the guest state is snapshotted is not
when the command is issued, but any unpredictable amount of time later.

I'm not sure this is what a user expects.

I don't think it's necessarily a big problem as long as you set the
expectations right, but good point anyway.

A better approach for the save part appears to be to stop the vcpus,
dump the device state, resume the vcpus, and save the memory contents
in the background, prioritizing the old copies of the pages that

So basically you would let the guest fault whenever it writes to a page
that is not saved yet, and then save it first before you make the page
writable again? Essentially blockdev-backup, except for RAM.

No multiple copies of the same page would have to be saved so the
stream format would be fine.  For the load part the usual inmigrate
should work.

This is true.

I think it will require changes to the qcow2 driver, though. Currently,
you write the VM state into the active layer and then take the disk
snapshot so that the VM state is automatically snapshotted as well.
Afterwards, the VM state is discarded again in the active layer.

If you want to take the snapshot at the point in time when the command
was issued, you first need to create a qcow2 snapshot to save the disk
state, but then continue to write the VM state into that snapshot, even
though it's not the active layer.

In fact I think this would be more elegant than writing the VM state
into the active layer and then discarding it again, but inactive
snapshots haven't been writable so far, so that will require some

I'm sure that Denis has already some thoughts on this, though.
Yes, I stick to the scheme when you write a snapshot as it is now but instead of ram writing I just preallocate the space for ram and save the actual file offsets of the clusters forming the space, then I resume vcpus and write the ram using those cluster offsets with respect to vcpu pagefaults.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]