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

[Michal Privoznik]

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>


>
>> #3 there is also important, because we will want to disable the UEFI UI option
>> if qemu/libvirt is too old, or if UEFI roms aren't available on the host
>> machine, and we will want to do it with an informative warning message or
>> tooltip. People will definitely want to try this and we will need to make it
>> as clear as possible when the needed bits are missing, which is going to be
>> common since ex. Fedora isn't even officially shipping OVMF.
>
> The easiest way for upstream users to play with *fresh* OVMF right now
> is to install Gerd's RPMs (and keep updating them)
> <https://www.kraxel.org/repos/>. The RPM you care about most is
> edk2.git-ovmf-x64, and the files in it that you care about most are
>
> /usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd
> /usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd
>
> These are not "standard" pathnames on any distro I know of or can
> imagine, and that's not a coincidence -- these files shouldn't conflict
> with anything anywhere. But, you *do* want to make them easily available
> for users in virt-manager.
>
> One thing you can say is that whoever installs this RPM better modify
> the "nvram" stanza in "/etc/libvirt/qemu.conf", and then libvirt will
> "know" about it, both for the (original) purpose of locating the
> matching varstore template, and for the (proposed) purpose of offering
> it as an option to virt-manager (in the capabilities XML or elsewhere).
>
> The other possibility is a notice for users that they simply navigate
> virt-manager to the "Customize before install" dialog, where they can
> freely provide an OVMF binary and its matching varstore template file.
>
> We have three guidelines / facts here:
> (a) Dan convinced me that users should be able to set these values
> without reconfiguring libvirtd,
> (b) you're saying that OVMF should be easy to use,
> (c) the currently easiest way to use *fresh* OVMF (which you really do
> want to use) is Gerd's RPMs.
>
> These together are telling me that you can't *bury* the custom OVMF
> selection widgets on some obscure dialog. Right now the optimal way for
> upstream users *is* the custom OVMF selection. It might appear as a nuts
> n' bolts view, but right now that provides the most direct route for
> upstream users.
>
>> Granted, with that approach libvirt will have to hardcode OVMF paths to
>> inspect, but that's better for clients, and actually much simpler if other
>> distros package their bits at different locations, they can just patch libvirt
>> and well behaved tools should do the right thing.
>
> Again, the first components of the nvram list elements in qemu.conf
> could double for this purpose (so no patching needed), but, again :),
> DanPB expressily wanted to allow users to work with custom OVMF installs
> without changing system-wide configuration.

Well, you can even configure libvirt so it knows about no OVMF binary 
and use per-domain teplate exclusively.

Michal