Re: [Qemu-devel] [Qemu-block] [PATCH 1/2] Add save-snapshot, load-snapshot and delete-snapshot to QAPI

[Kevin Wolf <kwolf@redhat.com>]

Am 11.01.2018 um 14:04 hat Daniel P. Berrange geschrieben:
> On Thu, Jan 11, 2018 at 01:46:38PM +0100, Max Reitz wrote:
> > On 2018-01-08 14:52, Eric Blake wrote:
> > > On 01/07/2018 06:23 AM, Richard Palethorpe wrote:
> > >> Add QAPI wrapper functions for the existing snapshot functionality. These
> > >> functions behave the same way as the HMP savevm, loadvm and delvm
> > >> commands. This will allow applications, such as OpenQA, to programmatically
> > >> revert the VM to a previous state with no dependence on HMP or qemu-img.
> > > 
> > > That's already possible; libvirt uses QMP's human-monitor-command to
> > > access these HMP commands programmatically.
> > > 
> > > We've had discussions in the past about what it would take to have
> > > specific QMP commands for these operations; the biggest problem is that
> > > these commands promote the use of internal snapshots, and there are
> > > enough performance and other issues with internal snapshots that we are
> > > not yet ready to commit to a long-term interface for making their use
> > > easier.  At this point, our recommendation is to prefer external snapshots.
> > 
> > We already have QMP commands for internal snapshots, though.  Isn't the
> > biggest issue that savevm takes too much time to be a synchronous QMP
> > command?
> 
> Ultimately savevm/loadvm are using much of the migration code internally,
> but are not exposed as URI schemes. Could we perhaps take advantage of
> the internal common layer and define a migration URI scheme
> 
>    snapshot:<name>
> 
> where '<name>' is the name of the internal snapshot in the qcow2 file.

Let's include a node-name there, please. QEMU automagically deciding
where to store the VM state is one of the major problems of the HMP
interface.

And while we're at it, we can make it more future-proof by allowing to
specify arbitrary options:

    snapshot:node=<node-name>,name=<snapshot-name>

That would allow us to add something like compressed=on|off later.
Actually, compressed VM state sounds pretty nice. Why don't we have this
yet? The qcow2 format already provides everything you need for it.

> 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, you don't want to
waste space by keeping both the old and the current version of the page
content in the file.

Kevin