[PATCH 1/2] qemu_capabilities: Introduce QEMU_CAPS_X_USE_CANONICAL_PATH_FOR_RAMBLOCK_ID

[Peter Krempa]

On Tue, Jan 12, 2021 at 20:24:44 +0100, Igor Mammedov wrote:
> On Tue, 12 Jan 2021 18:41:38 +0000
> Daniel P. Berrangé <berrange at redhat.com> wrote:
> 
> > On Tue, Jan 12, 2021 at 07:28:45PM +0100, Peter Krempa wrote:
> > > On Tue, Jan 12, 2021 at 19:20:58 +0100, Igor Mammedov wrote:  
> > > > On Tue, 12 Jan 2021 12:35:19 +0100
> > > > Peter Krempa <pkrempa at redhat.com> wrote

[...]

> > Yeah it is pretty dubious on the QEMU side to have used an "x-" prefix
> > here at all, when use of this option is mandatory to make migration
> > work :-(
> 
> if generic consensus is to drop prefix, I can post a QEMU patch to do so
> and let downstream(s) to carry burden.

It really depends on the situation, because the commit messages don't
seem to describe it satisfactory.

Basically we don't want to ever use a qemu property knob, which is qemu
free to change arbitrarily.

If the property is to be used with any upcoming qemu version we must get
a guarantee that it will not change. There are two options basically:

1) 'x-' is dropped
 1a) we will use it with qemu-6.0 and later
    ( everything is clean, but users will have to update qemu to fix it )
 1b) we will carry code which will use 'x-' prefixed version from it's
     inception until qemu-5.2, when we will hard-mask it out and add
     plenty comments outlining that this is not what we do normally
     (it will be okay for past releases, since they will not change)

2) qemu declares the option stable with the 'x-' prefix
   We'll require that any place even in the code which declares the
   option has an appropriate comment preventing anybody from changing
   it.

   We'll then add also cautionary comments discouraging use of it.

3) qemu fixes the issue without libvirt's involvment

For us really 1a) and 3 is acceptable without any comments. Other
options will require extraordinary measures to prevent using this as
prior art in using any other x-prefixed features from qemu.

in 1a) case, downstreams can obviously backport the qemu patch renaming
the feature and libvirt will require no change at all

Now the question is whether we want to make migration work between the
affected releases which will depend what to use.