On Fri, Jul 15, 2022 at 11:14:58 +0200, Eugenio PĂ©rez wrote:
Currently, the migration code denies migration as long as the VM has
a
vhost-vDPA device.
While it's true that vhost-vDPA devices cannot be migrated at the moment, there are
plans to be able to migrate them soon.
Libvirt must treat it equal to vhost-kernel devices: Not all of them can
be migrated (the ones that do not expose the feature VHOST_F_LOG_ALL
cannot be migrated). So checks like this one should work for all vhost
devices equally.
A more accurate solution is to ask qemu if it has an active migration
blocker at that moment. Hoever, that require synchronization to avoid
qemu to add one between the query and the actual migration command.
What would cause QEMU to add such a blocker? I believe it wouldn't do it
by itself and I hope even guest action would not cause migration blocker
to be added. Which in ideal case would mean only a QMP command (such as
hotplugging a non-migratable device) is the only way to add migration
blocker. If this is true, than we're safe as libvirt does not allow such
commands between qemuMigrationSrcIsAllowed and migration start.
That said, is there a reason for not implementing the correct solution
right away as a separate patch?
Jirka