Re: luks devices and libvirt
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.