Re: [libvirt] RFC: API additions for enhanced snapshot support
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(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 619 bytes)