On Wed, Jul 10, 2024 at 04:48:23PM -0300, Fabiano Rosas wrote:
> Peter Xu <peterx(a)redhat.com> writes:
>
> > On Wed, Jul 10, 2024 at 01:21:51PM -0300, Fabiano Rosas wrote:
> >> It's not about trust, we simply don't support migrations other than
> >> n->n+1 and (maybe) n->n-1. So QEMU from 2016 is certainly not
included.
> >
> > Where does it come from? I thought we suppport that..
>
> I'm taking that from:
>
> docs/devel/migration/main.rst:
> "In general QEMU tries to maintain forward migration compatibility
> (i.e. migrating from QEMU n->n+1) and there are users who benefit from
> backward compatibility as well."
>
> But of course it doesn't say whether that comes with a transitive rule
> allowing n->n+2 migrations.
I'd say that "i.e." implies n->n+1 is not the only forward migration we
would support.
I _think_ we should support all forward migration as long as the machine
type matches.
>
> >
> > The same question would be: are we requesting an OpenStack cluster to
> > always upgrade QEMU with +1 versions, otherwise migration will fail?
>
> Will an OpenStack cluster be using upstream QEMU? If not, then that's a
It's an example to show what I meant! :) Nothing else. Definitely not
saying that everyone should use an upstream released QEMU (but in reality,
it's not a problem, I think, and I do feel like people use them, perhaps
more with the stable releases).
> question for the distro. In a very practical sense, we're not requesting
> anything. We barely test n->n+1/n->n-1, even if we had a strong support
> statement I wouldn't be confident saying migration from QEMU 2.7 -> QEMU
> 9.1 should succeed.
No matter what we test in CI, I don't think we should break that for >1
versions.. I hope 2.7->9.1 keeps working, otherwise I think it's legal to
file a bug by anyone.
For example, I randomly fetched a bug report:
https://gitlab.com/qemu-project/qemu/-/issues/1937
QEMU version: 6.2 and 7.2.5
And I believe that's the common case even for upstream. If we don't do
that right for upstream, it can be impossible tasks for downstream and for
all of us to maintain.
But do we do that right currently? I have no idea. Have we ever done
it? And we're here discussing a hypothetical 2.7->9.1 ...
So we cannot reuse the UNUSED field because QEMU from 2016 might send
their data and QEMU from 2024 would interpret it wrong.
How do we proceed? Add a subsection. And make the code survive when
receiving 0.
@Peter is that it? What about backwards-compat? We'll need a property as
well it seems.