Peter Xu <pet...@redhat.com> writes: > On Wed, Jul 10, 2024 at 04:48:23PM -0300, Fabiano Rosas wrote: >> Peter Xu <pet...@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.
