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

From: Markus Armbruster <armbru@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: rpalethorpe@suse.de, Richard Palethorpe <richiejp@f-m.fm>,
	quintela@redhat.com, qemu-devel@nongnu.org, dgilbert@redhat.com
Subject: Re: [Qemu-devel] [PATCH 1/2] Add save-snapshot, load-snapshot and delete-snapshot to QAPI
Date: Sat, 03 Feb 2018 14:28:51 +0100	[thread overview]
Message-ID: <87po5m2odo.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <cb7ae03d-1249-e772-e7e9-99b777054bb3@redhat.com> (Eric Blake's message of "Wed, 10 Jan 2018 10:48:08 -0600")

Coming to this thread rather late, sorry.

Eric Blake <eblake@redhat.com> writes:

> On 01/10/2018 10:19 AM, Richard Palethorpe wrote:
>> Hello Eric & Peter,
>> 
>> Eric Blake writes:
>> 
>>> 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.
>> 
>> That is what we are currently doing and is an improvement over
>> programatically using HMP, but I wanted to improve upon
>> that. Occasionally saving or loading snapshots fails and it is not clear
>> why.
>
> Straightforward mapping of the existing HMP commands into QMP without
> any thought about the design won't make the errors any clearer. My
> argument is that any QMP design for managing internal snapshots must be
> well-designed, but that since we discourage internal snapshots, no one
> has been actively working on that design.

savevm and loadvm are HMP only precisely because an exact QMP equivalent
wouldn't be a sane interface, and designing a sane QMP interface would
be work.  Things that won't do for QMP include automatic selection of
the block device receiving the VM state, and synchronous operation.

Building blocks might be a better fit for QMP than a one-size-fits-all
savevm command.

Internal and external snapshots have different advantages.  Because
external snapshots are more flexible, they've received a lot more
attention[*] than internal ones.  I wouldn't let friends use internal
snapshots for production.

You're welcome to put in the work to push internal snapshots to parity
with external ones.  Do not underestimate how much work that's going to
be.  External snapshots' head start is years.

[...]

[*] "All the attention" would be a fair first order approximation, I
think.