On Wed, Oct 23, 2019 at 11:32:14AM +0800, cenjiahui wrote: > From: Jiahui Cen <cenjia...@huawei.com> > > 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. > Signed-off-by: Jiahui Cen <cenjia...@huawei.com> > Signed-off-by: Ying Fang <fangyi...@huawei.com> 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 :|
