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