devel/migration/compatibility.rst

7 When we do migration, we have two QEMU processes: the source and the
18 Let's start with a practical example, we start with:
36 I am going to list the number of combinations that we can have.  Let's
50 This are the easiest ones, we will not talk more about them in this
53 Now we start with the more interesting cases.  Consider the case where
54 we have the same QEMU version in both sides (qemu-5.2) but we are using
72 because we have the limitation than qemu-5.1 doesn't know pc-5.2.  So
77   This migration is known as newer to older.  We need to make sure
78   when we are developing 5.2 we need to take care about not to break
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
86   than we are able to receive migrations from qemu-5.1. The problem is
90 compatibility problems.  But the reason that we create qemu-5.2 is to
93 If we get a device that has a new feature, or change a default value,
94 we have a problem when we try to migrate between different QEMU
97 So we need a way to tell qemu-5.2 that when we are using machine type
105 How do we tell QEMU about these device feature changes?  In
108 If we change a default value, we need to put back the old value on
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
115 macros that exist.  With it, we set the default value for that
117 version.  But if we want a different value for a previous version, we
133 When we are doing migration, if we migrate from a device that has 4
134 queues to a device that have only one queue, we don't know where to
135 put the extra information for the other 3 queues, and we fail
138 Similar problem when we migrate from qemu-5.1 that has only one queue
139 to qemu-5.2, we only sent information for one queue, but destination
140 has 4, and we have 3 queues that are not properly initialized and
143 So, how can we address this problem.  Easy, just convince qemu-5.2
147 That way we fix the cases 5 and 6.
163 And now the other interesting case, case 3.  In this case we have:
167     Here we have the same QEMU in both sides.  So it doesn't matter a
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:
185     migration B -> C is case 3, so we don't care.  But actually we
186     care because we haven't started the guest in qemu-5.2, it came
187     migrated from qemu-5.1.  So to be in the safe place, we need to
188     always use number of queues 1 when we are using pc-5.1.
223 Let's assume that we are using the same QEMU binary on both sides,
224 just to make the things easier.  But we have a device that has
229 How can we get this to work with migration.  The way to do that is
252 Let's say that we have:
262 If we try to migrate without any care from host A to host B, it will
289 And we want to migrate between them, the way configure both QEMU cpu
305 Notice that we don't recommend to use -cpu host for migration.  It is
312 In this section we have considered that we are using the same QEMU
313 binary in both sides of the migration.  If we use different QEMU
314 versions process, then we need to have into account all other
317 How to mitigate when we have a backward compatibility error
320 We broke migration for old machine types continuously during
321 development.  But as soon as we find that there is a problem, we fix
322 it.  The problem is what happens when we detect after we have done a
327 After the release of qemu-8.0 we found a problem when doing migration
350 In qemu-8.0 we got this commit::
375 The patch changes how we configure PCI space for AER.  But QEMU fails
391 First, we create a new property for the device to be able to configure
407 Notice that we enable the feature for new machine types.
409 Now we see how the fix is done.  This is going to depend on what kind
436 I.e. If the property bit is enabled, we configure it as we did for
437 qemu-8.0.  If the property bit is not set, we configure it as it was in 7.2.
464 Not really, now our matrix is much bigger.  We started with the easy
473 different.  For the 1st set, their fail and we can do nothing, both
474 versions are released and we can't change anything.
485 But now we found that qemu-8.0 neither can migrate to qemu-7.2 not
491 So, if we start a pc-7.2 machine in qemu-8.0 we can't migrate it to
494 Can we do better?
496 Yeap.  If we know that we are going to do this migration:
500 We can launch the appropriate devices with::
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
506 property for pc-7.2.  Notice that we need to remember, it is not
512 In the second migration, the source is not qemu-8.0, but we still have
513 that "problem" and have that property enabled.  Notice that we need to
514 continue having this mark/property until we have this machine
515 rebooted.  But it is not a normal reboot (that don't reload QEMU) we
517 on we can use the proper real machine.