I note that Linstor always puts a given volume at a fixed device node, e.g. /dev/drbd1000. This is a property of the volume-definition itself, so I believe it is persistent and the same across all nodes.
root@node1:~# linstor volume-definition list -p
+---------------------------------------------------------------+
| ResourceName | VolumeNr | VolumeMinor | Size | Gross | State |
|===============================================================|
| my_ssd_res | 0 | 1000 | 1 GiB | | ok |
| res00 | 0 | 1001 | 1 GiB | | ok |
| res00 | 1 | 1002 | 3 GiB | | ok |
+---------------------------------------------------------------+
Given this, I was wondering about using a generic “host block device” driver instead of, or as well as, Linstor integration - so you’d just attach to /dev/drbd1000, say.
Thinks: is this possible already??
root@node1:~# lxc config device add foo test-linstor unix-block source=/dev/drbd1000 path=/dev/sdb
Device test-linstor added to foo
root@node1:~# lxc exec foo bash
root@foo:~# ls -l /dev/sdb
brw-rw---- 1 root root 147, 1000 Feb 13 16:43 /dev/sdb
root@foo:~# blockdev --getsize64 /dev/sdb
1077665792
Well, whaddya know 
I was also able to create a filesystem on /dev/sdb - although in order to mount it I had to set security.privileged=true on the container.
I have not yet tested migration in an lxd cluster.
It still would be the responsibility of the user to ensure that the given block device exists on the target node before migration (by using the CLI to create a Linstor “resource” on that node), and I don’t know if migration is blocked if the remote node doesn’t have that block device. A proper Linstor plugin could take care of all that via the API.
Cheers,
Brian.