On Tue, Jul 19, 2022 at 5:24 PM Jiri Denemark <jdenemar@xxxxxxxxxx> 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@xxxxxxxxx> 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
>
