Re: [PATCH 1/2] qemu_capabilities: Introduce QEMU_CAPS_X_USE_CANONICAL_PATH_FOR_RAMBLOCK_ID
On Tue, 12 Jan 2021 20:59:11 +0100
Peter Krempa <pkrempa(a)redhat.com> wrote:
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(a)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(a)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 )
I have
thought about it some more, (modulo downstream issue)
dropping prefix will effectively exclude old QEMU-(5.0-5.2)
even though feature is available there.
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)
5.2 is not
enough, it should be carried till machine type 4.0 exists.
On QEMU side we once 4.0 machine type is removed we can deprecate and
remove no longer needed option so libvirt (with this patches) would see
that it no longer exists and not put it on CLI anymore. Only after that
it probably is ok to drop code for it.
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.
I've
just resent v2 of QEMU patch that incorporates your suggestions.
3) qemu fixes the issue without libvirt's involvment
if it were possible the
option, I'd go for it in the first place.
unfortunately, it's too late for it now.
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.
If we can help it, then yes.
That's why I resent QEMU patch keeping 'x-' prefix (with your feedback
included).