[PATCH 0/1] [PATCH] device-types/blk/description.tex: Allow longer device IDs to be returned

["Richard W.M. Jones" <rjones@redhat.com>]

This is a draft proposal to allow virtio-blk devices to have longer
device ID strings (aka serial numbers).

On Linux the serial number of a disk appears under
/sys/block/vda/serial and is used by udev to generate symlinks in
/dev/disk/by-id/.  The serial should be logically attached to a disk
image, and should not change as the disk moves around, and the
symlinks in /dev/disk/by-id/ should similarly be long lived and
permanently refer to a specific disk.

Currently virtio-blk limits the device ID string to 20 ASCII
characters.  Other buses, especially SCSI-based ones like virtio-scsi
and VMware's pvscsi, support much longer serials.  VMware (pvscsi)
calls the serial number a UUID and encodes it through SCSI VPD 0x83 as
"NAA Registered Extended" using 128 bits which Linux prints as a 32
character UUID (without dashes).  virtio-scsi supports a wider variety
of formats, up to very long serials.

This causes problems when the backing device of a disk is changed from
other types to virtio-blk.  Our specific case is when converting
guests from VMware (using pvscsi) to qemu (using virtio-blk), but a
similar thing would happen when converting between virtio-scsi and
virtio-blk.  In both cases a long serial is truncated to 20 bytes.
This causes /dev/disk/by-id/ paths inside the guest to change, meaning
that configuration files and software expecting these paths to never
change will break.

Another major concern is to prevent existing guests from breaking when
long serials are introduced.  In particular, qemu currently silently
truncates the serial parameter to 20 characters, but higher level
software (libvirt, KubeVirt) passes in the full length serial.  The
danger here is that upgrading the hypervisor + driver in a guest would
cause the longer serial to suddenly be used, breaking the guest.  Or
in another scenario, a guest template that uses the older driver would
see the truncated serial even if a new hypervisor is used, but
upgrading the driver inside the guest later would change to use the
longer serial.

Therefore this patch:

 - Leaves the old request VIRTIO_BLK_T_GET_ID alone.  Old drivers can
   continue to use this.  The existing (truncation) behaviour is
   documented.

 - Introduces a new call VIRTIO_BLK_T_GET_LONG_ID to read the full
   serial, up to 247 bytes long.  This is always NUL-terminated and
   passed through a buffer which is always 248 bytes long.

 - Advises driver writers that they should allow guests to opt in to
   longer serial support, while leaving it up to drivers / guests to
   decide what to do based on their situation.

I have written working qemu and Linux kernel patches that implement this:

https://gitlab.com/rwmjones/qemu/-/commits/2026-virtio-blk-long-id?ref_type=heads
https://github.com/rwmjones/linux/commits/2026-virtio-blk-long-id/

Rich.

Richard W.M. Jones (1):
  device-types/blk/description.tex: Allow longer device IDs to be
    returned

 device-types/blk/description.tex | 32 +++++++++++++++++++++++++-------
 1 file changed, 25 insertions(+), 7 deletions(-)

-- 
2.55.0