[PATCH] docs: formatdomain: Document disk serial truncation status quo
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@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 + 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. ``wwn`` If present, this element specifies the WWN (World Wide Name) of a virtual hard disk or CD-ROM drive. It must be composed of 16 hexadecimal digits. -- 2.31.1
On 6/4/21 2:08 PM, 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@redhat.com> --- docs/formatdomain.rst | 10 ++++++++++ 1 file changed, 10 insertions(+)
Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Michal
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@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@redhat.com>
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@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.
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.
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@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@redhat.com>
On Tue, Jun 29, 2021 at 21:37:19 +0200, Tomáš Golembiovský wrote:
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:
[...]
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.
I'm a bit sceptical that qemu will ever make it a hard failure, especially since there's proof that we have VMs that are using long serials and qemu is silently truncating it. Even in such case it would break existing configurations. The only reasonable way I can see is to only make it a failure after extending the size to at least 36 characters to accomodate UUIDs which were accepted for some time. In case of IDE drives I don't think that's possible though so they'll need to stay an exception. I'll point this out to QEMU devs in case it will ever get to it.
participants (3)
-
Michal Prívozník -
Peter Krempa -
Tomáš Golembiovský