Comment 27 for bug 1483071

Ran into this bug trying to test running under UEFI.

I was able to get the VM booting (but it dropped into the EFI shell, no quite sure, but possible related to the use of the two files versus the single-combined file). Here's how I reproduced the issue:

On xenial amd64 host,

- sudo add-apt-repository multiverse
- sudo apt install uvtool uvtool-libvirt ovmf
- uvt-simplestreams-libvirt sync --source http://cloud-images.ubuntu.com/daily release=xenial arch=amd64
- uvt-kvm create --memory 1024 --cpu 4 --disk 10 x1 release=xenial arch=amd64
- virsh stop x1
- virsh edit x1
Add inside <os> section:
<os>
  ...
  <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader>
  <nvram template='/usr/share/OVMF/OVMF_VARS.fd'>/var/lib/libvirt/qemu/nvram/x1_VARS.fd</nvram>
  ...
</os>
- virsh start x1
... failed to start x1

This bug suggests to update the aa profile, but as already mentioned, this
complained about loading the profile. This comment here[1] helped me debug
and diagnose the issue. It appears that /usr/share is hardcoded as a no-go
place for libvirt/qemu to read from and hence aa denies access to the files.

I debugged that with:

% virsh dumpxml x1 | sudo /usr/lib/libvirt/virt-aa-helper -c -u libvirt-`virsh domuuid x1` x1
virt-aa-helper: error: /usr/share/OVMF/OVMF_CODE.fd
virt-aa-helper: error: skipped restricted file
virt-aa-helper: error: invalid VM definition

Even adding:

  /usr/share/OVMF/OVMF_CODE.fd r,

to the template didn't help either. The comment from jdstrand made me think this was
hardcoded and couldn't be changed, so decided to relocate the OVMF files to a place where
libvirt and qemu can read them.

sudo cp /usr/share/OVMF/OVMF* /var/lib/uvtool/libvirt/images/

And updated the x1 xml with the correct path to the OVFM files, then re-run the virt-aa-helper:

(funkmetal) libvirt % virsh dumpxml x1 | sudo /usr/lib/libvirt/virt-aa-helper -c -u libvirt-`virsh domuuid x1` x1
(funkmetal) libvirt % cat libvirt-`virsh domuuid x1`.files
# DO NOT EDIT THIS FILE DIRECTLY. IT IS MANAGED BY LIBVIRT.
  "/var/log/libvirt/**/x1.log" w,
  "/var/lib/libvirt/qemu/domain-x1/monitor.sock" rw,
  "/var/run/libvirt/**/x1.pid" rwk,
  "/run/libvirt/**/x1.pid" rwk,
  "/var/run/libvirt/**/*.tunnelmigrate.dest.x1" rw,
  "/run/libvirt/**/*.tunnelmigrate.dest.x1" rw,
  "/var/lib/uvtool/libvirt/images/x1.qcow" rw,
  "/var/lib/uvtool/libvirt/images/x-uvt-b64-Y29tLnVidW50dS5jbG91ZC5kYWlseTpzZXJ2ZXI6MTYuMDQ6YW1kNjQgMjAxNjAxMDU=" r,
  # don't audit writes to readonly files
  deny "/var/lib/uvtool/libvirt/images/x-uvt-b64-Y29tLnVidW50dS5jbG91ZC5kYWlseTpzZXJ2ZXI6MTYuMDQ6YW1kNjQgMjAxNjAxMDU=" w,
  "/var/lib/uvtool/libvirt/images/x1-ds.qcow" rw,
  "/var/lib/uvtool/libvirt/images/OVMF_CODE.fd" r,
  # don't audit writes to readonly files
  deny "/var/lib/uvtool/libvirt/images/OVMF_CODE.fd" w,
  "/var/lib/libvirt/qemu/nvram/x1_VARS.fd" rw,
  /dev/vhost-net rw,
(funkmetal) libvirt % cat libvirt-`virsh domuuid x1`
#
# This profile is for the domain whose UUID matches this file.
#

#include <tunables/global>

profile libvirt-10a7b819-a30e-4155-b61f-4402fc2daed2 {
  #include <abstractions/libvirt-qemu>
  #include <libvirt/libvirt-10a7b819-a30e-4155-b61f-4402fc2daed2.files>

}

1. https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/799997/comments/34