On Tue, Jul 19, 2022 at 5:24 PM Jiri Denemark <jdenemar@redhat.com> wrote:
On Tue, Jul 19, 2022 at 17:09:29 +0200, Eugenio Perez Martin wrote:
On Tue, Jul 19, 2022 at 4:02 PM Laine Stump <laine@laine.org> wrote:
Actually that's been on my todo list for a long time - for any qemu that supports the QMP command that checks for migratability, we should be calling this command rather than checking against our own internal list (which is really just an "informed guess") of what can't be migrated. This way we'll always get the right answer (or at least what QEMU believes to be the right answer :-)). Fixing it this way will also mean that migration of VFIO devices will just "magically" start working once a migration-supporting driver is written for the device, and the correct vfio driver is bound to the device (this latter item is also on my list).
So if you're up for making the patch to call the QMP command, I'd be happy to review it!
Thanks! Actually I'd need some guidance first, I'm not very used to libvirt code.
As I understand I should create a function in qemu_agent.h/c, a getter similar to qemuAgentGetFSInfo. How can I get a qemuAgent from qemuMigrationSrcIsAllowed? I only have a virQEMUDriver there.
I hope we don't need to ask the guest agent to get migration blockers as that would be pretty much a show stopper for us. What is the exact way of getting the info from QEMU?
Sorry, I confused "agent" with the QMP here. This is an example response with a migration blocker: <- '{ "execute": "query-migrate" }' -> {"return": {"blocked-reasons": ["Migration disabled: vhost lacks VHOST_F_LOG_ALL feature."]}} There is no member "blocked-reasons" in case no blocker is registered in qemu.
Jirka