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
