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 - 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 These, to me, look similar enough that I feel we should look at them together from QAPI POV. 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
