Thursday, September 11, 2014

libvirt now supports OVMF

Thanks to the work of Michal Privoznik and support of Laszlo Ersek and others, libvirt can now manage VMs using OVMF natively.  If you're on Fedora and using Gerd's OVMF RPMs, you simply need to create a copy of /usr/share/edk2.git/ovmf-x64/OVMF-pure-efi.fd for each VM (put it somewhere like /var/lib/libvirt/images/), and make it writable (support is still new and it doesn't seem to change file permissions for the VM yet).  Then, edit the domain XML to include this:

<domain type='kvm'>
  ...
  <os>
    ...
    <loader type='pflash'>/var/lib/libvirt/images/VM1-OVMF.fd</loader>
  </os>
</domain>

Since the OVMF image we're using is a "unified" image, it contains both the UEFI code itself as well as variable storage space, so the above adds it as writable by the VM.  There are also ways to have a split image so you can maintain the UEFI code separate from the variables, but I'll wait for builds from Gerd that support that before I attempt to document it.

With support for both the kvm=off cpu option and OVMF in libvirt, we're now able to run completely native libvirt VMs with GeForce and Radeon GPU assignment.  Support is already underway for virt-manager and virt-install of OVMF.

Also, a VM CPU selection tip, since we don't care about migration with an assigned GPU, there are few reasons left not to want to use the -cpu host option for QEMU.  To enable that through libvirt, change the CPU definition in the XML to this:

<domain type='kvm'>
  ...
  <cpu mode='host-passthrough'/>
  ...
</domain>

Automatic vCPU pinning is also available:

<domain type='kvm'>
  ...
  <cputune>
    <vcpupin vcpu='0' cpuset='0'/>
    <vcpupin vcpu='1' cpuset='1'/>
  </cputune>
  ...
</domain>

And yes, hugepage support is also available, see libvirt documentation for details.  Enjoy.

7 comments:

  1. It also supports the q35 machine type since a few days, according to [1]
    Though my 440FX setup is working so well that I haven't tested it yet.

    Is there any upside to using q35 if it works? The forums really aren't helpful in that regard…

    [1] https://github.com/tianocore/edk2/commit/41f80fbd9905cdc9a457e3cdf8110539f948c6b9

    PS: I hope I'm not spamming you. I hit preview and the comment vanished, so I'm resending it.

    ReplyDelete
    Replies
    1. Awesome, thanks for the tip on OVMF support for Q35!

      When we first started doing VGA assignment there was FUD that Q35 provided a machine model closer to bare metal and should therefore have a better chance of working. In a few isolated cases, that's true. Things like the Linux radeon driver assuming it has a parent device that it can negotiate link parameters with. Mostly though, it's not needed, especially with Windows guests IME. Even with OVMF support, it still has some downsides. AHCI has been terribly slow, and maybe not 100% stable. libvirt support for Q35 is also still fairly fragile. It doesn't yet seem to have root port support and tries to only allow devices on certain bus types, which seems to preclude the exact reason we want to use Q35.

      If 440FX works for you, it's probably the better option right now.

      [I only got one notice of your comment, no spamming]

      Delete
  2. Hey Alex,

    Can you correct the error on the host-passthrough section there should be a ' at the end of host-passthrough.

    I've been able to boot my Windows8 Guest up using the native OVMF and can ping it, just unable to check if the VGA passthrough with my AMD R9 290 is working as I'm doing it remotely.

    I have also managed to boot it up using a q35 machine type with OVMF, Windows8 is pinging again can't check VGA passthrough but will do later.

    ReplyDelete
    Replies
    1. Thanks, fixed. I hope it ends up working and good to hear about q35+OVMF. I intend to give that a try this week, but expect that the libvirt support for 440fx is still going to make that be the preferred machine type for me.

      Delete
    2. Also, I recommend setting up TightVNC on your GPU VMs so you can fiddle with them without necessarily sitting in front of the monitor.

      Delete
  3. late, but, what is the difference betwheen 440fx-2.4 and 2.3, 2.2, etc???

    what is the best for a motherboard with Intel 5520 chipset? (evga SR-2)

    BTW- great blog!

    greetings

    ReplyDelete
    Replies
    1. The chipset versions correspond to the QEMU release and are for migration compatibility.

      5520 is old, I have no suggestions.

      Delete

Comments are not a support forum. For help with problems, please try the vfio-users mailing list (https://www.redhat.com/mailman/listinfo/vfio-users)