On Wed, Aug 24, 2011 at 09:22:33AM -0600, Eric Blake wrote:
A nice benefit of deleting all snapshots at undefine time is that
you don't have to do any reparenting or subtree identification - since
everything goes, this is an O(n) process, whereas using multiple
virDomainSnapshotDelete calls would be O(n^2) or worse.
* src/qemu/qemu_driver.c (qemuDomainDestroyFlags)
(qemuDomainUndefineFlags): Honor new flags.
---
src/qemu/qemu_driver.c | 51 ++++++++++++++++++++++++++++++++++++++---------
1 files changed, 41 insertions(+), 10 deletions(-)
I'm not entirely sure this is a good idea, for the same reason that we
rejected the patch to add 'UNDEFINE_DISKS' to the virDomainUndefine
call. Particularly when we start storing snapshots in files outside
the main disk image (ie not qcow2 external snapshots), we get into
error reporting problems. Do we just ignore any errors deleting the
snapshots ? How does the app detect this & cleanup. Do we report
the errors, in which case how does the app know how far through the
destroy process we got. These feel like policy decisions to me, and
so for app code to decide.
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|