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. 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.
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)?
In HMP, the monitor would block until migration was completed. 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.
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...
Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|