On Tue, Jul 19, 2022 at 5:24 PM Jiri Denemark <jdenemar(a)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(a)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