[PATCH] docs: formatdomain: Document disk serial truncation status quo

[Tomáš Golembiovský]

On Tue, Jun 29, 2021 at 03:33:26PM +0200, Peter Krempa wrote:
> 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 at redhat.com>
> > > ---
> > >  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.
> 

Ok, there's probably no need for that if we can safely assume the limit
will not become smaller in the future. I was concerned about a situation
where all VMs would suddnely start failing after QEMU upgrade.

Thanks for the info,

    Tomas


> > 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.
> 

-- 
Tomáš Golembiovský <tgolembi at redhat.com>