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

[Laszlo Ersek]

On 08/22/14 12:24, Daniel P. Berrange wrote:
> On Fri, Aug 22, 2014 at 12:12:52PM +0200, Laszlo Ersek wrote:
>> 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.
> 
> Having a default map in libvirt and in qemu.conf is still acceptable
> for the common case. I just want to make sure that if the user wants
> to provide a non-default BIOS in <loader> they can still get the NVRAM
> automatically created from a template, without having to edit qemu.conf
> and restart libvirtd.

Michal, can you please incorporate this? I guess the priorities would be:
- if <nvram> has text contents, just use that. (same as now)
- else, if <nvram> has @template, copy from there. (new)
- otherwise, consult the map. (same as now)

Thanks,
Laszlo