On Tue, Aug 16, 2022 at 13:51:20 +0200, Frédéric Lespez wrote: > Hi, > > I have progressed in my research. > > I created a minimal test case in order to reproduce the problem (see below). > > I made tests on 3 (physical) machines under Debian 11.4: the problem is > present on 2 machines but there is no problem on the third. > > I booted a machine where the problem is present into a Debian 11.4 live OS > and made the test : it works, no problem. > > So far, all my tests lead me to the following conclusions: > - The problem is tied to the configuration of the system. > - It's not 'file permission' problem. The directory structure of the > storage pool, the file permissions on this structure, the configuration of > libvirt and qemu and the user under which the daemon runs are the same on > all systems. > - I have made the test with libvirt 7.0.0 & qemu 1.5.2 and with libvirt > 8.0.0 and qemu 1.7.0 (from Debian 11 backports). The different versions have > the same behavior. > - Apparmor is not the culprit (No error in logs). I have also disabled it > and the behavior is still in the same > > I will appreciate any hint about what I should check to find the difference > between the working systems and the failing ones. > > Regards, > Fred > > How to made a test (under root): > > 1/ Install libvirt & qemu if needed > apt install libvirt-daemon-system qemu-system-x86 virtinst > > 2/ Start libvirt daemon if needed > systemctl start libvirtd > > 3/ Create the default pool storage (if it is not created automatically) > virsh pool-define-as default dir - - - - /var/lib/libvirt/images/ > virsh pool-build default > virsh pool-start default > > 5/ Download Debian 11.4 Generic cloud image and put it in the default > storage pool > wget -O /var/lib/libvirt/images/debian.qcow2 https://cloud.debian.org/images/cloud/bullseye/latest/debian-11-genericcloud-amd64.qcow2 > > 6/ Refresh the default storage and check the Debian image is visible. > virsh pool-refresh default > virsh vol-list --pool default > > 7) Start the default network > virsh net-start default > > 8) Create a VM based on the Debian 11.4 Generic cloud image > virt-install -n TESTBUG --disk vol=default/debian.qcow2 --memory 1024 > --import --noreboot --graphics none > > 9/ Start the VM, it should start and work fine > virsh start TESTBUG > > 10/ Stop the VM > virsh shutdown TESTBUG > > 11/ Change the disk definition to switch to the disk type from 'file' to > 'volume' and adapt the 'source' attributes accordingly. > virsh edit --domain TESTBUG > > Change this section: > <disk type="file" device="disk"> > <driver name="qemu" type="qcow2"/> > <source file="/var/lib/libvirt/images/debian.qcow2"/> > <target dev="hda" bus="ide"/> > <address type="drive" controller="0" bus="0" target="0" unit="0"/> > </disk> > > to : > <disk type="volume" device="disk"> > <driver name="qemu" type="qcow2"/> > <source pool="default" volume="debian.qcow2"/> > <target dev="hda" bus="ide"/> > <address type="drive" controller="0" bus="0" target="0" unit="0"/> > </disk> > > 12/ Start the VM again. It will either succeed or fail with the fololwing > error : > error creating libvirt domain: internal error: qemu unexpectedly closed the > monitor: 2022-08-11T16:12:22.987252Z qemu-system-x86_64: -blockdev {"driver":"file","filename":"/var/lib/libvirt/images/debian.qcow2","node-name":"libvirt-3-storage","auto-read-only":true,"discard":"unmap"}: > Could not open '/var/lib/libvirt/images/debian.qcow2': Permission denied Hi, I'm fairly certain that the above is because of Apparmor. Specifically the apparmor labelling code does not translate the pool/volume name to the path to the image, while for other security drivers we use the existing definition and thus do translate it. I'm not familiar enough with apparmor to point you to how to configure logging properly, though. The issue originates from the fact that the apparmor driver uses a helper process to setup the labelling and the helper process itself is not able to access libvirt's storage driver and thus unable to do the translation. I'll try to think about a possibility to pass the path though.
