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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list