On Fri, Aug 02, 2024 at 12:40:33PM -0400, Michael S. Tsirkin wrote: > On Fri, Aug 02, 2024 at 12:26:22PM -0400, Peter Xu wrote: > > And that's why I was thinking (where I totally agree with you on this) that > > whether we should settle a short term plan first to be on the safe side > > that we start with migration always being compatible, then we figure the > > other approach. > > We have two big issues around migration compatibility we never solved: > > - some guest visible behaviour depends on a package outside of qemu: > as that package can change, so can qemu behaviour Any example, or bug link for this one? > > - sometimes we change guest visible behaviour and only > discover this after the release: fixing that breaks > migration to one version, not fixing breaks migration to another In this case it is a bug, IMHO, and not always fixable. It's like QEMU can crash and coredump, not fixable unless the user upgrades. Here "upgrades" for migration purpose means, the user should avoid migration with a broken QEMU version, and one needs to cold reboot into a new fixed binary rather than a live migration. The good thing is as long as the user doesn't trigger migration logically the bug can be avoided. The bad thing is since it's a migration bug it cannot be fixed by live migrating to a new QEMU.. AFAICT we did that before, for downstream we fix X.Y.0 with X.Y.1, then declare X.Y.0 broken, something like that. It's the same for downstream where we put into similar documentations. > > > These, to me, look similar enough that I feel we should look > at them together from QAPI POV. Or maybe I misunderstood here, in that case some elaboration of the QAPI that mentioned here could help on clarifying things. So far I don't see any QAPI command can fix a migration bug, for example, which falls into category 2 above. > > Both issues sometimes can have work-arounds, enabling these > would be nice. > Also, both issues have a clean solution, which can come in > two flavors: > 1. basic: detecting incompatibility > and not starting qemu on destination (or failing migration, > possibly early, which I consider a less clean solution). > 2. advanced: ability to go from a set of configurations to > a flag making them compatible. > > > -- > MST > Thanks, -- Peter Xu
