On Sun, Jul 28, 2024 at 17:31:46 +0200, Marc Haber wrote:

Hi,

this is an ongoing issue. I don't know whether I ever have addresses this here, but it's still annoying.

I am using debian unstable, libvirt 10.5.0, virt-manager 4.1.0, qemu 9.0.2. I work through virt-manager, rarely I use virsh.

I regularly configure virtual disks that are located on a luks-encrypted LVM volume. when unlocked, the block devices appears as /dev/mapper/foo and is a symlink to a ../dm-xx node with xx being a random number, ../dm-xx being a regular block device.

To facilitate this, I have defined a storage pool with this XML:

<pool type="dir"> <name>mapper</name> <uuid></uuid> <capacity unit="bytes">24598757376</capacity> <allocation unit="bytes">0</allocation> <available unit="bytes">24598757376</available> <source> </source> <target> <path>/dev/mapper</path> <permissions> <mode>0755</mode> <owner>0</owner> <group>0</group> </permissions> </target> </pool>

This is necessary as the storage type "LVM volume group" now insists on a volume group name, and the DM mappings created by LUKS dont have a volume group name.

So looking at such configuration, when I dump a volume XML of a volume I get: $ virsh vol-dumpxml --pool mapperdir angien-root <volume type='file'> <name>angien-root</name> <key>/dev/mapper/angien-root</key> <capacity unit='bytes'>118111600640</capacity> [...] As you can see the volume type is 'file' instead of what you'd normally expect ('block).

When I add a disk to a VM from this storage pool, it generates the XML:

<disk type="file" device="disk"> <driver name="qemu" type="raw"/> <source file="/dev/mapper/wintest"/> <target dev="vda" bus="virtio"/> <address type="pci" domain="0x0000" bus="0x05" slot="0x00" function="0x0"/> </disk>

Based on the above that is most likely expected as it's reported as 'file'.

qemu won't start with this settings:

error: Failed to start domain 'win11test' error: internal error: QEMU unexpectedly closed the monitor (vm='win11test'): 2024-07-28T15:20:25.250387Z qemu-system-x86_64: -blockdev {"driver":"file","filename":"/dev/mapper/wintest","node-name":"libvirt-1-storage","read-only":false}: 'file' driver requires '/dev/mapper/wintest' to be a regular file

Changing the XML to

<disk type="block" device="disk"> <driver name="qemu" type="raw"/> <source dev="/dev/mapper/wintest"/> <target dev="vda" bus="virtio"/> <address type="pci" domain="0x0000" bus="0x05" slot="0x00" function="0x0"/> </disk>

(note type="block" and "source dev")

makes the VM work.

Yup, block devices must use the appropriate type.

Can virt-manager somehow be coaxed into generating XML that works here?

I didn't look into virt-manager code, but I can see that the libvirt type returned in such pool type is wrong, so it can't really make a better decision.

If not, is this a virt-manager issue

It looks like a libvirt issue for now, or a combination. Feel free to open appropriate issues in the upstream tracker.

or should qemu just accept type="file" and "source file")?

No. You must use the proper type here.