Allow specifying qvm-block device by UUID

[andrewdavidwong]

On 2016-08-25 18:06, johnyjukya@[...].org wrote:

Most standard Linux utilities that refer to block devices, allow you to
specify by uuid as well (mount, cryptsetup are two examples).

The documentation for qvm-block is sparse, but probably because it's a
striaght-forward utility.

There's no support in qvm-block to assign a device to a VM by UUID, is there?

Could be handy for some of the automation I'd like to put in place on
firing up the system.

One can always lsblk|grep|sed|cut|whatever in a sh script, and then use
the resulting block device for qvm-block, but it'd be a lot cleaner and
less error-prone if one could say

"qvm-block -a Florp UUID=kasdjflaksjdfaklsdf"
or "qvm-block -a FLorp --uid asdfkasjdlfkajsd"

Just a suggestion. (And for any other qvm-* that refer to block devices,
perhaps.)

Cheers.

JJ

[easydozen]

I'm seeking for a way to a more robust association between removable device and VM.
The following workaround in /usr/lib/qubes/udev-block-add-change seems like the first step:

# prepare own uuid, based on serial and partition numbers
QUUID="`uuidgen -s -n @oid -N "${ID_SERIAL} ${PARTN}"`"
# crop uuid to match regular expression (qubes/ext/block.py)
NAME="${QUUID:(-12)}"
# make a link to the device
ln -sf ${DEVNAME} /dev/${NAME}

qvm-block output:

BACKEND:DEVID DESCRIPTION USED BY
sys-usb:52fd0105f711 DataTraveler_2.0 (/dev/sda1) sys-net (read-only=no, frontend-dev=xvdi)
sys-usb:81ca47a85fd3 DataTraveler_2.0 (/dev/sda)

Is it worth a PR?

[35609902357]

Can this be solved by using /dev/disk/by-uuid/XXXXXXXXXXXX instead of /dev/sdX?

[easydozen]

Can this be solved by using /dev/disk/by-uuid/XXXXXXXXXXXX instead of /dev/sdX?

I introduced my very own cropped version of UUID due to xenstore' path limitations.

[marmarek]

There are two conflicting requirements here:

1. qvm-block requires unique identifiers
2. any identifier based solely on a device properties may not be unique (if you plug two identical devices for example, or one pretending to be the other)

To see it yourself, you can easily do that with loop block devices: simply attach the same file as both /dev/loop0 and /dev/loop1. The same will happen if you have two USB sticks with the same filesystem UUID.

I think a solution here could be to add extra device property - a "stable identifier", that can be used to attach the device, especially with --persistent, but qvm-block (and in fact other qvm-device too - the same applies to qvm-usb) can then enumerate the devices looking for specific stable ID. But also it detect duplicates and handle them somehow (refuse attach? attach first? ask the user?).

[marmarek]

The stable id implementation I'd see like this:

1. define property name and its constraints (allowed characters, length etc), document at https://www.qubes-os.org/doc/admin-api/
2. (backend vm side) calculate the stable id from device and store it besides other device properties: https://github.com/QubesOS/qubes-linux-utils/tree/master/udev
3. (dom0 side): add optional property to the base DeviceInfo class (core-admin/qubes/devices.py), set it where appropriate (core-admin/qubes/ext/block.py, possibly also in app-linux-usb-proxy too)
4. (dom0 side): add attaching by stable id - especially for persistent attach during vm startup, I think that would be device-get:block handler in core-admin/qubes/ext/block.py, but I may be missing something
5. (dom0/GUI domain side): add displaying stable id in qvm-device tool; add option to choose which id to use (based on --persistent?) - core-admin-client repo