The qmp-commands.hx file from QEMU says[1]:
"The user Monitor's "detach" argument is invalid in QMP and should
not be used"
However, when live block migration is performed, I still see that
libvirt sets the 'detach' boolean to 'true':
[. . .]
2015-04-09 11:20:54.160+0000: 12152: debug : qemuMonitorJSONCommandWithFd:290 : Send command '{"execute":"migrate","arguments":{"detach":true,"blk":true,"inc":false,"uri":"fd:migrate"},"id":"libvirt-18"}' for write with FD -1
[. . .]
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)?
Contextual libvirtd.log from source, with log_filter for 'qemu' set[2].
Note that in the above case, live block migration _did_ succeed, I'm
just asking this to educate myself.
PS: If you're wondering why am I not using the new 'drive-mirror' based
approach above, I performed this block migration via OpenStack Nova.
Currently in Nova's case, live block migration falls back to the old
approach of QMP `migrate` command (with 'inc' flag set to true -- it
explicitly set by OpenStack Nova) via qemuMonitorJsonMigrate(), and
not the new way of qemuMonitorJSONDriveMirror().
I was testing with:
- libvirt-daemon-driver-qemu-1.2.13.1-2.fc22.x86_64
- qemu-system-x86-2.3.1-1.fc22.x86_64
[1] http://git.qemu.org/?p=qemu.git;a=blob;f=qmp-commands.hx#l643
[2] https://kashyapc.fedorapeople.org/virt/temp/live-blk-migration-libvirt-debug-log-on-src.txt
--
/kashyap
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list