Re: Use of 'detach' flag with QMP command `migrate` in qemuMonitorJSONMigrate()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-log-on-src.txt

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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]