<!-- See https://libvirt.org/bugs.html#quality for guidance --> ## Software environment - Operating system: Debian testing - Architecture: x86_64 - kernel version: 5.10.0-3-amd64 - libvirt version: 7.0.0 - Hypervisor and version: QEMU 5.2.0 ## Description of problem QEMU is unable to launch guests that have guests using "volume" type disks, when the volume is in an LVM-backed pool. This issue is caused by libvirt not writing a line in the guests' apparmor profile to whitelist the underlying device. However, it does not suffer from this problem with disks of type "block" that use the path directly. ## Steps to reproduce 1. Create a pool backed by an LVM VG. 2. Create a volume. 3. Create a guest with a disk of type "volume" that uses the volume and pool just created. 4. Permissions problem encountered. ## Additional information Example disk XML for a non working guest (QEMU fails with permissions problems): ```XML <disk type="volume" device="disk"> <driver name="qemu" type="raw" cache="none" io="native"/> <source pool="zeta-vg" volume="debian-test-01"/> <target dev="vda" bus="virtio"/> </disk> ``` Equivalent XML using the underlying block device: ```XML <disk type="block" device="disk"> <driver name="qemu" type="raw" cache="none" io="native"/> <source dev="/dev/zeta-vg/debian-test-01"/> <target dev="vda" bus="virtio"/> </disk> ``` The generated `/etc/apparmor.d/libvirt/libvirt-<uuid>.files` AppArmor profile from the non-working guest (using the "volume" type disk): ``` # DO NOT EDIT THIS FILE DIRECTLY. IT IS MANAGED BY LIBVIRT. "/var/log/libvirt/**/debian-test-01.log" w, "/var/lib/libvirt/qemu/domain-debian-test-01/monitor.sock" rw, "/var/lib/libvirt/qemu/domain-1-debian-test-01/*" rw, "/run/libvirt/**/debian-test-01.pid" rwk, "/run/libvirt/**/*.tunnelmigrate.dest.debian-test-01" rw, "/dev/vhost-net" rw, "/var/lib/libvirt/qemu/domain-1-debian-test-01/{,**}" rwk, "/var/lib/libvirt/qemu/channel/target/domain-1-debian-test-01/{,**}" rwk, "/var/lib/libvirt/qemu/domain-1-debian-test-01/master-key.aes" rwk, "/dev/net/tun" rwk, ``` The generated `/etc/apparmor.d/libvirt/libvirt-<uuid>.files` AppArmor profile from the working guest (using the "block" type disk): ``` # DO NOT EDIT THIS FILE DIRECTLY. IT IS MANAGED BY LIBVIRT. "/var/log/libvirt/**/debian-test-01.log" w, "/var/lib/libvirt/qemu/domain-debian-test-01/monitor.sock" rw, "/var/lib/libvirt/qemu/domain-1-debian-test-01/*" rw, "/run/libvirt/**/debian-test-01.pid" rwk, "/run/libvirt/**/*.tunnelmigrate.dest.debian-test-01" rw, "/dev/dm-2" rwk, "/dev/vhost-net" rw, "/var/lib/libvirt/qemu/domain-1-debian-test-01/{,**}" rwk, "/var/lib/libvirt/qemu/channel/target/domain-5-debian-test-01/{,**}" rwk, "/var/lib/libvirt/qemu/domain-1-debian-test-01/master-key.aes" rwk, "/dev/net/tun" rwk, ``` Note the lack of `/dev/dm-2` in the first one. <!-- The line below ensures that proper tags are added to the issue. -- >