Description of problem: when migrate with not same multi-fd channel on src and dst host, src host qemu will wait for migration forever, and execute migrate_cancel, qemu on dst host will get stuck and won't quit by auto. Version-Release number of selected component (if applicable): host info: kernel-4.18.0-108.el8.x86_64 & qemu-img-4.0.0-4.module+el8.1.0+3356+cda7f1ee.x86_64 guest info: kernel-4.18.0-108.el8.x86_64 How reproducible: 100% Steps to Reproduce: 1.when migrate with only changing multifd-channels to 4 on src host(multifd-channels is 2 on dst host qemu), I met two situations: a.on src host qemu, migration status of guest is setup waiting for 20mins. and on dst host qemu, migration status of guest is active(and multifd threads exist on dst host), so strange. And after 20mins, execute migrate_cancel, qemu on dst host will get stuck and won't quit by auto, what's more, qemu process still runs on dst host. b.when start migration, qemu on dst host core dump immediately. 2. 3. Actual results: as above Expected results: when migrate guest with different multifd-channels on src&dst host, migration should fail or give right prompt in qemu. Additional info:
This is a feature, not a failure. You need to setup the same number of channels for both sides. About migration cancel, there has been a new series upstream that improve that. Improving the error message upstream, but not important. Thanks a lot.
QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Approve close this bz as WONTFIX as libvirt doesn't reproduce this bz.