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

On Tue, Feb 24, 2015 at 04:41:44PM +0100, Peter Krempa wrote: > 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: > > > 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 ... I remember that in the virDomainCreateFlags we have START_FORCE_BOOT which is defined to discard any existing managed save file. Should we either extend that to also discard the NVRAM file, or alternatively add a START_RESET_NVRAM flag as a way to boot with clean BIOS ?