[libvirt] [PATCH] qemu: don't refuse to undefine a guest with NVRAM file

[Daniel P. Berrange]

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 :|