Am 13.02.2018 um 15:36 hat Daniel P. Berrangé geschrieben: > On Tue, Feb 13, 2018 at 05:30:02PM +0300, Roman Kagan wrote: > > 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. > > > > 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 change. > > 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. > > No, that's policy decision that doesn't matter from QMP pov. If the mgmt > app wants the snapshot to be wrt to the initial time, it can simply > invoke the "stop" QMP command before doing the live migration and > "cont" afterwards.
That would be non-live. I think Roman means a live snapshot that saves the state at the beginning of the operation. Basically the difference between blockdev-backup (state at the beginning) and blockdev-mirror (state at the end), except for a whole VM. Kevin
