[libvirt] [PATCH 2/3] snapshot: add atomic create flag

[Peter Krempa]

On 03/16/2012 11:05 PM, Eric Blake wrote:
> Right now, it is appallingly easy to cause qemu disk snapshots
> to alter a domain then fail; for example, by requesting a two-disk
> snapshot where the second disk name resides on read-only storage.
> In this failure scenario, libvirt reports failure, but modifies
> the live domain XML in-place to record that the first disk snapshot
> was taken; and places a difficult burden on the management app
> to grab the XML and reparse it to see which disks, if any, were
> altered by the partial snapshot.
>
> This patch adds a new flag where implementations can request that
> the hypervisor make snapshots atomically; either no changes to
> XML occur, or all disks were altered as a group.  If you request
> the flag, you either get outright failure up front, or you take
> advantage of hypervisor abilities to make an atomic snapshot. Of
> course, drivers should prefer the atomic means even without the
> flag explicitly requested.
>
> There's no way to make snapshots 100% bulletproof - even if the
> hypervisor does it perfectly atomic, we could run out of memory
> during the followup tasks of updating our in-memory XML, and report
> a failure.  However, these sorts of catastrophic failures are rare
> and unlikely, and it is still nicer to know that either all
> snapshots happened or none of them, as that is an easier state to
> recover from.
>
> * include/libvirt/libvirt.h.in
> (VIR_DOMAIN_SNAPSHOT_CREATE_ATOMIC): New flag.
> * src/libvirt.c (virDomainSnapshotCreateXML): Document it.
> * tools/virsh.c (cmdSnapshotCreate, cmdSnapshotCreateAs): Expose it.
> * tools/virsh.pod (snapshot-create, snapshot-create-as): Document
> it.
> ---
...
> + * that it is still possible to fail after disks have changed, but only
> + * in the much rarer cases of running out of memory or disk space).
(sometimes it's not that rare (but then you've also got some other 
problems) :D)


ACK,

Peter