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