"Michael S. Tsirkin" <m...@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 <quint...@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.
