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