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@xxxxxxxxxx>
> > > ---
> > > 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@xxxxxxxxxx>
