[virt-tools-list] [virt-manager PATCH RFC 3/4] virt-manager: OVMF support

[Laszlo Ersek]

On 09/16/14 15:51, Michal Privoznik wrote:
> On 16.09.2014 13:17, Laszlo Ersek wrote:
>> On 09/15/14 23:10, Cole Robinson wrote:
>>> On 09/11/2014 12:56 PM, Giuseppe Scrivano wrote:
>>>> Signed-off-by: Giuseppe Scrivano <gscrivan at redhat.com>
>>>> ---
>>>>   ui/create.ui          | 325
>>>> +++++++++++++++++++++++++++++++++++++++++++++++---
>>>>   virtManager/create.py |  59 ++++++++-
>>>>   2 files changed, 369 insertions(+), 15 deletions(-)
>>>
>>> The UI is fine for a 'nuts and bolts' type view but IMO we should
>>> strip away
>>> some of the power while also drastically simplifying the common case.
>>>
>>> I think we should shoot for just adding a simple dropdown with BIOS
>>> and UEFI
>>> options in the VM Details Boot page, and if needed at install time
>>> people have
>>> to go through 'Customize before install'.
>>
>> In general, I'm OK with this, as long as all options are available to
>> the user ultimately, in some view; but it won't be very convenient. See
>> below.
>>
>>> When the user selects UEFI we try to
>>> give them the optimal config.
>>>
>>> To do this the friendly way, we need to hardcode the location for the
>>> UEFI
>>> roms and NVRAM templates. This sucks :) Ideally these would be
>>> treated like
>>> <emulator> and xen <loader> paths, detected and exposed to clients via
>>> capabilities XML. This 1) gives apps a way to see that UEFI is
>>> installed, even
>>> on remote machines, 2) allows us to specify optimal defaults, and 3)
>>> tells us
>>> that libvirt actually supports all the relevant rom/nvram bits for that
>>> hypervisor. Triple whamy! :)
>>
>> I don't know how <emulator> and xen <loader> paths are interrogated, but
>> I guess libvirtd could somehow return the first components of elements
>> in the nvram list, in qemu.conf. That would tell you what OVMF binaries
>> libvirtd has a matching varstore template for, which basically means
>> what OVMF binaries libvirtd knows about. You could consider the first
>> element in that list the "default OVMF choice" on the host.
>>
>> Of course I defer to Michal :)
> 
> I see. Well, in 1.2.7 I've introduced this
> virConnectGetDomainCapabilities() API that for given [qemu binary path,
> architecture, machine type, virt type] (or any subset of those) returns
> what features are supported. Of course, this was due to my hugepages
> work so the majority of things is not implemented yet, however, I think
> this API can be used to determine if UEFI is supported. In fact, I've
> proposed such patch upstream:
> 
> https://www.redhat.com/archives/libvir-list/2014-September/msg01030.html
> 
> Moreover, since there's a way to pass an arbitrary template file from
> which the per-domain NVRAM file is copied, does it make sense to list
> master VARS.fd files known to libvirt? It's held in domain XML, so even
> the template can be per-domain:
> 
> <os>
>   <type arch='x86_64' machine='pc'>hvm</type>
>   <loader readonly='yes' type='pflash'>/my/path/OVMF_CODE.fd</loader>
>   <nvram template='/my/path/OVMF/OVMF_VARS.fd'/>
>   <boot dev='hd'/>
>   <bootmenu enable='yes'/>
> </os>

No, the varstore templates need not be passed to whoever is asking. I
used two different terms in the above: "first component", and "first
element".

The nvram stanza is a list of pairs. Each pair has two components. The
first component of a pair is the firmware binary. The second component
is the matching varstore template.

nvram = [
  "binary_1:varstore_tmpl_1",
  "binary_2:varstore_tmpl_2",
  "binary_3:varstore_tmpl_3" ]

With "return the first components of elements in the nvram list", I
meant returning [ "binary_1", "binary_2", "binary_3" ].

Regarding the "first element", I only entertained that maybe the first
element in the list could be considered "system default" (ie. "binary_1").

NB, I'm not proposing / requesting myself to implement any of this; I
just tried to come up with some details for Cole's idea. Gerd's proposal
for the firmware registry is probably more flexible then, if dynamically
querying libvirtd about specific firmware binaries is deemed necessary.

Personally I'm not convinced that such a feature is necessary.

Thanks
Laszlo