devel/migration/compatibility.rst

23 Related to this are the "latest" machine types defined on each of
29 First of all, migration is only supposed to work if you use the same
32 Most aspects of the backend configuration can be changed at will,
36 I am going to list the number of combinations that we can have.  Let's
55 the latest machine type for that version (pc-5.2) but one of an older
60   It needs to use the definition of pc-5.1 and the devices as they
63   idea of what the pc-5.1 machine is.
111 what are we going to put in that array, the value of a property.
113 To create a property for a device, we need to use one of the
120 hw_compat_X_Y is an array of registers that have the format:
130 queue. In qemu-5.2 it has the same number of queues as the number of
144 that when it is running pc-5.1, it needs to set the number of queues
151     qemu-5.2 -M pc-5.1 sets number of queues to be 1.
152     qemu-5.1 -M pc-5.1 expects number of queues to be 1.
158     qemu-5.1 -M pc-5.1 sets number of queues to be 1.
159     qemu-5.2 -M pc-5.1 expects number of queues to be 1.
168     lot if we have set the number of queues to 1 or not, because
173     Think what happens if we do one of this double migrations:
183     migration A -> B is case 6, so number of queues needs to be 1.
188     always use number of queues 1 when we are using pc-5.1.
210 It changes the default value of num_queues.  But it fishes it for old
225 different features on both sides of the migration.  That can be
226 because the devices are different, because the kernel driver of both
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
233 features of both sides, and that is the way that you should launch
266 Doing this would be the equivalent of doing with cpus:
278 has less features than host B, sometimes it works.  Important word of
282 example, let's see that the differences of the cpus is that Host A and
301 of the management application or of the user to make sure that the
303 of features in general.
313 binary in both sides of the migration.  If we use different QEMU
327 After the release of qemu-8.0 we found a problem when doing migration
328 of the machine type pc-7.2.
359 The relevant bits of the commit for our example are this ones::
389 The relevant parts of the fix in QEMU are as follow:
409 of breakage happens, but in this case it is quite simple::
478 This two are the ones that work. The whole point of making the
506 enough to know that the source of the migration is qemu-8.0.  Think of