[libvirt] [PATCH v4 3/3] qemu: Automatically create NVRAM store

[Daniel P. Berrange]

On Fri, Aug 22, 2014 at 11:38:06AM +0200, Laszlo Ersek wrote:
> On 08/22/14 10:54, Daniel P. Berrange wrote:
> > On Fri, Aug 22, 2014 at 10:27:29AM +0200, Laszlo Ersek wrote:
> >> On 08/21/14 11:05, Daniel P. Berrange wrote:
> >>> So the user has the ability to specify a arbitrary BIOS in the XML,
> >>> but unless it matches one of the ones listed in the libvirt config
> >>> they aren't going to be able to start the guest. What can we do
> >>> about this, as it doesn't really seem like a great position to be
> >>> in.
> >>
> >> I disagree. Users who use virt-manager (for which patches still have to
> >> be written, to expose this feature) won't put arbitrary strings in the
> >> <loader> element; virt-manager should offer a minimal choice between
> >> "BIOS" vs. "UEFI".
> >>
> >> Users who are hard-core enough to hack the domain XML by hand are
> >> expected to provide good values.
> > 
> > The problem I'm raising is that it is *not* sufficient to merely
> > provide good values in the XML here. You can't simply deploy a
> > custom OVMF file and update your XML, because this code is relying
> > on values in the libvirtd.conf configuration file.
> 
> If the domain XML spells out both <loader> and <nvram>, then both should
> be updated manually by the user (if the VM's old nvram is not compatible
> with the new loader). This would include the user either instantiating
> the new varstore for the VM, or removing the <nvram> element (so that
> the new default template can take effect).
>
> If the domain XML doesn't spell out <nvram> (either genuinely, or
> because the user removed that element, see above), then yes, you need to
> edit /etc/libvirt/qemu.conf.
>
> I don't see a problem with that. You won't keep installing OVMF_CODE.fd
> files in random locations in the host filesystem. You might be
> developing OVMF and install various ad-hoc builds, but those would go to
> the same location (same pathname), hence it would have to be added only
> once to the qemu.conf file.

Well I do see a problem with editing qemu.conf for this, particularly
when there is a very straightforward way to avoid that need which I
have outlined here. It is crazy to force these extra hoops onto people

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