11:23 a.m.
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-de...
--
/kashyap
4:02 a.m.
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 :|
5:30 a.m.
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
3343
days inactive
3344
days old
2 comments
2 participants
participants (2)
-
Daniel P. Berrange -
Kashyap Chamarthy