Disk serials are truncated arbitrarily and silently by qemu depending on the device type and how they are configured. Since changing the current state would lead to more regressions than we have now, document that the truncation is arbitrary. Signed-off-by: Peter Krempa <pkrempa(a)redhat.com&gt; --- docs/formatdomain.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index aa7bb8da14..3ee537da14 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -3146,6 +3146,16 @@ paravirtualized driver is specified via the ``disk`` element. may look like ``<serial>WD-WMAP9A966149</serial>``. Not supported for scsi-block devices, that is those using disk ``type`` 'block' using ``device`` 'lun' on ``bus`` 'scsi'. :since:`Since 0.7.1` + + Note that depending on hypervisor and device type the serial number may be + truncated silently. IDE/SATA devices are commonly limited to 20 characters. + SCSI devices depending on hypervisor version are limited to 20, 36 or 247

+ characters. + + Hypervisors may also start rejecting overly long serials instead of + truncating them in the future so it's advised to avoid the implicit + truncation by testing the desired serial length range with the desired device + and hypervisor combination.

On Mon, Jun 28, 2021 at 16:55:34 +0200, Tomáš Golembiovský wrote: > Hi, > > I have a few questions regarding this to get better understanding on how > this should be handled by management apps. > > On Fri, Jun 04, 2021 at 02:08:40PM +0200, Peter Krempa wrote: > > Disk serials are truncated arbitrarily and silently by qemu depending on > > the device type and how they are configured. Since changing the current > > state would lead to more regressions than we have now, document that the > > truncation is arbitrary. > > > > Signed-off-by: Peter Krempa <pkrempa(a)redhat.com&gt; > > --- > > docs/formatdomain.rst | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst > > index aa7bb8da14..3ee537da14 100644 > > --- a/docs/formatdomain.rst > > +++ b/docs/formatdomain.rst > > @@ -3146,6 +3146,16 @@ paravirtualized driver is specified via the ``disk`` element. > > may look like ``<serial>WD-WMAP9A966149</serial>``. Not supported for > > scsi-block devices, that is those using disk ``type`` 'block' using > > ``device`` 'lun' on ``bus`` 'scsi'. :since:`Since 0.7.1` > > + > > + Note that depending on hypervisor and device type the serial number may be > > + truncated silently. IDE/SATA devices are commonly limited to 20 characters. > > + SCSI devices depending on hypervisor version are limited to 20, 36 or 247 > > Is this meant to say "hypervisor" or is it really "hypervisor version"? > This can mean a huge difference. See below. In this case, hypervisor + version. > > + characters. > > + > > + Hypervisors may also start rejecting overly long serials instead of > > + truncating them in the future so it's advised to avoid the implicit > > + truncation by testing the desired serial length range with the desired device > > + and hypervisor combination. > > If hypervisor start rejecting long serial numbers than this will become > tricky. It indeed will be tricky. > Does the above mean libvirt can report the length limit? Or does > that mean one should first try running some VMs to test the limit, take > a note of the length and hardcode that? If it is the later then For now, libvirt can't do that because qemu isn't exposing this data in any way, but in case it would make oVirt's life easier I think we can ask QEMU to add the length limit in an introspectable fashion.

> what are the chances that the limit in hypervisor will become smaller? Generally I'd assume it's close to 0. Decreasing the length can be generally considered as regression in behaviour and more importantly there usually aren't technical reasons to do that once it's proven to work ad a higher limit. > Or is it safe to assume that the limit will only grow in future versions > of the hypervisor (notably QEMU). For qemu I think it's safe to assume that it will only grow in cases where the technical limit of the emulated device's serial passing approach is higher than currently considered.