On Tue, Jan 05, 2021 at 09:28:27PM +0800, Keqian Zhu wrote:
Hi Daniel,
Thanks for your reply :-) Please see my words below.
On 2021/1/4 19:58, Daniel P. Berrangé wrote:
On Fri, Dec 18, 2020 at 04:38:22PM +0800, Keqian Zhu wrote:
Hi Daniel and Jiri,
On 2020/12/8 18:31, Jiri Denemark wrote:
On Tue, Dec 08, 2020 at 09:27:39 +0000, Daniel P. Berrangé wrote:
On Tue, Dec 08, 2020 at 10:06:25AM +0800, zhukeqian wrote:
On 2020/12/7 18:38, Daniel P. Berrangé wrote: > On Mon, Dec 07, 2020 at 09:55:53AM +0800, zhukeqian wrote: >> Hi Daniel,
[...]
Hi Daniel,
The purpose is to remove this failure check for QEMU v2.12. In QEMU commit 65ace0604551, it decoupled the RAM status from the active migration status.
The usage scenario is querying migration status at destination side, which may contain active migration status, but without RAM status, so we will see that libvirt report error here.
I'm confused, because AFAIK, libvirt does not need to run query-migrate on the destination, so there shouldn't be anything that needs fixing.
Moreover, you can't even request migration statistics on the destination manually because libvirt blocks that:
# virsh domjobinfo nest error: Operation not supported: migration statistics are available only on the source host
Jirka
.
Sorry for delay reply.
The purpose of QEMU commit 65ace0604551 (migration: add postcopy total blocktime into query-migrate) is to query some postcopy related information on destination side.
We can call query-migrate on destination side *after* migration complete, thanks.
But nothing in libvirt ever tries to call query-migrate on the dest side. Yes, but the dest side does not always act as dest. After migration completion, the dest side enters to a normal status and libvirt does not forbid us to query migration status.
Before QEMU commit 65ace0604551, we can successfully query the migration status, which is MIGRATION_STATUS_NONE. But this commit will return valid status (MIGRATION_STATUS_COMPLETED) without ram info, causing libvirt reports error (migration was active, but no RAM info was set).
Do you have more patches that add such calls ? If so, then please send a patch series that does the full job.
I do not add new feature to libvirt, but just manually execute query-migrate on dest side *after migration completion* will trigger this problem.
How are you running query-migrate ? If you're doing that with monitor command passthrough then we shouldn't need to change the libvirt migration code. Please can you provide the exact sequence of libvirt API calls / virsh commands you are running on both source and dest to reproduce the problem. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|