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

Peter Krempa pkrempa at redhat.com
Wed Jun 30 08:16:43 UTC 2021


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.




More information about the libvir-list mailing list