[libvirt] [RFC]: Snapshot API v3

[Matthias Bolte]

2010/3/31 Chris Lalancette <clalance at redhat.com>:
> On 03/30/2010 04:40 PM, Jiri Denemark wrote:
>> Hi.
>>
>> ...
>>> /* NOTE: struct _virDomainSnapshot is a private structure, ala
>>>  * struct _virDomain.
>>>  */
>>> typedef struct _virDomainSnapshot virDomainSnapshot;
>>>
>>> /* Take a snapshot of the current VM state.  Throws an error if
>>>  * the VM is not currently running */
>>> virDomainSnapshotPtr virDomainSnapshotCreateXML(virDomainPtr domain,
>>>                                                 const char *xmlDesc,
>>>                                                 unsigned int flags);
>>
>> This is probably a leftover from previous versions, but... why do we restrict
>> this API only for running VMs?
>
> Oops, yeah, you are right, I just forgot to change the comment.  It now says:
>
> /* Take a snapshot of the current VM state. */
>
>>
>> ...
>>> /* Delete a snapshot - with no flags, the snapshot is not used anymore,
>>>  * but also not removed.  With a MERGE flag, it merges the snapshot into
>>>  * the parent snapshot (or the base image, if there is no parent snapshot).
>>>  * Note that if other snapshots would be discarded because of this
>>>  * MERGE action, this operation will fail.  If that is really what is intended,
>>>  * use MERGE_FORCE.
>>>  *
>>>  * With a DISCARD flag, it deletes the snapshot.  Note that if children snapshots
>>>  * would be discarded because of this delete action, this operation will
>>>  * fail.  If this is really what is intended, use DISCARD_FORCE.
>>>  *
>>>  * MERGE, MERGE_FORCE, DISCARD, and DISCARD_FORCE are mutually-exclusive.
>>>  *
>>>  * Note that this operation can happen when the domain is running or shut
>>>  * down, though this is hypervisor specific */
>>> typedef enum {
>>>     VIR_DOMAIN_SNAPSHOT_DELETE_MERGE,
>>>     VIR_DOMAIN_SNAPSHOT_DELETE_MERGE_FORCE,
>>>     VIR_DOMAIN_SNAPSHOT_DELETE_DISCARD,
>>>     VIR_DOMAIN_SNAPSHOT_DELETE_DISCARD_FORCE,
>>> } virDomainSnapshotDelete;
>>
>> Merging a snapshot into its parent is probably not the best semantics for
>> MERGE flag as hypervisors differ in the way merging is implemented. As you
>
> Yeah, you are right, we can't just declare this.  It's also an open question
> to me what qemu does about merging (though bugs with loadvm/delvm are preventing
> me from testing this at the moment).

And as described in my other response ESX does merge-into-children
too, but I didn't realize this until now. I just used the wrong words
to describe it at first.

So, after I thought about this in detail, I'd like to ask: Is there
something like a merge-into-parent semantic at all?

>> also mention below, VirtualBox merges into all children instead of a parent.
>> We should allow for both cases. However it influences several things. Firstly,
>> it makes MERGE_FORCE unnecessary for child merging, which is not a big deal as
>> it can just be treated in the same way as MERGE. Secondly, it makes a huge
>> difference when deleting a snapshot with no child. In one case it results in
>> changes being merged and in other case it results changes begin dropped.
>>
>> One option is to refine the semantics to something like:
>>
>> - MERGE: merge changes into other snapshot(s) and fail if it would require any
>>   snapshot to be discarded (even the one which was supposed to be merged)
>> - MERGE_FORCE: really merge even discarding other snapshots but fail if the
>>   snapshot itself would actually be discarded
>> - DISCARD: discard the snapshot and fail if other snapshots would be discarded
>> - DISCARD_FORCE: discard, no matter what
>
> The problem with declaring these semantics is that they are somewhat confusing, so
> application developers will probably get them wrong.  On the other hand it does
> allow us to declare a semantic that all 3 hypervisors probably can support,
> unlike the options below.
>
>>
>> Another option would be to introduce several different APIs for merging into
>> children, merging into parent, and discarding. That would allow drivers to
>> implement only supported methods. Even all of them for a very flexible
>> hypervisor.
>
> The problem with this one is that it will be difficult for application writers
> to write a single application that handles all of the hypervisors.  Imagine trying
> to write a GUI around this, and you'll see what I mean.  If we were to add 3 new
> API's like this, we would also probably want to add some data to the capabilities
> XML for the particular hypervisors so you could grey out specific options in a GUI.
>
> On the other hand, it does solve the problem with merging parents vs. children, and
> also diffuses Paolo's concern about the "SnapshotDelete" API sometimes deleting data
> and sometimes modifying the base image.

Again, I think there is nothing like "merging parents vs. children".
The only possibility is merging into children. Or am I totally
confused now?

>>
>> And the third option I see would be distinguishing merge direction using new
>> flags.
>
> This one is like the second option, in that you don't know which particular
> directions a particular hypervisor supports.  You'd still need to add
> capabilities XML for each hypervisor.
>
> I have to say that after thinking about these 3 options, I like the first
> option the best.  While it's slightly confusing, it is a good semantic.  I'll
> update the documentation for this.
>
>>
>> Personally, I like the second option best as it provides the easiest way for
>> application to detect unsupported behavior.
>>
>> ...
>>> Possible issues:
>>> 1)  I don't see a way to support "managed" save/restore and snapshotting with
>>> this API.  I think we'll have to have a separate API for managed save/restore.
>>> 2)  What is the semantic for deleting snapshots from a running domain?
>>> Virtualbox seems to not allow you to manipulate snapshots while the domain is
>>> running.  Qemu does allow this, but it's currently unclear what the exact
>>> semantics are.  VMware seems to allow manipulation of snapshots while the
>>> domain is running.
>>> 3)  Do we need a snapshot UUID?  Virtualbox allows you to have multiple snapshots
>>> with the same name, differentiated by UUID.  Confusingly, they also have a
>>> "FindByName" method that returns the first depth-first search snapshot that matches
>>> a given name.  For qemu, if you specify the same name twice it overwrites the previous
>>> one with the new one.  I don't know what ESX does here.
>>
>> Libvirt uses/generates UUIDs for almost everything (networks, vms, ...) so it
>> might be more consistent to have UUID in snapshot as well.
>
> Yeah, that is true, which is why I'm waffling with it.  In general it seems like superflous
> information, except in the one case of virtualbox duplicate names (ESX doesn't allow
> duplicate names, I don't think, and qemu blows away duplicates).  My inclination is
> to declare the semantics of duplicate names to be undefined, since it doesn't seem
> to be a very useful feature.
>

As said in another response: ESX 4.0 allows duplicate names. It
distinguishes snapshots based on their ID. But this ID was added in
ESX 4.0. I think ESX 3.5 doesn't allow duplicate names.

With ESX 4.0 we could use the ID to derive a read-only UUID from it.
With ESX 3.5 we would need to abuse the name filed of a snapshot on
the ESX side to store a UUID per snapshot.

Matthias