Problem with a disk device of type 'volume'

13 Aug 2022

      Hi,

I need some help to debug a problem with libvirt and a disk device of 
type 'volume'.

I have a VM failing to start with the following error :
$ virsh -c qemu:///system start server
error :Failed to start domain 'server'
error :internal error: process exited while connecting to monitor: 
2022-08-13T09:26:50.121259Z qemu-system-x86_64: -blockdev 
{"driver":"file","filename":"/mnt/images/debian-11-genericcloud-amd64.qcow2","node-name":"libvirt-3-storage","auto-read-only":true,"discard":"unmap"}: 
Could not open '/mnt/images/debian-11-genericcloud-amd64.qcow2': 
Permission denied

I check the file access permission, but they are correct. I try to set 
everything to 777 or run qemu as root, but the problem persist.
$ ll -d /mnt /mnt/images /mnt/images/*
drwxr-xr-x 9 root         root         4,0K 31 déc.   2021 /mnt
drwxr-xr-x 2 root         root         4,0K 13 août  11:31 /mnt/images
-rw-r--r-- 1 libvirt-qemu libvirt-qemu 242M 13 août  11:31 
/mnt/images/debian-11-genericcloud-amd64.qcow2
-rw-r--r-- 1 libvirt-qemu libvirt-qemu 366K 13 août  11:31 
/mnt/images/server_cloudinit.iso
-rw-r--r-- 1 libvirt-qemu libvirt-qemu 593M 13 août  11:59 
/mnt/images/server_image.qcow2

After a lot of searching and testing, I found out that the disk device 
definition is linked to the source of the problem.
The disk device is defined like this :
<disk type="volume" device="disk">
   <driver name="qemu" type="qcow2"/>
   <source pool="TERRAFORM" volume="server_image.qcow2"/>
   <target dev="vda" bus="virtio"/>
   <address type="pci" domain="0x0000" bus="0x00" slot="0x05" 
function="0x0"/>
</disk>

This image 'server_image.qcow2' use a backing file:
$ qemu-img info /mnt/images/server_image.qcow2  --backing-chain
image: /mnt/stockage_rapide/VMs/terraform/puppetdev_server_image.qcow2
file format: qcow2
virtual size: 6 GiB (6442450944 bytes)
disk size: 475 MiB
cluster_size: 65536
backing file: /mnt/images/debian-11-genericcloud-amd64.qcow2
backing file format: qcow2
Format specific information:
     compat: 0.10
     compression type: zlib
     refcount bits: 16

image: /mnt/images/debian-11-genericcloud-amd64.qcow2
file format: qcow2
virtual size: 2 GiB (2147483648 bytes)
disk size: 242 MiB
cluster_size: 65536
Format specific information:
     compat: 1.1
     compression type: zlib
     lazy refcounts: false
     refcount bits: 16
     corrupt: false
     extended l2: false

And here is the definition of the associated storage pool :
<pool type="dir">
   <name>TERRAFORM</name>
   <uuid>dae00836-db4d-49ba-9d32-1f0278055516</uuid>
   <capacity unit="bytes">155674652672</capacity>
   <allocation unit="bytes">74396299264</allocation>
   <available unit="bytes">81278353408</available>
   <source>
   </source>
   <target>
     <path>/mnt/images</path>
     <permissions>
       <mode>0755</mode>
       <owner>0</owner>
       <group>0</group>
     </permissions>
   </target>
</pool>

If I changed the disk device definition to this (and changing only 
that), the domain start and works fine (no permission problem !).
<disk type="file" device="disk">
   <driver name="qemu" type="qcow2"/>
   <source file="/mnt/images/server_image.qcow2"/>
   <target dev="vda" bus="virtio"/>
   <address type="pci" domain="0x0000" bus="0x00" slot="0x05" 
function="0x0"/>
</disk>

Could you help me find the reason why the domain doesn't work when the 
disk device is of type 'volume' ?
Thanks in advance for your help.

Regards,
Fred

Additional information:
- Running this on Debian 11 with libvirt 8.0.0 (from backports) and qemu 
7.0 (from backports).
- Vanilla configuration of libvirt. I have just added my regular user to 
the libvirt group.
- Problem exists even if AppArmor is disabled.

PS: I want to use a disk device of type 'volume' because this domain is 
created by Terraform using the libvirt provider which use this kind of 
disk since it has some advantages. See the details here : 
https://github.com/dmacvicar/terraform-provider-libvirt/issues/126#issuecomm...

Problem with a disk device of type 'volume'

Frédéric Lespez