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

[Laszlo Ersek]

On 08/22/14 11:56, Daniel P. Berrange wrote:
> 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

OK.

But, if you don't provide a default map in some central config file, for
at least the system-wide OVMF installation(s), how do you save people
from the exact same burden (== manual varstore instantiation), when they
try to create a brand new UEFI virtual machine that uses one of the
system-wide OVMF filesets? Libvirt won't know where to copy the varstore
from.

What you outlined is not straightforward at all for this case. Since the
VM is just being created, it has no nvram/@template attribute (because
the domain XML is being composed, it doesn't exist yet).

The v4 patchset addresses the common case and allows the special use
case to remain hard. As far as I understand, your proposal breaks the
common use case (== the main goal of this patchset), namely that users
can just say "I have all the necessary distro packages installed, now
give me a new OVMF VM".

Thanks
Laszlo