On Fri, May 29, 2026 at 5:44 PM Michael Tokarev <[email protected]> wrote: > > [Trimmed the Cc list a bit] > > On 27.05.2026 15:20, Fabiano Rosas wrote: > > > There are no migration compatibility guarantees for an unversioned > > machine type. Only migration and snapshots from same-version QEMUs are > > expected to work in this case. Other scenarios may or may not work. > .. > > > > The addition from this patch is in a subsection, so .needed will > > determine whether it will be put on the stream. If we backport the > > change, then the stable QEMU build will (likely) start sending this > > subsection, which the old, non-stable QEMU will not recognize and > > migration will fail. Migration from stable-stable would likely work. > > > > So any stable versions that (would) contain this patch are likely to > > block migration from that version into an unpatched QEMU. > > > > Note that since the machine is unversioned, migration from QEMU x to > > QEMU x+1 is already prone to being broken.
Sorry, I forgot to reply to this one. Yep, that's fine. AFAIK no one expects this to work, so we are still avoiding adding versioned machines. > > Yeah, this was my understanding too. > > And given all the above, I think we should apply the fixes to the > stable series, and treat this as changing version (the version is > actually changed, but only the minor version). Yes, the VMs wont > be migratable between 10.0.9 and 10.0.10, exactly like it was > not-migratable between 10.0.x and 10.1.x. Because basically, with > no versioned machines, there's basically no migration capability > between different qemus *at all*. > > When we do have versioned machines, we can't add fields to previous > versions anymore, exactly because of the migration guarantees. But > as long as we don't, there's no guarantees at all. And the only > place where migration can be done is between different hosts with > the same qemu versions. > > The above description leaves one question still. What happens when > migrating from unpatched qemu to a patched qemu? Will the migration > fail due to missing field, or succeed, making the missing field to > have a default value? > > If it will succeed, then we definitely should add the field to fix > the original issue. > > BTW, can't we just skip, at the receive end, fields we don't know about? > > But all this is.. well... sort of moot for this very change already. > > I haven't realized that this discussion is about a change which I > *already* applied (I wanted to revert it until this question settles, > but I forgot to do that!). And meanwhile, I released the next set > of stable qemu releases, with the changes in question (two of them) > applied. It wasn't my intention (or else I'd not start this > discussion in the first place, obviously). > > So we do have this migration breakage already, "thanks" to my sloppiness. > > And I don't want to break things for users for no reason. The original > issue were described as a security issue even, so there's a reason to > fix it. I think. > > But in the future I'll try to be more careful about such things. > Again, understanding the machinery and consequences helps here too. That's much more my fault than yours. I nominated it for inclusion. It does sound like in future including breaking migration changes like this is ok though Alistair
