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-de...
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 :|