qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 3/3] migration/multifd: fix potential wrong acception order o


From: cenjiahui
Subject: Re: [PATCH 3/3] migration/multifd: fix potential wrong acception order of IOChannel
Date: Thu, 24 Oct 2019 21:53:24 +0800
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2

On 2019/10/24 17:52, Daniel P. Berrangé wrote:
> On Wed, Oct 23, 2019 at 11:32:14AM +0800, cenjiahui wrote:
>> From: Jiahui Cen <address@hidden>
>>
>> Multifd assumes the migration thread IOChannel is always established before
>> the multifd IOChannels, but this assumption will be broken in many situations
>> like network packet loss.
>>
>> For example:
>> Step1: Source (migration thread IOChannel)  --SYN-->  Destination
>> Step2: Source (migration thread IOChannel)  <--SYNACK  Destination
>> Step3: Source (migration thread IOChannel, lost) --ACK-->X  Destination
>> Step4: Source (multifd IOChannel) --SYN-->    Destination
>> Step5: Source (multifd IOChannel) <--SYNACK   Destination
>> Step6: Source (multifd IOChannel, ESTABLISHED) --ACK-->  Destination
>> Step7: Destination accepts multifd IOChannel
>> Step8: Source (migration thread IOChannel, ESTABLISHED) -ACK,DATA->  
>> Destination
>> Step9: Destination accepts migration thread IOChannel
>>
>> The above situation can be reproduced by creating a weak network environment,
>> such as "tc qdisc add dev eth0 root netem loss 50%". The wrong acception 
>> order
>> will cause magic check failure and thus lead to migration failure.
>>
>> This patch fixes this issue by sending a migration IOChannel initial packet 
>> with
>> a unique id when using multifd migration. Since the multifd IOChannels will 
>> also
>> send initial packets, the destination can judge whether the processing 
>> IOChannel
>> belongs to multifd by checking the id in the initial packet. This mechanism 
>> can
>> ensure that different IOChannels will go to correct branches in our test.
> 
> Isn't this going to break back compatibility when new QEMU talks to old
> QEMU with multifd enabled ? New QEMU will be sending a packet that old
> QEMU isn't expecting IIUC.

Yes, it actually breaks back compatibility. But since the old QEMU has bug with
multifd, it may be not suitable to use multifd to migrate from new QEMU to old
QEMU in my opinion.

Hi, Quintela, how do you think about this ?

> 
>> Signed-off-by: Jiahui Cen <address@hidden>
>> Signed-off-by: Ying Fang <address@hidden>

Regards,
Jiahui Cen




reply via email to

[Prev in Thread] Current Thread [Next in Thread]