On 2021/1/5 21:34, Daniel P. Berrangé wrote:
> 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.
OK. I am not very familiar with libvirt code logic, and my work flow is:
source side dest side
virsh start domain_name |
| |
virsh migrate --live domain_name (wait for migrate complete)
| |
(migrate complete) |
virsh domjobinfo domain_name
|
(migration was active, but no RAM info was set)
Hope the above work flow helps.
Thanks,
Keqian
>
> 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
>
