On Mon, 29 Jan 2024 at 13:45, Fabiano Rosas <faro...@suse.de> wrote:
>
> Peter Xu <pet...@redhat.com> writes:
> > Fundamentally, IMHO it's because QEMU as a project is used both in
> > enterprise and personal emulations. I think it might be too strict to
> > always request backward migration capability if we know some device / arch
> > is only used for personal, or educational, purposes.
>
> Do we need migration support tiers? =)
We already have them. The tier list is:
* if the machine type is a versioned one, then we maintain
forwards compatibility for the versioned machine
(i.e. can migrate machine-X.Y of QEMU A.B to the
machine-X.Y of a QEMU C.D which is newer than A.B).
* if the machine type is not versioned, then we do not make
any guarantee of migration compatibility across QEMU versions.
Instead the aim is that if the user tries it it either works
or gives an error message that the migration failed
(e.g. because the version field in a VMState struct was bumped).
Migration breaks are generally called out in commit messages.
Often for machines in this tier the user is really interested
in state-save snapshots for debugging purposes, rather than
in a true cross-host-machine migration.
* some machine types do not support migration/savevm/loadvm
at all, because of devices missing VMState structs. This
is not desirable, and for new machine models we try to
ensure that they have vmstate structs as part of the minimum
quality bar, but it is true of some legacy machine types.
AIUI we, in the sense of the upstream project, do not support
backwards migration compatibility (i.e. migrating a machine-X.Y
from QEMU C.D to QEMU A.B where A.B is an older version than C.D);
though some downstreams (read: RedHat) may do so.
thanks
-- PMM
