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

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.