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