tests/storage-volumes-vm: Root volume disk device attachments #366
Conversation
| ! lxc storage volume attach "${poolName}" virtual-machine/v2 v3 || false | ||
|
|
||
| # Deleting the instance will fail while it's root volume is in use | ||
| ! lxc delete v2 || false |
There was a problem hiding this comment.
I am now wondering if you can remove v2's root volume and permanently attach it to v1? I think that's something we want for scenario where we "rescue" files from an unbootable VM.
The test is fine but that question that popped :)
There was a problem hiding this comment.
With this feature, the only meaningful distinction remaining between virtual-machine/container volumes and custom volumes is their lifecycle; that is, tied to instances vs independent. In the absence of that constraint (and any concerns around back-compat 😅 ), I'd advocate to remove the idea of storage volume types all together and just have "storage volumes".
If keeping the root's contents around without the instance is a capability that we want, it might be worth looking at whether creating a custom volume as a copy of an instance/snapshot is possible.
@hamistao any experience with this? |
|
Not particularly, but it is not the first time we have seen udev or other packages mangling with disk devices that LXD manages (canonical/lxd#13701 (comment)) and since it only happens on a specific distro version and not on minimal it is almost certainly a problem of the same nature and probably isn't worth digging too deep into. On |
This should have a check for all corner cases around VM root volume attachments: - security.protection.start allows one other VM to attach the machine's root disk, and can only be removed if the disk is not attached - security.shared allows unchecked attachments of root disks - VM attachments are correctly reported in used_by - hotplug of VM root attachments works (as this is the method reccomended by the docs to avoid UUID/LABEL conflicts) Signed-off-by: Wesley Hershberger <[email protected]>
MggMuggins
force-pushed
the
attach-vm-root-volumes
branch
from
4ea7f64 to
2040505
Compare
|
Thanks @tomponline @hamistao, I agree that this isn't worth chasing. @simondeziel They do pass locally 😉 . It looks like it goes from 5 |
This should have a check for all corner cases around VM root volume attachments (coverage for canonical/lxd#14532):
I ran into an interesting behavior of udev in Noble VMs while testing that slowed this down a bit. In order for udev to create a symlink for
SCSI_IDENT_SERIAL(/dev/disk/by-id/scsi-SQEMU_QEMU_HARDDISK_lxd_virtual--machine-vm5), I had to hotplug the device in anubuntu:24.04VM. Starting the VM from cold didn't create the link, andubuntu-minimal:24.04VMs never created it at all.Without hotplug or in an
ubuntu-minimal:24.04:With hotplug:
I worked around it by using a shorter LXD device name so that the symlink name wouldn't be truncated; not sure if this is worth chasing further.