On 07/06/2011 02:59 AM, Nicolas Sebrecht wrote: > The 05/07/11, Eric Blake wrote: > >> I was trying to model this after the virDomainSnapshot API, which has a >> notion of current snapshot, but I guess I don't fully understand what >> that API was implying by current domain snapshot. >> >> After looking more through the code, it looks like the idea was to >> support the notion of a branching hierarchy of snapshots: >> >> A -> B -> D >> \-> C -> E Someone pointed out to me (I'm not sure if it was in this thread) that qcow2 does _not_ by itself maintain any hierarchy - from qemu-img's point of view, all snapshots are equally independent reference-counted copies of data at a moment in time. So the hierarchy present in libvirt's use of virDomainSnapshot* APIs as applied to system checkpoints is a factor of libvirt maintaining extra metadata alongside the qcow2 images. That is, libvirt remembers which checkpoint was most recently created/reverted, and when creating a new checkpoint, assigns the current snapshot as the parent of the new one. > > May I ask what would happen if the user asks for deletion of A (as both > base and snapshot)? Would it be possible? Would it be merged to both B > and C? Using which filename? Libvirt already handles this just fine for live checkpoints (although in my testing yesterday, it look like libvirt forgets to maintain a notion of current snapshot if you used virDomainSnapshotCreateXML while a domain was inactive, making for an incomplete hierarchy). Basically, when deleting a snapshot, you have two options - delete that snapshot and all descendants, or delete just the snapshot and reparent all immediate children. That is, in the above scenario, when deleting B, you can choose whether to end up with: A -> C -> E (B and B's children all deleted) or A -> D \-> C -> E (B deleted, and D reparented to B's parent) Right now, libvirt's handling of checkpoint hierarchy under virDomainSnapshot* API fits in with the qemu 'savevm' usage, which uses only internal qcow2 snapshots. So there are no filenames to merge. You are indeed correct, though, that when deleting snapshots where snapshots involve external files, that it would be nice to have user control over which of the two files gets deleted. But the same principles apply - if E.img has C.img as a backing file, then requesting to delete snapshot C means that either E.img will also need to be deleted, or it will need to be rebased to have its backing-file updated to match the parent of C.img. -- Eric Blake eblake@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list