[libvirt] [RFC]: Snapshot API v3

[Daniel Veillard]

On Tue, Mar 30, 2010 at 06:13:07PM -0400, Chris Lalancette wrote:
> On 03/30/2010 04:40 PM, Jiri Denemark wrote:
[...]
> > 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.

  Well I think if we documents the 4 different flags with small graphic
examples showing what happen to hierarchies of snapshot on the
operation, I don't see why the users would be confused.
  The only other option to avoid user confusion is to reduce
capabilities drastically, and I don't think we want to go there.

> > 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.

  IMHO uuid allows to name things uniquely when we can't check for
uniqueness at creation (e.g. the domain has been moving around and
we don't have a shared storage for snaphots). That's an edge case
but if using also UUID is cheap I would go for it.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/