[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 2/3] migration/docs: How to migrate when hosts have differ
|
From: |
Juan Quintela |
|
Subject: |
Re: [PATCH v3 2/3] migration/docs: How to migrate when hosts have different features |
|
Date: |
Tue, 17 Oct 2023 16:11:18 +0200 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) |
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Mon, May 15, 2023 at 10:32:00AM +0200, Juan Quintela wrote:
>> Sometimes devices have different features depending of things outside
>> of qemu. For instance the kernel. Document how to handle that cases.
>>
>> Signed-off-by: Juan Quintela <quintela@redhat.com>
>
> yes, e.g. vhost features are exactly like this.
Yeap, I know that. But not in enough detail to get a good example.
[...]
>> +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.
>
> How do people know what to do?
They need to:
- know their hardware/device/driver.
- how they can do it in qemu.
I can help with the second, not with the 1st.
> How about a tool that will help you get data from hosts
> and then tell you how to configure qemu to make them
> compatible?
This is the holy gray of migration. I would like to be able to create
machines from QMP. That way, I can transport the configuration over the
migration channel, instead of hoping that it is the same. Troubles so
far:
- we are very far away of being able to create machines with QMP (not
migration related).
- we have properties that can be different on source and destination.
For instance, the path to the file that implements a device can be
different on both systems.
We could add some keyword to the part of the configuration that can be
different. As said, we can say that destination/QMP can give us a new
path for a block device. But we need to be able to mark number of
CPU's as required to be the same.
- For devices/state that can't be seen from inside qemu, I don't know
have a good idea. It can be related that I am not an expert on that
type of devices. Perhaps someone that knows more about they can give
some insights.
Later, Juan.