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

[Peter Krempa]

On Tue, Feb 24, 2015 at 15:31:14 +0000, Daniel Berrange wrote:
> 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.

My wording wasn't clear enough. I was thinking that the initial design
should be like this. Changing this is not an option now.

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

The mgmt app has the option to use either non-managed save or store the
NVRAM in a non-default location for example ...

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

Well, okay, but then you should note in the docs that by doing the
undefine without the flags some data in libvirt internal paths may be
left behind and persist into a new VM with the same name.

Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150224/73374496/attachment-0001.sig>