devel/migration/compatibility.rst

7 When we do migration, we have two QEMU processes: the source and the
29 First of all, migration is only supposed to work if you use the same
77   This migration is known as newer to older.  We need to make sure
79   migration to qemu-5.1.  Notice that we can't make updates to
85   This migration is known as older to newer.  We need to make sure
133 When we are doing migration, if we migrate from a device that has 4
136 migration.
154     correct.  migration works.
161     correct.  migration works.
183     migration A -> B is case 6, so number of queues needs to be 1.
185     migration B -> C is case 3, so we don't care.  But actually we
199 The relevant parts for migration are::
225 different features on both sides of the migration.  That can be
229 How can we get this to work with migration.  The way to do that is
231 has in the source of the migration.  The features that the device has
232 on the target of the migration, you get the intersection of the
239 migration will succeed.
249 See when they talk about migration they recommend that one chooses the
263 fail because when migration tries to load the feature Y on
305 Notice that we don't recommend to use -cpu host for migration.  It is
313 binary in both sides of the migration.  If we use different QEMU
320 We broke migration for old machine types continuously during
327 After the release of qemu-8.0 we found a problem when doing migration
332   This migration works
336   This migration works
340   This migration fails
344   This migration fails
346 So clearly something fails when migration between qemu-7.2 and
448          { "virtio-mem", "x-early-migration", "false" },
449          { "migration", "x-preempt-pre-7-2", "true" },
465 cases, migration from the same version to the same version always
496 Yeap.  If we know that we are going to do this migration:
504 And now we can receive a migration from 8.0.  And from now on, we can
505 do that migration to new machine types if we remember to enable that
507 enough to know that the source of the migration is qemu-8.0.  Think of
512 In the second migration, the source is not qemu-8.0, but we still have