VMs can't handle disks with names longer than 27 bytes

[hamistao]

Required information

• Distribution: Ubuntu
• Distribution version: 22.04
• snap: latest/edge
• LXC version: 5.21.1 LTS
• LXD version: 5.21.1 LTS

Issue description

When adding a disk with a long name(longer than 27 bytes) to a running VM, it fails with Error: Failed to start device "device-with-long-name-to-produce-error": Failed to add the virtiofs device: tag property must be 36 bytes or less. This happens when attaching filesystem volumes or adding a drive directory share, but not with block devices. That happens because the tag property that is passed over to qemu can't have more than 36 bytes. This property is being created by appending the device name to lxd_, as seen here. Adding a device to a stopped VM doesn't result in the same error but it fail to start and qemu-system-x86_64:/var/snap/lxd/common/lxd/logs/test-vm/qemu.conf:267: tag property must be 36 bytes or less will be shown in qemu.log.
There are many way to handle this, my suggestion for what should be done is changing the logic for creating the tag property since limiting the device name to 32 bytes is too restrictive. This could be done through a hash(or partial hash) of the device name (eg. using a SHA1 hash encoded in base64 as lxd_ENCODED_NAME_HASH would satisfy the lenght limit).

Steps to reproduce

1. mkdir -p $HOME/shared_fs
2. lxc launch ubuntu:22.04 test-vm --vm
3. lxc config device add test-vm device-with-long-name-to-produce-error disk source=$HOME/shared_fs path=/mnt/test-disk

[simondeziel]

... There are many way to handle this, my suggestion for what should be done is changing the logic for creating the tag property since limiting the device name to 32 bytes is too restrictive. This could be done through a hash(or partial hash) of the device name (eg. using a SHA1 hash encoded in base64 as lxd_ENCODED_NAME_HASH would satisfy the lenght limit).

If you go with a hashed name, please use a trimmed SHA256 just for the sake of avoiding SHA1 for the same reason as provided in #12454. Thanks!

[tomponline]

Take a look at the existing blockNodeName function, it may be of use here.

Also see deviceDetachBlockDevice for where we do additional escaping before (and often instead of) hashing.

We should be careful to ensure that what ever we do here we do not change anything that the VM guest observes about the device as these can be used for device paths inside the guest. If something of a certain length doesn't work today thats OK and we can start to hash it conditionally, but changing things that work today such that they manifest differently inside the guest isn't something we can do.