migration/doc: How to migrate when hosts have different features
Sometimes devices have different features depending of things outside of qemu. For instance the kernel. Document how to handle that cases. Acked-by: Peter Xu <peterx@redhat.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231018112827.1325-4-quintela@redhat.com>
This commit is contained in:
parent
1aefe2ca14
commit
593c28c02c
@ -1138,3 +1138,100 @@ machine types to have the right value::
|
|||||||
+ { "virtio-blk-device", "num-queues", "1"},
|
+ { "virtio-blk-device", "num-queues", "1"},
|
||||||
...
|
...
|
||||||
};
|
};
|
||||||
|
|
||||||
|
A device with diferent features on both sides
|
||||||
|
---------------------------------------------
|
||||||
|
|
||||||
|
Let's assume that we are using the same QEMU binary on both sides,
|
||||||
|
just to make the things easier. But we have a device that has
|
||||||
|
different features on both sides of the migration. That can be
|
||||||
|
because the devices are different, because the kernel driver of both
|
||||||
|
devices have different features, whatever.
|
||||||
|
|
||||||
|
How can we get this to work with migration. The way to do that is
|
||||||
|
"theoretically" easy. You have to get the features that the device
|
||||||
|
has in the source of the migration. The features that the device has
|
||||||
|
on the target of the migration, you get the intersection of the
|
||||||
|
features of both sides, and that is the way that you should launch
|
||||||
|
QEMU.
|
||||||
|
|
||||||
|
Notice that this is not completely related to QEMU. The most
|
||||||
|
important thing here is that this should be handled by the managing
|
||||||
|
application that launches QEMU. If QEMU is configured correctly, the
|
||||||
|
migration will succeed.
|
||||||
|
|
||||||
|
That said, actually doing it is complicated. Almost all devices are
|
||||||
|
bad at being able to be launched with only some features enabled.
|
||||||
|
With one big exception: cpus.
|
||||||
|
|
||||||
|
You can read the documentation for QEMU x86 cpu models here:
|
||||||
|
|
||||||
|
https://qemu-project.gitlab.io/qemu/system/qemu-cpu-models.html
|
||||||
|
|
||||||
|
See when they talk about migration they recommend that one chooses the
|
||||||
|
newest cpu model that is supported for all cpus.
|
||||||
|
|
||||||
|
Let's say that we have:
|
||||||
|
|
||||||
|
Host A:
|
||||||
|
|
||||||
|
Device X has the feature Y
|
||||||
|
|
||||||
|
Host B:
|
||||||
|
|
||||||
|
Device X has not the feature Y
|
||||||
|
|
||||||
|
If we try to migrate without any care from host A to host B, it will
|
||||||
|
fail because when migration tries to load the feature Y on
|
||||||
|
destination, it will find that the hardware is not there.
|
||||||
|
|
||||||
|
Doing this would be the equivalent of doing with cpus:
|
||||||
|
|
||||||
|
Host A:
|
||||||
|
|
||||||
|
$ qemu-system-x86_64 -cpu host
|
||||||
|
|
||||||
|
Host B:
|
||||||
|
|
||||||
|
$ qemu-system-x86_64 -cpu host
|
||||||
|
|
||||||
|
When both hosts have different cpu features this is guaranteed to
|
||||||
|
fail. Especially if Host B has less features than host A. If host A
|
||||||
|
has less features than host B, sometimes it works. Important word of
|
||||||
|
last sentence is "sometimes".
|
||||||
|
|
||||||
|
So, forgetting about cpu models and continuing with the -cpu host
|
||||||
|
example, let's see that the differences of the cpus is that Host A and
|
||||||
|
B have the following features:
|
||||||
|
|
||||||
|
Features: 'pcid' 'stibp' 'taa-no'
|
||||||
|
Host A: X X
|
||||||
|
Host B: X
|
||||||
|
|
||||||
|
And we want to migrate between them, the way configure both QEMU cpu
|
||||||
|
will be:
|
||||||
|
|
||||||
|
Host A:
|
||||||
|
|
||||||
|
$ qemu-system-x86_64 -cpu host,pcid=off,stibp=off
|
||||||
|
|
||||||
|
Host B:
|
||||||
|
|
||||||
|
$ qemu-system-x86_64 -cpu host,taa-no=off
|
||||||
|
|
||||||
|
And you would be able to migrate between them. It is responsability
|
||||||
|
of the management application or of the user to make sure that the
|
||||||
|
configuration is correct. QEMU doesn't know how to look at this kind
|
||||||
|
of features in general.
|
||||||
|
|
||||||
|
Notice that we don't recomend to use -cpu host for migration. It is
|
||||||
|
used in this example because it makes the example simpler.
|
||||||
|
|
||||||
|
Other devices have worse control about individual features. If they
|
||||||
|
want to be able to migrate between hosts that show different features,
|
||||||
|
the device needs a way to configure which ones it is going to use.
|
||||||
|
|
||||||
|
In this section we have considered that we are using the same QEMU
|
||||||
|
binary in both sides of the migration. If we use different QEMU
|
||||||
|
versions process, then we need to have into account all other
|
||||||
|
differences and the examples become even more complicated.
|
||||||
|
Loading…
Reference in New Issue
Block a user