On Tue, Feb 24, 2015 at 04:23:41PM +0100, Peter Krempa wrote: > In that case we probably should have negated the logic here and delete > all the stuff by default and give the user option to leave the data > behind. I think that would have been even more unsatisfactory - the semantics of undefine were always just that they just remove the configuration, leaving any other aspect of the VM untouched. Making it delete actual data by default would be a significant semantic change IMHO. > The original motivation is apparently that we should not allow anything > that would represent state of the deleted VM to be transferred > accidentaly to a new VM with same name. For the save image or snapshots > the risk of persisting any data is low as a save image would not > function without it's disk and still be somewhat secure as it would > contain the whole memory image including security. For the NVRAM though > it might uncover data stored there or even make the VM unbootable. > > I agree that the current state is not ideal as we basically force the > user to specify all the necessary flags. I think we can safely avoid > displaying the message in cases when it's not stored in the > libvirt-internal path but for the internal path I'm not convinced that > it would be a great idea to change the default. This is the problem with trying to put this kind of policy into libvirt though. It is targetting one use case, but has forgotten other valid use cases. For example, consider if the NVRAM file or the managed save image were stored in a filesystem that was NFS. The application wishes to undefine the config on one host and define it on another host. Any checks of this kind will always be wrong for some portion of use cases. > We can perhaps add a flag that woult either enable all the "UNDEFINE*" > flags or perhaps invert the logic of them so the user could leave them > behind. IMHO we should just remove this check, and the one for managed save, from the API entirely and leave such error scenario checking to the higher level applications which understand the context of usage in a way that libvirt itself never can. Regards, 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