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>
---
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.
+ 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. 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
what are the chances that the limit in hypervisor will become smaller?
Or is it safe to assume that the limit will only grow in future versions
of the hypervisor (notably QEMU).
Thanks,
Tomas
--
Tomáš Golembiovský <tgolembi(a)redhat.com>