please add support for configuring ovmf via use of qemu -L option

Bug #1074207 reported by Steve Langasek on 2012-11-02
This bug affects 2 people
Affects Status Importance Assigned to Milestone
libvirt (Ubuntu)
qemu (Ubuntu)
virt-manager (Ubuntu)

Bug Description

libvirt supports passing additional arguments to qemu using the following syntax:

<domain type='kvm' xmlns:qemu=''>
    <qemu:arg value='-L'/>
    <qemu:arg value='/usr/share/ovmf'/>

We will soon have a package in raring that provides ovmf (the secureboot-capable UEFI firmware implementation for qemu) at the above path. Please add support for configuring this via virt-manager.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: virt-manager 0.9.3-1ubuntu2
ProcVersionSignature: Ubuntu 3.5.0-18.29~fanspeed2-generic 3.5.7
Uname: Linux 3.5.0-18-generic x86_64
ApportVersion: 2.6.1-0ubuntu6
Architecture: amd64
Date: Fri Nov 2 01:59:35 2012
InstallationDate: Installed on 2010-09-24 (769 days ago)
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
MarkForUpload: True
PackageArchitecture: all
SourcePackage: virt-manager
UpgradeStatus: Upgraded to quantal on 2012-06-11 (143 days ago)

Steve Langasek (vorlon) wrote :
Changed in virt-manager (Ubuntu):
importance: Undecided → Wishlist
Marc Deslauriers (mdeslaur) wrote :

The -L option probably wouldn't be appropriate because it will also change the default path for the VGA bios and keymaps.

Would the -bios option work for this firmware? If so, I believe libvirt already supports settings this via <loader> in <os>, in which case adding it to virt-manager would be a lot more elegant than attempting to bypass libvirt.

Changed in virt-manager (Ubuntu):
status: New → Incomplete
Steve Langasek (vorlon) wrote :

OVMF includes its own implementation of the VGA BIOS which must be used together with the BIOS image. So the override of the VGA BIOS path is quite deliberate; there doesn't seem to be a way to point at an arbitrary VGA BIOS file with libvirt. The override of the keymaps path is less deliberate, but would be addressed by a symlink in the ovmf package.

Changed in virt-manager (Ubuntu):
status: Incomplete → New
Steve Langasek (vorlon) wrote :

15:19 < mdeslaur> the ovmf package could ship the qemu-system-x86_64-uefi and qemu-system-i386-uefi scripts, which
                  would just be a shell file that adds the appropriate option for the alternate directory
15:20 < mdeslaur> and a trivial distro patch could be added to libvirt to gain knowledge of those two new archs
15:20 < mdeslaur> it's also hackish, but that's where I'm at now

That seems to make the most sense, given that virt-manager can't sanely poke these qemu settings down into libvirt.

Laszlo Ersek (lacos-caesar) wrote :

(1) Re #3:

OVMF.fd includes OvmfVideo.rom starting with SVN rev 13520. A single -bios option suffices.

(2) Re Bug Description:

Can you please tell me more about the package to be shipped in Raring Ringtail? Is it available somewhere online (work in progress or otherwise)? I'm especially interested in how you're going to handle the non-free license of the FAT driver (FatPkg / FatBinPkg). Will you put OVMF in Restricted or Multiverse?


Jamie Strandboge (jdstrand) wrote :

Probably goes without saying, but libvirt will need to be updated such that /etc/apparmor.d/abstractions/libvirt-qemu will need to have the following line:
/usr/share/ovmf/** r,

Marc Deslauriers (mdeslaur) wrote :

Since it will now be a single firmware file, I will probably use the -bios option via <os><loader>, so the ovmf firmware will need to go in the same directory as the other qemu firmware.

Changed in libvirt (Ubuntu):
importance: Undecided → Wishlist
status: New → Confirmed
Jamie Strandboge (jdstrand) wrote :

libvirt's virt-aa-helper valid_path() will also need to be updated. If the OVMF.Fd (aka bios.bin) is in /usr/share, then specifying '<os><loader>/usr/share/<wherever>/bios.bin</loader></os>' causes virt-aa-helper to fail because files in /usr/share are currently considered restricted. This can be fixed by adding "/usr/share/<wherever>" to "override[]" in valid_path().

Jamie Strandboge (jdstrand) wrote :

FYI, I compiled my own OVMF.Fd ( To use immediately, do something like:
$ mkdir ~/vms/ovmf
$ cp bios.bin ~/vms/ovmf

Adjust /etc/apparmor.d/abstractions/libvirt-qemu to have:
  # until libvirt is patched
  @{HOME}/vms/ovmf/** r,

Then use in libvirt xml something like:
    <type arch='x86_64' machine='pc-1.2'>hvm</type>

I tested this with the VM using the cirrus driver to get to the EFI shell:
      <model type='cirrus' vram='9216' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>

On Fri, Nov 16, 2012 at 01:46:30PM -0000, Marc Deslauriers wrote:
> Since it will now be a single firmware file, I will probably use the
> -bios option via <os><loader>, so the ovmf firmware will need to go in
> the same directory as the other qemu firmware.

The other qemu firmware is all located in different directories
(/usr/share/vgabios, /usr/share/seabios) and symlinked into /usr/share/qemu.
So the apparmor change will still be needed.

Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
<email address hidden> <email address hidden>

Marc Deslauriers (mdeslaur) wrote :

OK, I've uploaded an ugly first stab at adding this to virt-manager in the following PPA:

Make sure the firmware file is called "OVMF.fd" and is in the hypervisor's default firmware directory. For qemu, this would be in /usr/share/qemu.

Creating a new vm should now show a "firmware" option in the advanced section at the end of the wizard, and the details screen should also show which firmware is being used.

Marc Deslauriers (mdeslaur) wrote :

The first stab is a hack, as for it to be done properly: 1- qemu needs to be able to report what firmware it locates and supports, 2- the libvirt qemu driver needs to report that as capabilities, 3- libvirt needs to be able to report loaders as capabilities, 4- virtinst needs to support loader capabilities, 5- virt-manager needs to probe for firmware via capabilities, and display a dynamic list.

Jamie Strandboge (jdstrand) wrote :

Thanks Marc. This works well here. When using UEFI it adds the <loader>OVMF.fd</loader> line to the xml and it doesn't when using the default. Booting with UEFI I see the OVMF.fd firmware screen and without UEFI I do not. Also, the way Marc implemented this, no changes are needed to libvirt.

Small nit: I've only ever seen the OVMF file referred to as "OVMF.Fd" as opposed to "OVMF.fd". This will likely need to change if we end up shipping this file anyway....

Jamie Strandboge (jdstrand) wrote :

Actually, libvirt will likely want to be adjusted too-- Marc used '<loader>OVMF.fd</loader>' which is fine and let's qemu find it and virt-aa-helper happens to think that is ok, cause the path is relative. However, if an absolute path is used (eg '<loader>/usr/share/qemu/OVMF.fd</loader>'), then the guest will not boot for the reasons mentioned in comment #8.

Steve Langasek (vorlon) wrote :

Why would this need to be specified as an absolute path? I think the existing model of passing different video bios types, and linking everything into the common qemu directory, seems applicable.

Jamie Strandboge (jdstrand) wrote :

The path doesn't*need to be specified (as mentioned). What I am saying is that I found a bug that shows there is a problem with virt-aa-helper if you do specify it. This isn't OVMF.Fd specific. Using the <loader> at all with an absolute path will result in a very lowlevel error that is hard to diagnose and therefore should be fixed.

Serge Hallyn (serge-hallyn) wrote :


do you think we should whitelist /**/OVMF.Fd, whitelist /usr/share/qemu/**, or are you suggesting something different (in comments #16 and #8)?

Steve Langasek (vorlon) wrote :

On Fri, Jan 18, 2013 at 10:07:10PM -0000, Serge Hallyn wrote:
> @Jamie,

> do you think we should whitelist /**/OVMF.Fd, whitelist
> /usr/share/qemu/**, or are you suggesting something different (in
> comments #16 and #8)?

At present we have the following in

  # access to firmware's etc
  /usr/share/kvm/** r,
  /usr/share/qemu/** r,
  /usr/share/bochs/** r,
  /usr/share/openbios/** r,
  /usr/share/openhackware/** r,
  /usr/share/proll/** r,
  /usr/share/vgabios/** r,
  /usr/share/seabios/** r,

assuming ovmf is handled consistently to the other bioses, we probably want
'/usr/share/ovmf/** r' added to this list, with a symlink from
/usr/share/ovmf/OVMF.fd to /usr/share/qemu/OVMF.fd.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libvirt - 1.0.1-0ubuntu3

libvirt (1.0.1-0ubuntu3) raring; urgency=low

  * debian/apparmor/libvirt-qemu: add /usr/share/ovmf/** r (LP: #1074207)
 -- Serge Hallyn <email address hidden> Tue, 29 Jan 2013 11:55:19 -0600

Changed in libvirt (Ubuntu):
status: Confirmed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package qemu - 1.3.0+dfsg-1~exp3ubuntu8

qemu (1.3.0+dfsg-1~exp3ubuntu8) raring; urgency=low

  * qemu-system.links:
    - Add link to usr/share/ovmf/OVMF.fd (LP: #1074207)
    - Fix target of /etc/kvm/kvm-if{up,down} links
 -- Serge Hallyn <email address hidden> Tue, 29 Jan 2013 10:52:22 -0600

Changed in qemu (Ubuntu):
status: New → Fix Released
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in virt-manager (Ubuntu):
status: New → Confirmed
Steve Langasek (vorlon) wrote :

edk2/ovmf is now available in raring.

Steve Langasek (vorlon) wrote :

Ping: Marc, I'm still using the ppa build of virt-manager here, are there any remaining blockers in the underlying packages to having this included in raring?

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package virt-manager - 0.9.4-2ubuntu3

virt-manager (0.9.4-2ubuntu3) raring; urgency=low

  * debian/patches/uefi_support.patch: ugly hack to add a UEFI firmware
    option. (LP: #1074207)
 -- Marc Deslauriers <email address hidden> Tue, 05 Mar 2013 17:43:17 -0500

Changed in virt-manager (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers