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@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list