By default, the custom storage volume is added to the instance with the volume name as the [device] name. If you want to use a different device name, you can add it to the command:
Thanks.
It has worked. lxc config device add jam2 vd1 disk source=block2 pool=pl
Now in config, device name is shown as vd1, instead of source name (block2)
devices:
block2:
pool: pl
source: block2
type: disk
which actually doesn’t matter much
because inside VM, it either way identifies as
Disk /dev/sdc: 953.68 MiB, 1000005632 bytes, 1953136 sectors
Disk model: QEMU HARDDISK
Is there no way to disrupt that /dev/sdb /dev/sdc convention, override it by /dev/vdx …?
I try to get a better overview of disk attach.
As snap/user space has added some new restrictions, generally there are two ways, one is by
lxc storage volume attach …
other is from point of view of instance:
lxc config device add INSTANCE DEVNAME disk
Restrictions:
Type Block can not be attached to container
though it was previously possible by device unix-block, using any host’s block device, zvol … through its path /home/dev.img or /dev/zd1 …
Type file system can be attached to containers as well as vm, though path must be defined and as for vm:
lxc config device add jam3 st1 disk source=st1 pool=pl2 path=st1
Error: Failed to start device “st1”: Cannot attach directory while instance is running
So, must stop the vm, attach device and start again? Not very convenient.
Yes VMs don’t currently allow directories be passed through as disks whilst the VM is running.
This is something we may be able to fix in certain circumstances, so please could you open an issue https://github.com/lxc/lxd/issues
I think a separate one would also be valid for supporting adding block volumes to containers.
This could also then be an opportunity to update the docs with the various limitations.
It’s slightly more than that in that we also need to effectively pass a unix-block device for it, but yeah, it’s an easy piece of work which is why it’s currently assigned to a student.