On 02/13/2018 05:43 PM, 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.
This patchset looks quite similar I have initiated in 2015
Current agreement on the topic from migration and block layer
maintainers is that for QAPI we should have the following:
1. savevm and load VM commands should accept block device to
store VM state.
2. saveVM and load VM should be made asynchronous to avoid
huge downtime during memory and state storing
The design should take (1) and (2) into the account. Right now
Denis Plotnikov is working (internally) on (2).