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.
