On Mon, Sep 28, 2015 at 10:02:48AM +0100, Daniel P. Berrange wrote:
> On Sun, Sep 27, 2015 at 06:23:15PM +0200, Kashyap Chamarthy wrote:
> > The qmp-commands.hx file from QEMU says[1]:
> >
> > "The user Monitor's "detach" argument is invalid in QMP and should
> > not be used"
>
> That does not exactly reflect reality.
Ah, so the doc should probably be reworded.
> The QMP parser permits "detach", but the qmp_migrate() method ignores
> it, and operates as if it were always set to 'true', which is what
> libvirt wants anyway.
I see. Indeed, the qmp_migrate() method in QEMU explicitly checks if
'blk' and 'inc' flags are initialized, but ignores 'detach'.
> > However, when live block migration is performed, I still see that
> > libvirt sets the 'detach' boolean to 'true':
[. . .]
> > Where 'detach' means: "not wait for completion" (reading hmp-commands.hx
> > in QEMU source) or 'QEMU_MONITOR_MIGRATE_BACKGROUND' (reading
> > qemuMonitorJSONMigrate() from qemu_monitor_json.c in libvirt source).
> >
> >
> > Two questions:
> >
> > - Should the 'detach' flag be not passed in this case, because the
> > documentation says it's not valid in QMP case?
> >
> > - _What_ exactly is setting the 'detach' flag explicitly in this case?
> > Or is it default when using 'inc' flag ('--copy-storage-inc' in
> > `virsh` parlance)?
>
> In HMP, the monitor would block until migration was completed.
Yep, I see so in hmp.c (in QEMU source), 'detach' defaults to
false.
> Passing detach=true means the monitor command completes immediately
> migration has started. Libvirt passes detach=true because it wants the
> latter behaviour which was not the default with HMP.
> We've just inherited that when we ported to QMP, even though it is
> redundant.
Noted, thanks for the clarification, Dan.
[. . .]
--
/kashyap
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list