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

Tue Sep 16 11:17:42 UTC 2014

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 :)

> #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.

> I'd prefer this to not be in the new VM wizard, since I think most people
> won't know what choice to make, so we should take it out of the common path.

I believe that upstream users who want to run *fresh* OVMF will have to
know anyway. The optimal way is to install Gerd's RPMs, and either
reconfig libvirtd accordingly (and then the custom selection can remain
buried), or specify the custom binary & varstore template paths.

> There's also potential problems, like does windows XP install on pure UEFI?

No. ("I very seriously doubt that".) But why is that a problem? The
default selection is SeaBIOS, and to get to that option in the current
version of the patchset, you already have to open an expander called
"Advanced" or some such.

> If there are people out there that want to always default to UEFI maybe we
> could add a global preference for them to set, but that could come later if we
> decide it's needed.
> 
> So, thoughts on that?
> 
> Assuming that's okay, some clarifying questions:
> 
> - What is the optimal config for UEFI? The template based NVRAM? From a
> management perspective that certainly sounds simplest.

Yes, split files (binary & varstore template) are optimal.

The unified OVMF.fd files are a dead-end for management purposes.

> - Will the OVMF package be shipping an NVRAM 'template'?

Yes.

Old OVMF builds exist of course that don't provide the split files, but
virt-manager should expressly ignore those builds. Libvirtd *does*
accommodate them, and so does virt-install, but virt-manager shouldn't.
It would be possible, but it would make the GUI even more complex. The
unified OVMF.fd files (where the file contains a live varstore, and a
basically non-updateable binary) is just a dead-end, management-wise.

> - Would we want a CSM option in that list (or UEFI + BIOS, or some other name)?

You don't want to dedicate a separate option to that on the GUI. The
custom UEFI selection (by pathname) allows the user to run whatever he
likes.

OVMF's build can be influenced by several orthogonal build time
switches, which leads to "combinatorial explosion". CSM vs. no-CSM,
secure-boot vs. no-secure-boot, debug log on serial port vs. debug log
on qemu debug port, old UEFI shell vs. new UEFI shell, Intel PROEFI
e1000 driver built into the firmware vs. not, and so on.

> - Also, further down the line, will we ever use UEFI by default? Maybe for
> certain OS versions? Just something to consider?

Yes, that would be a reasonable feature request, later. Especially if
you restrict OVMF as default choice to some OSes at first.

> - What's the minimum qemu version we should target with this stuff as well? Is
> the pflash stuff new?

It's not easy to say. OVMF doesn't only depend on pflash support, there
are dependencies on the ACPI payload that qemu generates as well. I
recommend to stick with the latest stable qemu release, 2.1.1.

There's no reason for a distro to upgrade virt-manager & libvirtd to
bleeding edge without doing the same with qemu.

> And some minor implementation bits to consider:
> 
> - For existing VMs, we can show the firmware field in VM Details -> Boot as a
> readonly label

I agree, that's a good idea.

> - Make sure to hide the UEFI UI on archs that don't support it

Probably useful, yes.

> - We should also come up with a virt-install convenience option, like '--boot
> uefi' or similar. But of course keep the fine grained options as well.
> 
> - People that need advanced config, like pointing to custom nvram, or custom
> ovmf, we should point them at virt-install and virt-xml.

I disagree (see near the top).

(1) On a distribution that makes fresh OVMF readily available, the
optimal config comes together as follows:

(a) as part of the libvirtd package, /etc/libvirt/qemu.conf is
immediately installed with an nvram stanza that references the
OVMF_CODE.fd and OVMF_VARS.fd files that are installed by the
distribution's own OVMF package.

(b) virt-manager either hardcodes the pathname of the same OVMF_CODE.fd
file (visible in this patchset), or (as you propose) retrieves it from
libvirtd in some way.

(c) The user then picks "system-wide UEFI" (or, in your proposal, it
picks the *only* UEFI option).

(d) virt-manager then generates the following XML:

  <loader readonly='yes' type='pflash'
   >/usr/share/OVMF/OVMF_CODE.fd</loader>

That's it. The OVMF_CODE.fd pathname here will equal that from step (1b).

(e) In response, libvirtd will derive the pathname of the varstore
template (based on qemu.conf / "nvram" in step (1a)), and copy that to a
VM-specific file (== the VM's private varstore instance).

(f) When the distro's own OVMF package is updated, the OVMF_CODE.fd and
OVMF_VARS.fd files are replaced automatically, but the VM keeps its own
private varstore instance.

(2) On a distribution that makes only ancient OVMF available, or none at
all, the optimal config is this:

(a) The user installs Gerd's package.

(b) The user *optionally* bothers to edit /etc/libvirt/qemu.conf so that
the nvram stanza begins with

nvram = [

"/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd:/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd",
  ... further OVMF binaries and their varstore templates ...
  ]

(c) If the user performed step (2b), *and* libvirtd is enhanced to
provide "/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd" from the
above nvram stanza to virt-manager, then the simplest for the user is to
pick the "system-wide UEFI" option (or, according to your suggestion,
the *only* UEFI option).

The XML that virt-manager generates in this case is

  <loader readonly='yes' type='pflash'
   >/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd</loader>

and (1e) will apply.

(d) If the user did not perform step (2b), or he did but libvirt cannot
(yet) return that value to virt-manager, then the easiest way for the
user is to specify those two pathnames manually under the "custom UEFI"
option.

Virt-manager then generates

  <loader readonly='yes' type='pflash'
   >/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd</loader>
  <nvram template='/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd'/>

In response, libvirtd will directly know the pathname of the varstore
template, and copy that to a VM-specific file (== the VM's private
varstore instance).

(e) When Gerd's RPMs are automatically rebuilt and the user runs "yum
update" (or whatever his distro calls that command), then the
/usr/share/edk2.git/ovmf-x64/OVMF_{CODE,VARS}-pure-efi.fd files are
replaced automatically, but the VM preserves its private varstore.

In other words, if you prevent the upstream user from specifying a
custom OVMF binary (and the matching varstore template) in virt-manager,
then you force the user to edit /etc/libvirtd/qemu.conf, *and* you force
libvirtd developers to expose the contents of "nvram" in qemu.conf to
virt-manager in some dynamic way.

> In fact if developers
> want to switch back and forth between different uefi configurations, virt-xml
> is far more optimal then poking around in virt-manager UI anyways.

I agree with that, but it's not about developers.

Consider a minimal howto for users that want to create a *fresh* OVMF
virtual machine. It goes like this (with this version of the patchset):

(1) Install Gerd's repo:

  wget -O /etc/yum.repos.d/kraxel-firmware.repo \
    https://www.kraxel.org/repos/firmware.repo

(2) Install OVMF:

  yum install edk2.git-ovmf-x64

(3) Start virt-manager, and proceed with VM creation as you normally do
until Step 5.

(4) In step 5:
  - open Advanced options
  - select Firmware Type as "Custom UEFI"
  - enter the following values:
    UEFI binary:
      /usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd
    UEFI varstore template:
      /usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd
  - click Finish; you're done

According to you suggestion, it would say:

(1) same
(2) same

(3) edit /etc/libvirt/qemu.conf:

  nvram = [

"/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd:/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd"
]

(4) restart libvirtd

(5) Make sure you have a libvirtd version running that can expose the
contents of "nvram" in /etc/libvirt/qemu.conf to virt-manager dynamically

(6) Start virt-manager, and proceed with VM creation as you normally do
until Step 5. [unchanged]

(7) In step 5:
  - open Advanced options
  - select Firmware Type as "UEFI"

Step 7 would be easier, but steps 3, 4 and 5 are harder.

Thanks,
Laszlo