Re: [PATCH] migration/docs: Explain two solutions for VMSD compatibility

[Peter Maydell]

On Mon, 29 Jan 2024 at 13:45, Fabiano Rosas <farosas@suse.de> wrote:
>
> Peter Xu <peterx@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