qemu fails loading PC BIOS OVMF.fd

[olberger]

vagrant up --provider libvirt fails with

...
==> default: Starting domain.
There was an error talking to Libvirt. The error message is shown
below:

Call to virDomainCreateWithFlags failed: internal error: process exited while connecting to monitor: qemu: could not load PC BIOS '/home/olivier/.vagrant.d/boxes/AntonioMeireles-VAGRANTSLASH-ClearLinux/28810/libvirt/OVMF.fd'

however :

ls -l /home/olivier/.vagrant.d/boxes/AntonioMeireles-VAGRANTSLASH-ClearLinux/28810/libvirt/OVMF.fd
-rw-r--r-- 1 olivier olivier 4194304 avril 19 13:22 /home/olivier/.vagrant.d/boxes/AntonioMeireles-VAGRANTSLASH-ClearLinux/28810/libvirt/OVMF.fd

Also in /var/log/libvirt/qemu/ClearLinux-packer_default.log:

2019-04-19 11:55:00.972+0000: starting up libvirt version: 5.0.0, package: 2 (Guido Günther <agx@sigxcpu.org> Sun, 07 Apr 2019 12:36:21 +0200), qemu version: 3.1.0Debian 1:3.1+dfsg-7, kernel: 4.19.0-4-amd64, hostname: newlatitude
LC_ALL=C \
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
QEMU_AUDIO_DRV=none \
/usr/bin/qemu-system-x86_64 \
-name guest=ClearLinux-packer_default,debug-threads=on \
-S \
-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-19-ClearLinux-packer_de/master-key.aes \
-machine pc-i440fx-3.1,accel=kvm,usb=off,dump-guest-core=off \
-cpu host \
-bios /home/olivier/.vagrant.d/boxes/AntonioMeireles-VAGRANTSLASH-ClearLinux/28810/libvirt/OVMF.fd \
-m 2048 \
-realtime mlock=off \
-smp 2,sockets=2,cores=1,threads=1 \
-uuid fdb50fdb-be12-424f-b8a5-eaa9e2b69799 \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=26,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc \
-no-shutdown \
-boot strict=on \
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 \
-drive file=/var/lib/libvirt/images/ClearLinux-packer_default.img,format=qcow2,if=none,id=drive-virtio-disk0 \
-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \
-netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=29 \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:a0:b7:df,bus=pci.0,addr=0x6 \
-chardev pty,id=charserial0 \
-device isa-serial,chardev=charserial0,id=serial0 \
-chardev socket,id=charchannel0,fd=31,server,nowait \
-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
-vnc 127.0.0.1:0 \
-k en-us \
-device cirrus-vga,id=video0,bus=pci.0,addr=0x2 \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \
-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
-msg timestamp=on
2019-04-19 11:55:00.972+0000: Domain id=19 is tainted: host-cpu
char device redirected to /dev/pts/6 (label charserial0)
qemu: could not load PC BIOS '/home/olivier/.vagrant.d/boxes/AntonioMeireles-VAGRANTSLASH-ClearLinux/28810/libvirt/OVMF.fd'
2019-04-19 11:55:01.102+0000: shutting down, reason=failed

This doesn't seem to be the same issue as reported in #14 since I'm not root... or that's weird...

Thanks in advance.

[olberger]

Being on Debian, I modified the Vagrantfile and setting thi works around the issue:

config.vm.provider :libvirt do |libvirt, override|
    libvirt.loader = '/usr/share/qemu/OVMF.fd'
  end

my guess, qemu won't want to load a BIOS file that's not under '/usr/share/qemu/' ?

Hope this helps,

[AntonioMeireles]

@olberger

Hi! and many, many thanks by raising this!

Albeit i couldn't reproduce your issue it made clear(better late than never) in my mind that there was a severe design issue in my boxes, as there's no point in having them bundle an OVMF.fd when the libvirt/kvm host where they are going to be consumed will have it anyway and when that won't ever work if Vagrant is talking to a remote libvirt host, since the vagrant-libvirt plugin has no machinery to upload from the Vagrant host to the libvirt one the bios blob (it only does that for the boxes themselves).

So, from now on the boxes won't ship a bundled OVMF.fd, on a custom path, and will just expect it to be available on its default, more common, location. I'm building atm a new set of boxes (for 28950) that should be public in the next few hours or so, that will consume this (i'll add a note here when they get available).

Again, many, many thanks and a Happy Easter!

[AntonioMeireles]

@olberger,

28950 boxes are now online. they passed basic smoke testing here and should just work out of the box on your setup, per my previous comment.

Can you confirm, please :-)

Thanks in Advance

António

[olberger]

Seems to be working without the need for the workaround in Vagrantfile. Thx