Re: [libvirt] Use of 'detach' flag with QMP command `migrate` in qemuMonitorJSONMigrate()
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+: 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@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Use of 'detach' flag with QMP command `migrate` in qemuMonitorJSONMigrate()
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
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Use of 'detach' flag with QMP command `migrate` in qemuMonitorJSONMigrate()
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+: 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@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
