Re: [libvirt] [PATCH] qemu: don't refuse to undefine a guest with NVRAM file
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 :|