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

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

[Richard W.M. Jones]

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

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

[Richard W.M. Jones]

SCSI-based paravirtualized block devices including virtio-scsi and
VMware's pvscsi allow longer device IDs.  This presents an issue when
we change the backing of a disk from one type to another, eg from
pvscsi to virtio-blk, or virtio-scsi to virtio-blk.  The longer device
ID has to be truncated to 20 bytes.  This results in guest visible
changes, notably /dev/disk/by-id/ paths are different, so any
mountpoints or configuration files that use these paths will break.

Therefore extend virtio-blk to allow longer device IDs.  I chose 247
bytes (ASCII chars) as the new limit since it can cope with any SCSI
device serial.  Real serials will be much shorter than this; the aim
is to allow UUIDs to be preserved which would use 32 or 36 ASCII
chars.

We have to be cautious about breaking existing guests where the
hypervisor is currently silently truncating a longer ID to 20 bytes.
I suggest in the specification that virtio-blk device drivers allow a
way to opt in to longer IDs, but this is ultimately up to the guests /
drivers to decide.

Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
---
 device-types/blk/description.tex | 32 +++++++++++++++++++++++++-------
 1 file changed, 25 insertions(+), 7 deletions(-)

diff --git a/device-types/blk/description.tex b/device-types/blk/description.tex
index 3b3a4e7..d42ca21 100644
--- a/device-types/blk/description.tex
+++ b/device-types/blk/description.tex
@@ -457,9 +457,9 @@ \subsection{Device Operation}\label{sec:Device Types / Block Device / Device Ope
 The type of the request is either a read (VIRTIO_BLK_T_IN), a write
 (VIRTIO_BLK_T_OUT), a discard (VIRTIO_BLK_T_DISCARD), a write zeroes
 (VIRTIO_BLK_T_WRITE_ZEROES), a flush (VIRTIO_BLK_T_FLUSH), a get device ID
-string command (VIRTIO_BLK_T_GET_ID), a secure erase
-(VIRTIO_BLK_T_SECURE_ERASE), or a get device lifetime command
-(VIRTIO_BLK_T_GET_LIFETIME).
+string command (VIRTIO_BLK_T_GET_ID or VIRTIO_BLK_T_GET_LONG_ID),
+a secure erase (VIRTIO_BLK_T_SECURE_ERASE), or a get device lifetime
+command (VIRTIO_BLK_T_GET_LIFETIME).
 
 \begin{lstlisting}
 #define VIRTIO_BLK_T_IN           0
@@ -469,7 +469,8 @@ \subsection{Device Operation}\label{sec:Device Types / Block Device / Device Ope
 #define VIRTIO_BLK_T_GET_LIFETIME 10
 #define VIRTIO_BLK_T_DISCARD      11
 #define VIRTIO_BLK_T_WRITE_ZEROES 13
-#define VIRTIO_BLK_T_SECURE_ERASE   14
+#define VIRTIO_BLK_T_SECURE_ERASE 14
+#define VIRTIO_BLK_T_GET_LONG_ID  32
 \end{lstlisting}
 
 The \field{flags} bitfield is ignored by the device unless
@@ -515,9 +516,26 @@ \subsection{Device Operation}\label{sec:Device Types / Block Device / Device Ope
 the device to discard the specified range, provided that following reads return
 zeroes.
 
-VIRTIO_BLK_T_GET_ID requests fetch the device ID string from the device into
-\field{data}.  The device ID string is a NUL-padded ASCII string up to 20 bytes
-long.  If the string is 20 bytes long then there is no NUL terminator.
+VIRTIO_BLK_T_GET_ID or VIRTIO_BLK_T_GET_LONG_ID requests fetch the
+device ID string from the device into \field{data}.  The device ID
+string is an ASCII string which can be up to 247 bytes long.
+
+VIRTIO_BLK_T_GET_ID fetches the first 20 bytes of the device ID
+string.  If the ID is shorter than 20 bytes, then the response is
+padded with NUL bytes so its length is 20 bytes.  (Note that if the ID
+is 20 bytes or longer, this means the response will not be NUL
+terminated.)
+
+VIRTIO_BLK_T_GET_LONG_ID fetches the complete device ID string.  The
+response is always 248 bytes long, padded to this length with NUL
+bytes.  Since the longest permitted device ID string is 247 bytes, the
+response MUST be NUL terminated.
+
+Device drivers MAY choose a mechanism to opt in to longer device IDs,
+to prevent existing guests from breaking when they see a longer
+(non-truncated) device ID.  In this case a guest which has not opted
+in will continue to use VIRTIO_BLK_T_GET_ID and ignore the complete
+ID.
 
 The \field{data} used for VIRTIO_BLK_T_GET_LIFETIME requests is populated
 by the device, and is of the form
-- 
2.55.0

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

[Michael S. Tsirkin]

On Sun, Sep 06, 2026 at 03:54:44PM +0100, Richard W.M. Jones wrote:
> SCSI-based paravirtualized block devices including virtio-scsi and
> VMware's pvscsi allow longer device IDs.  This presents an issue when
> we change the backing of a disk from one type to another, eg from
> pvscsi to virtio-blk, or virtio-scsi to virtio-blk.  The longer device
> ID has to be truncated to 20 bytes.  This results in guest visible
> changes, notably /dev/disk/by-id/ paths are different, so any
> mountpoints or configuration files that use these paths will break.
> 
> Therefore extend virtio-blk to allow longer device IDs.  I chose 247
> bytes (ASCII chars) as the new limit since it can cope with any SCSI
> device serial.  Real serials will be much shorter than this; the aim
> is to allow UUIDs to be preserved which would use 32 or 36 ASCII
> chars.
> 
> We have to be cautious about breaking existing guests where the
> hypervisor is currently silently truncating a longer ID to 20 bytes.
> I suggest in the specification that virtio-blk device drivers allow a
> way to opt in to longer IDs, but this is ultimately up to the guests /
> drivers to decide.
> 
> Signed-off-by: Richard W.M. Jones <rjones@redhat.com>

With 1 patch pls dont use a cover letter next time.
And Pls Cc relevant people)

> ---
>  device-types/blk/description.tex | 32 +++++++++++++++++++++++++-------
>  1 file changed, 25 insertions(+), 7 deletions(-)
> 
> diff --git a/device-types/blk/description.tex b/device-types/blk/description.tex
> index 3b3a4e7..d42ca21 100644
> --- a/device-types/blk/description.tex
> +++ b/device-types/blk/description.tex
> @@ -457,9 +457,9 @@ \subsection{Device Operation}\label{sec:Device Types / Block Device / Device Ope
>  The type of the request is either a read (VIRTIO_BLK_T_IN), a write
>  (VIRTIO_BLK_T_OUT), a discard (VIRTIO_BLK_T_DISCARD), a write zeroes
>  (VIRTIO_BLK_T_WRITE_ZEROES), a flush (VIRTIO_BLK_T_FLUSH), a get device ID
> -string command (VIRTIO_BLK_T_GET_ID), a secure erase
> -(VIRTIO_BLK_T_SECURE_ERASE), or a get device lifetime command
> -(VIRTIO_BLK_T_GET_LIFETIME).
> +string command (VIRTIO_BLK_T_GET_ID or VIRTIO_BLK_T_GET_LONG_ID),
> +a secure erase (VIRTIO_BLK_T_SECURE_ERASE), or a get device lifetime
> +command (VIRTIO_BLK_T_GET_LIFETIME).
>  
>  \begin{lstlisting}
>  #define VIRTIO_BLK_T_IN           0
> @@ -469,7 +469,8 @@ \subsection{Device Operation}\label{sec:Device Types / Block Device / Device Ope
>  #define VIRTIO_BLK_T_GET_LIFETIME 10
>  #define VIRTIO_BLK_T_DISCARD      11
>  #define VIRTIO_BLK_T_WRITE_ZEROES 13
> -#define VIRTIO_BLK_T_SECURE_ERASE   14
> +#define VIRTIO_BLK_T_SECURE_ERASE 14
> +#define VIRTIO_BLK_T_GET_LONG_ID  32


U also want a feature bit otherwise driver does not know if it's safe to
send VIRTIO_BLK_T_GET_LONG_ID.

>  \end{lstlisting}
>  
>  The \field{flags} bitfield is ignored by the device unless
> @@ -515,9 +516,26 @@ \subsection{Device Operation}\label{sec:Device Types / Block Device / Device Ope
>  the device to discard the specified range, provided that following reads return
>  zeroes.
>  
> -VIRTIO_BLK_T_GET_ID requests fetch the device ID string from the device into
> -\field{data}.  The device ID string is a NUL-padded ASCII string up to 20 bytes
> -long.  If the string is 20 bytes long then there is no NUL terminator.
> +VIRTIO_BLK_T_GET_ID or VIRTIO_BLK_T_GET_LONG_ID requests fetch the
> +device ID string from the device into \field{data}.  The device ID
> +string is an ASCII string which can be up to 247 bytes long.
> +
> +VIRTIO_BLK_T_GET_ID fetches the first 20 bytes of the device ID
> +string.  If the ID is shorter than 20 bytes, then the response is
> +padded with NUL bytes so its length is 20 bytes.  (Note that if the ID
> +is 20 bytes or longer, this means the response will not be NUL
> +terminated.)
> +
> +VIRTIO_BLK_T_GET_LONG_ID fetches the complete device ID string.  The
> +response is always 248 bytes long, padded to this length with NUL
> +bytes.  Since the longest permitted device ID string is 247 bytes, the
> +response MUST be NUL terminated.

That's a lot of padding) Sure u do not want to use the actual length?

And pls avoid MUST outside conformance statements.
Here "is NUL terminated".

> +
> +Device drivers MAY choose a mechanism to opt in to longer device IDs,

same here, avoid MAY

> +to prevent existing guests

existing where?

> from breaking when they see a longer
> +(non-truncated) device ID.  In this case a guest which has not opted

avoid "guest"

> +in will continue to use VIRTIO_BLK_T_GET_ID

continue in what sense?

> and ignore the complete
> +ID.


No idea what does the above imply.

Maybe add conformance statements that say exactly what you mean.



>  
>  The \field{data} used for VIRTIO_BLK_T_GET_LIFETIME requests is populated
>  by the device, and is of the form
> -- 
> 2.55.0
> 
> 

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

[Richard W.M. Jones]

On Sun, Sep 06, 2026 at 11:13:39AM -0400, Michael S. Tsirkin wrote:
> On Sun, Sep 06, 2026 at 03:54:44PM +0100, Richard W.M. Jones wrote:
[...]
> U also want a feature bit otherwise driver does not know if it's safe to
> send VIRTIO_BLK_T_GET_LONG_ID.

Interestingly (at least for Linux) sending VIRTIO_BLK_T_GET_LONG_ID
when the hypervisor doesn't support it returns -EOPNOTSUPP, but I can
add a feature bit as well.

> >  \end{lstlisting}
> >  
> >  The \field{flags} bitfield is ignored by the device unless
> > @@ -515,9 +516,26 @@ \subsection{Device Operation}\label{sec:Device Types / Block Device / Device Ope
> >  the device to discard the specified range, provided that following reads return
> >  zeroes.
> >  
> > -VIRTIO_BLK_T_GET_ID requests fetch the device ID string from the device into
> > -\field{data}.  The device ID string is a NUL-padded ASCII string up to 20 bytes
> > -long.  If the string is 20 bytes long then there is no NUL terminator.
> > +VIRTIO_BLK_T_GET_ID or VIRTIO_BLK_T_GET_LONG_ID requests fetch the
> > +device ID string from the device into \field{data}.  The device ID
> > +string is an ASCII string which can be up to 247 bytes long.
> > +
> > +VIRTIO_BLK_T_GET_ID fetches the first 20 bytes of the device ID
> > +string.  If the ID is shorter than 20 bytes, then the response is
> > +padded with NUL bytes so its length is 20 bytes.  (Note that if the ID
> > +is 20 bytes or longer, this means the response will not be NUL
> > +terminated.)
> > +
> > +VIRTIO_BLK_T_GET_LONG_ID fetches the complete device ID string.  The
> > +response is always 248 bytes long, padded to this length with NUL
> > +bytes.  Since the longest permitted device ID string is 247 bytes, the
> > +response MUST be NUL terminated.
> 
> That's a lot of padding) Sure u do not want to use the actual length?

I'm not too clear on this (and the spec is also unclear), but it seems
the buffer is allocated in the guest RAM?  In that case since it
doesn't know the length in advance it must allocate a fixed size buffer.

[...]
> > +(non-truncated) device ID.  In this case a guest which has not opted
> 
> avoid "guest"

Is "driver" preferred?

I'll send a follow up addressing your other points, but probably not today.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit

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

[Michael S. Tsirkin]

On Sun, Sep 06, 2026 at 05:06:25PM +0100, Richard W.M. Jones wrote:
> On Sun, Sep 06, 2026 at 11:13:39AM -0400, Michael S. Tsirkin wrote:
> > On Sun, Sep 06, 2026 at 03:54:44PM +0100, Richard W.M. Jones wrote:
> [...]
> > U also want a feature bit otherwise driver does not know if it's safe to
> > send VIRTIO_BLK_T_GET_LONG_ID.
> 
> Interestingly (at least for Linux) sending VIRTIO_BLK_T_GET_LONG_ID
> when the hypervisor doesn't support it returns -EOPNOTSUPP, but I can
> add a feature bit as well.
> 
> > >  \end{lstlisting}
> > >  
> > >  The \field{flags} bitfield is ignored by the device unless
> > > @@ -515,9 +516,26 @@ \subsection{Device Operation}\label{sec:Device Types / Block Device / Device Ope
> > >  the device to discard the specified range, provided that following reads return
> > >  zeroes.
> > >  
> > > -VIRTIO_BLK_T_GET_ID requests fetch the device ID string from the device into
> > > -\field{data}.  The device ID string is a NUL-padded ASCII string up to 20 bytes
> > > -long.  If the string is 20 bytes long then there is no NUL terminator.
> > > +VIRTIO_BLK_T_GET_ID or VIRTIO_BLK_T_GET_LONG_ID requests fetch the
> > > +device ID string from the device into \field{data}.  The device ID
> > > +string is an ASCII string which can be up to 247 bytes long.
> > > +
> > > +VIRTIO_BLK_T_GET_ID fetches the first 20 bytes of the device ID
> > > +string.  If the ID is shorter than 20 bytes, then the response is
> > > +padded with NUL bytes so its length is 20 bytes.  (Note that if the ID
> > > +is 20 bytes or longer, this means the response will not be NUL
> > > +terminated.)
> > > +
> > > +VIRTIO_BLK_T_GET_LONG_ID fetches the complete device ID string.  The
> > > +response is always 248 bytes long, padded to this length with NUL
> > > +bytes.  Since the longest permitted device ID string is 247 bytes, the
> > > +response MUST be NUL terminated.
> > 
> > That's a lot of padding) Sure u do not want to use the actual length?
> 
> I'm not too clear on this (and the spec is also unclear), but it seems
> the buffer is allocated in the guest RAM?



Yes. But the driver specifies the length to the device.
So do we need a new type of request? We could just
change the length depending on a feature bit.


>  In that case since it
> doesn't know the length in advance it must allocate a fixed size buffer.
> 
> [...]

That's certainly the simplest way to do it, so that's what the spec
does:

The length of \field{data} MUST be 20 bytes for VIRTIO_BLK_T_GET_ID requests.




> > > +(non-truncated) device ID.  In this case a guest which has not opted
> > 
> > avoid "guest"
> 
> Is "driver" preferred?


yes

> I'll send a follow up addressing your other points, but probably not today.
> 
> Rich.

I have some more comments from reading more about it.

> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> nbdkit - Flexible, fast NBD server with plugins
> https://gitlab.com/nbdkit/nbdkit

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

[Michael S. Tsirkin]

On Sun, Sep 06, 2026 at 03:54:44PM +0100, Richard W.M. Jones wrote:
> SCSI-based paravirtualized block devices including virtio-scsi and
> VMware's pvscsi allow longer device IDs.  This presents an issue when
> we change the backing of a disk from one type to another, eg from
> pvscsi to virtio-blk, or virtio-scsi to virtio-blk.  The longer device
> ID has to be truncated to 20 bytes.  This results in guest visible
> changes, notably /dev/disk/by-id/ paths are different, so any
> mountpoints or configuration files that use these paths will break.
> 
> Therefore extend virtio-blk to allow longer device IDs.  I chose 247
> bytes (ASCII chars) as the new limit since it can cope with any SCSI
> device serial.  Real serials will be much shorter than this; the aim
> is to allow UUIDs to be preserved which would use 32 or 36 ASCII
> chars.
> 
> We have to be cautious about breaking existing guests where the
> hypervisor is currently silently truncating a longer ID to 20 bytes.
> I suggest in the specification that virtio-blk device drivers allow a
> way to opt in to longer IDs, but this is ultimately up to the guests /
> drivers to decide.
> 
> Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
> ---
>  device-types/blk/description.tex | 32 +++++++++++++++++++++++++-------
>  1 file changed, 25 insertions(+), 7 deletions(-)
> 
> diff --git a/device-types/blk/description.tex b/device-types/blk/description.tex
> index 3b3a4e7..d42ca21 100644
> --- a/device-types/blk/description.tex
> +++ b/device-types/blk/description.tex
> @@ -457,9 +457,9 @@ \subsection{Device Operation}\label{sec:Device Types / Block Device / Device Ope
>  The type of the request is either a read (VIRTIO_BLK_T_IN), a write
>  (VIRTIO_BLK_T_OUT), a discard (VIRTIO_BLK_T_DISCARD), a write zeroes
>  (VIRTIO_BLK_T_WRITE_ZEROES), a flush (VIRTIO_BLK_T_FLUSH), a get device ID
> -string command (VIRTIO_BLK_T_GET_ID), a secure erase
> -(VIRTIO_BLK_T_SECURE_ERASE), or a get device lifetime command
> -(VIRTIO_BLK_T_GET_LIFETIME).
> +string command (VIRTIO_BLK_T_GET_ID or VIRTIO_BLK_T_GET_LONG_ID),
> +a secure erase (VIRTIO_BLK_T_SECURE_ERASE), or a get device lifetime
> +command (VIRTIO_BLK_T_GET_LIFETIME).
>  
>  \begin{lstlisting}
>  #define VIRTIO_BLK_T_IN           0


I think it is time we folded this list with the defines below,
to avoid repetition, and help implementers:


	The type of the request is one of the following:
	....

	#define VIRTIO_BLK_T_GET_LIFETIME 10 /* get device lifetime */
	#define VIRTIO_BLK_T_DISCARD      11 /* discard */


> @@ -469,7 +469,8 @@ \subsection{Device Operation}\label{sec:Device Types / Block Device / Device Ope
>  #define VIRTIO_BLK_T_GET_LIFETIME 10
>  #define VIRTIO_BLK_T_DISCARD      11
>  #define VIRTIO_BLK_T_WRITE_ZEROES 13
> -#define VIRTIO_BLK_T_SECURE_ERASE   14
> +#define VIRTIO_BLK_T_SECURE_ERASE 14
> +#define VIRTIO_BLK_T_GET_LONG_ID  32
>  \end{lstlisting}
>  
>  The \field{flags} bitfield is ignored by the device unless
> @@ -515,9 +516,26 @@ \subsection{Device Operation}\label{sec:Device Types / Block Device / Device Ope
>  the device to discard the specified range, provided that following reads return
>  zeroes.
>  
> -VIRTIO_BLK_T_GET_ID requests fetch the device ID string from the device into
> -\field{data}.  The device ID string is a NUL-padded ASCII string up to 20 bytes
> -long.  If the string is 20 bytes long then there is no NUL terminator.
> +VIRTIO_BLK_T_GET_ID or VIRTIO_BLK_T_GET_LONG_ID requests fetch the
> +device ID string from the device into \field{data}.  The device ID
> +string is an ASCII string which can be up to 247 bytes long.

why 247? It feels like a lot, especially given we are padding. I'd say
128 maybe.  This way it fits in a single pci express packet on most
systems.

And as long as we are relaxing things, let's allow unicode?



> +
> +VIRTIO_BLK_T_GET_ID fetches the first 20 bytes of the device ID
> +string.  If the ID is shorter than 20 bytes, then the response is
> +padded with NUL bytes so its length is 20 bytes.  (Note that if the ID
> +is 20 bytes or longer, this means the response will not be NUL
> +terminated.)

Why first specifically?


> +
> +VIRTIO_BLK_T_GET_LONG_ID fetches the complete device ID string.

Until we add LONG_LONG_ID )

>  The
> +response is always 248 bytes long, padded to this length with NUL
> +bytes.  Since the longest permitted device ID string is 247 bytes, the
> +response MUST be NUL terminated.
> +
> +Device drivers MAY choose a mechanism to opt in to longer device IDs,
> +to prevent existing guests from breaking when they see a longer
> +(non-truncated) device ID.
>  In this case a guest which has not opted
> +in will continue to use VIRTIO_BLK_T_GET_ID and ignore the complete
> +ID.

But we don't know that the first 20 bytes are unique or descriptive
enough.

>  The \field{data} used for VIRTIO_BLK_T_GET_LIFETIME requests is populated
>  by the device, and is of the form
> -- 
> 2.55.0
> 
> 

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

[Richard W.M. Jones]

On Mon, Sep 07, 2026 at 03:56:56AM -0400, Michael S. Tsirkin wrote:
> why 247? It feels like a lot, especially given we are padding. I'd say
> 128 maybe.  This way it fits in a single pci express packet on most
> systems.

virtio-scsi supports, at least in theory, 248 bytes, see:

https://gitlab.com/qemu/qemu/-/blob/cacd3462963a0a4f5bab4263ce79c2aa4b32692d/hw/scsi/scsi-disk.c#L708

This is chosen because of the maximum page size of a SCSI VPD (256)
minus the 8 bytes used for the header in VPD page 0x83.

Windows supports up to 128 "characters" and does support Unicode:

https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/storport/ns-storport-stor_serial_number

Although ...

> And as long as we are relaxing things, let's allow unicode?

... I feel we're just going to be introducing a world of pain by
trying to support Unicode, and I think anyone trying to use Unicode
serial numbers is doing it wrong.  Or anything outside numbers,
letters and dashes TBH.

Serials that I actually care about for my use case (converting from
VMware) are written as 32 hex characters, which VMware refers to as
"UUIDs" (they are actually encoded in binary by pvscsi but that's not
relevant here).

I think we could choose 247 or 248, but recommend that serials never
exceed 128 characters if implementers are concerned about
interoperability issues.  We still want to permit virtio-scsi serials
to be compatible with virtio-blk which argues for the larger sizes.

247 has the minor advantage that the response is always NUL-terminated.

> > +VIRTIO_BLK_T_GET_ID fetches the first 20 bytes of the device ID
> > +string.  If the ID is shorter than 20 bytes, then the response is
> > +padded with NUL bytes so its length is 20 bytes.  (Note that if the ID
> > +is 20 bytes or longer, this means the response will not be NUL
> > +terminated.)
> 
> Why first specifically?

For backwards compatibility (assuming I understand the question).
qemu's current behaviour is to truncate.

> > +Device drivers MAY choose a mechanism to opt in to longer device IDs,
> > +to prevent existing guests from breaking when they see a longer
> > +(non-truncated) device ID.
> >  In this case a guest which has not opted
> > +in will continue to use VIRTIO_BLK_T_GET_ID and ignore the complete
> > +ID.
> 
> But we don't know that the first 20 bytes are unique or descriptive
> enough.

Sure, in fact we know it is _not_, which is exactly the reason to
introduce the longer serials.

I'm preparing a follow up which I'll post shortly.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

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

[Michael S. Tsirkin]

On Mon, Sep 07, 2026 at 03:02:24PM +0100, Richard W.M. Jones wrote:
> On Mon, Sep 07, 2026 at 03:56:56AM -0400, Michael S. Tsirkin wrote:
> > why 247? It feels like a lot, especially given we are padding. I'd say
> > 128 maybe.  This way it fits in a single pci express packet on most
> > systems.
> 
> virtio-scsi supports, at least in theory, 248 bytes, see:
> 
> https://gitlab.com/qemu/qemu/-/blob/cacd3462963a0a4f5bab4263ce79c2aa4b32692d/hw/scsi/scsi-disk.c#L708
> 
> This is chosen because of the maximum page size of a SCSI VPD (256)
> minus the 8 bytes used for the header in VPD page 0x83.

Can I see a spec which says that is the maximum size?

> Windows supports up to 128 "characters" and does support Unicode:
> 
> https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/storport/ns-storport-stor_serial_number
> 
> Although ...
> 
> > And as long as we are relaxing things, let's allow unicode?
> 
> ... I feel we're just going to be introducing a world of pain by
> trying to support Unicode, and I think anyone trying to use Unicode
> serial numbers is doing it wrong.  Or anything outside numbers,
> letters and dashes TBH.

Really anything close to NAME_MAX is already a world of pain
for guests.


> Serials that I actually care about for my use case (converting from
> VMware) are written as 32 hex characters, which VMware refers to as
> "UUIDs" (they are actually encoded in binary by pvscsi but that's not
> relevant here).
> 
> I think we could choose 247 or 248, but recommend that serials never
> exceed 128 characters if implementers are concerned about
> interoperability issues.  We still want to permit virtio-scsi serials
> to be compatible with virtio-blk which argues for the larger sizes.
> 
> 247 has the minor advantage that the response is always NUL-terminated.
> 
> > > +VIRTIO_BLK_T_GET_ID fetches the first 20 bytes of the device ID
> > > +string.  If the ID is shorter than 20 bytes, then the response is
> > > +padded with NUL bytes so its length is 20 bytes.  (Note that if the ID
> > > +is 20 bytes or longer, this means the response will not be NUL
> > > +terminated.)
> > 
> > Why first specifically?
> 
> For backwards compatibility (assuming I understand the question).
> qemu's current behaviour is to truncate.

That's just a qemu command line quirk then.
At least from spec POV it isn't - the id must be <= 20.

> > > +Device drivers MAY choose a mechanism to opt in to longer device IDs,
> > > +to prevent existing guests from breaking when they see a longer
> > > +(non-truncated) device ID.
> > >  In this case a guest which has not opted
> > > +in will continue to use VIRTIO_BLK_T_GET_ID and ignore the complete
> > > +ID.
> > 
> > But we don't know that the first 20 bytes are unique or descriptive
> > enough.
> 
> Sure, in fact we know it is _not_, which is exactly the reason to
> introduce the longer serials.
> 
> I'm preparing a follow up which I'll post shortly.
> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> libguestfs lets you edit virtual machines.  Supports shell scripting,
> bindings from many languages.  http://libguestfs.org

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

[Richard W.M. Jones]

On Mon, Sep 07, 2026 at 03:27:25PM -0400, Michael S. Tsirkin wrote:
> On Mon, Sep 07, 2026 at 03:02:24PM +0100, Richard W.M. Jones wrote:
> > On Mon, Sep 07, 2026 at 03:56:56AM -0400, Michael S. Tsirkin wrote:
> > > why 247? It feels like a lot, especially given we are padding. I'd say
> > > 128 maybe.  This way it fits in a single pci express packet on most
> > > systems.
> > 
> > virtio-scsi supports, at least in theory, 248 bytes, see:
> > 
> > https://gitlab.com/qemu/qemu/-/blob/cacd3462963a0a4f5bab4263ce79c2aa4b32692d/hw/scsi/scsi-disk.c#L708
> > 
> > This is chosen because of the maximum page size of a SCSI VPD (256)
> > minus the 8 bytes used for the header in VPD page 0x83.
> 
> Can I see a spec which says that is the maximum size?

I don't think virtio-scsi is following a spec, but it's clear from the
source code that the limit is 256-8, see the link above.

[...]
> > > > +VIRTIO_BLK_T_GET_ID fetches the first 20 bytes of the device ID
> > > > +string.  If the ID is shorter than 20 bytes, then the response is
> > > > +padded with NUL bytes so its length is 20 bytes.  (Note that if the ID
> > > > +is 20 bytes or longer, this means the response will not be NUL
> > > > +terminated.)
> > > 
> > > Why first specifically?
> > 
> > For backwards compatibility (assuming I understand the question).
> > qemu's current behaviour is to truncate.
> 
> That's just a qemu command line quirk then.
> At least from spec POV it isn't - the id must be <= 20.

Isn't the virtio spec also there (partly) to clarify and formalise
what existing implementations actually do?  qemu truncates.
Firecracker truncates:

https://github.com/firecracker-microvm/firecracker/blob/7699746649826d1dfcdde626b3131bac08f28e0d/src/vmm/src/devices/virtio/block/virtio/device.rs#L159

libkrun seems to be using the same code as Firecracker, so it also
truncates:

https://github.com/libkrun/libkrun/blob/413a011760b7ee61493fb0073f7810319ca6a181/src/devices/src/virtio/block/device.rs#L170

I have a v3 which considerably simplifies the specification &
implementation which I'll post very soon.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

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

[Michael S. Tsirkin]

On Tue, Sep 08, 2026 at 10:35:34AM +0100, Richard W.M. Jones wrote:
> On Mon, Sep 07, 2026 at 03:27:25PM -0400, Michael S. Tsirkin wrote:
> > On Mon, Sep 07, 2026 at 03:02:24PM +0100, Richard W.M. Jones wrote:
> > > On Mon, Sep 07, 2026 at 03:56:56AM -0400, Michael S. Tsirkin wrote:
> > > > why 247? It feels like a lot, especially given we are padding. I'd say
> > > > 128 maybe.  This way it fits in a single pci express packet on most
> > > > systems.
> > > 
> > > virtio-scsi supports, at least in theory, 248 bytes, see:
> > > 
> > > https://gitlab.com/qemu/qemu/-/blob/cacd3462963a0a4f5bab4263ce79c2aa4b32692d/hw/scsi/scsi-disk.c#L708
> > > 
> > > This is chosen because of the maximum page size of a SCSI VPD (256)
> > > minus the 8 bytes used for the header in VPD page 0x83.
> > 
> > Can I see a spec which says that is the maximum size?
> 
> I don't think virtio-scsi is following a spec,


But you referred to SCSI VPD and said it has a limit of 256
and an 8 byte header. I can't figure out where this is from?

> but it's clear from the
> source code that the limit is 256-8, see the link above.
> 
> [...]


Hmm. I see MAX_SERIAL_LEN which is 36? And  MAX_SERIAL_LEN_FOR_DEVID
which is 20?


> > > > > +VIRTIO_BLK_T_GET_ID fetches the first 20 bytes of the device ID
> > > > > +string.  If the ID is shorter than 20 bytes, then the response is
> > > > > +padded with NUL bytes so its length is 20 bytes.  (Note that if the ID
> > > > > +is 20 bytes or longer, this means the response will not be NUL
> > > > > +terminated.)
> > > > 
> > > > Why first specifically?
> > > 
> > > For backwards compatibility (assuming I understand the question).
> > > qemu's current behaviour is to truncate.
> > 
> > That's just a qemu command line quirk then.
> > At least from spec POV it isn't - the id must be <= 20.
> 
> Isn't the virtio spec also there (partly) to clarify and formalise
> what existing implementations actually do?  qemu truncates.
> Firecracker truncates:
> 
> https://github.com/firecracker-microvm/firecracker/blob/7699746649826d1dfcdde626b3131bac08f28e0d/src/vmm/src/devices/virtio/block/virtio/device.rs#L159
> 
> libkrun seems to be using the same code as Firecracker, so it also
> truncates:
> 
> https://github.com/libkrun/libkrun/blob/413a011760b7ee61493fb0073f7810319ca6a181/src/devices/src/virtio/block/device.rs#L170


I can easily imagine a situation where someone prefixes the serial
with "virtio-" or whatever extra data, and shows the suffix
as the short id. Or hashes the short id. Or whatever.


> I have a v3 which considerably simplifies the specification &
> implementation which I'll post very soon.
> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-p2v converts physical machines to virtual machines.  Boot with a
> live CD or over the network (PXE) and turn machines into KVM guests.
> http://libguestfs.org/virt-v2v

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

[Richard W.M. Jones]

On Tue, Sep 08, 2026 at 06:06:14AM -0400, Michael S. Tsirkin wrote:
> On Tue, Sep 08, 2026 at 10:35:34AM +0100, Richard W.M. Jones wrote:
> > On Mon, Sep 07, 2026 at 03:27:25PM -0400, Michael S. Tsirkin wrote:
> > > On Mon, Sep 07, 2026 at 03:02:24PM +0100, Richard W.M. Jones wrote:
> > > > On Mon, Sep 07, 2026 at 03:56:56AM -0400, Michael S. Tsirkin wrote:
> > > > > why 247? It feels like a lot, especially given we are padding. I'd say
> > > > > 128 maybe.  This way it fits in a single pci express packet on most
> > > > > systems.
> > > > 
> > > > virtio-scsi supports, at least in theory, 248 bytes, see:
> > > > 
> > > > https://gitlab.com/qemu/qemu/-/blob/cacd3462963a0a4f5bab4263ce79c2aa4b32692d/hw/scsi/scsi-disk.c#L708
> > > > 
> > > > This is chosen because of the maximum page size of a SCSI VPD (256)
> > > > minus the 8 bytes used for the header in VPD page 0x83.
> > > 
> > > Can I see a spec which says that is the maximum size?
> > 
> > I don't think virtio-scsi is following a spec,
> 
> 
> But you referred to SCSI VPD and said it has a limit of 256
> and an 8 byte header. I can't figure out where this is from?
> 
> > but it's clear from the
> > source code that the limit is 256-8, see the link above.
> > 
> > [...]
> 
> 
> Hmm. I see MAX_SERIAL_LEN which is 36? And  MAX_SERIAL_LEN_FOR_DEVID
> which is 20?

Indeed you're right ... and this is very confusing.

qemu lets you set both serial and device_id, eg:

$ qemu-system-x86_64 -machine accel=kvm:tcg -cpu max -m 4096 \
  -device virtio-scsi-pci,id=scsi0 \
  -drive id=hd1,file=$HOME/tmp/vms/rhel-10.qcow2,format=qcow2,if=none \
  -device scsi-hd,bus=scsi0.0,drive=hd1,device_id=ABCDEFGHIJ0123456789abcdefghij0123456789ABCDEFGHIJ0123456789abcdefghij0123456789ABCDEFGHIJ0123456789abcdefghij0123456789ABCDEFGHIJ0123456789abcdefghij0123456789ABCDEFGHIJ0123456789abcdefghij0123456789ABCDEFGHIJ0123456789abcdefghij0123456789,serial=123456789012345678901234567890 

'serial' is exposed through VPD page 0x80 and is limited to 36 chars.

'device_id' is exposed through VPD page 0x83 and is limited to 256-8
bytes.

udev seems to use page 0x80 (not 0x83) to generate symlinks.

Anyway 20 chars is < 36 chars so the need for longer serials for
virtio-blk remains.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

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

[Michael S. Tsirkin]

On Tue, Sep 08, 2026 at 11:43:45AM +0100, Richard W.M. Jones wrote:
> Anyway 20 chars is < 36 chars so the need for longer serials for
> virtio-blk remains.
> 
> Rich.

I am surely not arguing about that.

-- 
MST