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@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/