Description of problem: The first time set migrate incoming failed due to wrong listening address, then try again, but failed to set the right migrate incoming for 2nd time: {"execute": "migrate-incoming", "arguments": {"uri": "tcp:10.73.130.69:4000"}, "id": "iyPg3lJW"} {"id": "iyPg3lJW", "error": {"class": "GenericError", "desc": "duplicate yank instance"}} Version-Release number of selected component (if applicable): hosts info: kernel-4.18.0-310.el8.x86_64 & qemu-kvm-6.0.0-19.module+el8.5.0+11385+6e7d542e.x86_64 How reproducible: 100% Steps to Reproduce: 1.Boot a vm on dst host with "-incoming defer" 2.Set migrate incoming on dst host, will get expected error because it should be $dst_host_ip: {"execute": "migrate-incoming", "arguments": {"uri": "tcp:$src_host_ip:4000"}, "id": "iyPg3lJW"} {"timestamp": {"seconds": 1624272064, "microseconds": 65049}, "event": "MIGRATION", "data": {"status": "setup"}} {"id": "iyPg3lJW", "error": {"class": "GenericError", "desc": "Failed to bind socket: Cannot assign requested address"}} 3.Then try again step 2 {"execute": "migrate-incoming", "arguments": {"uri": "tcp:$dst_host_ip:4000"}, "id": "iyPg3lJW"} {"id": "iyPg3lJW", "error": {"class": "GenericError", "desc": "duplicate yank instance"}} Actual results: Can't succeed setting migrate incoming for the 2nd time after the first time failed Expected results: succeed setting migrate incoming for the 2nd time after the first time failed Additional info: 1.Didn't hit such issue on host(qemu-kvm-4.2.0-52.module+el8.5.0+11386+ef5875dd.x86_64) 2.This issue should be related with yank (Bug 1956897) 3.Didn't reproduce bz on libvirt-daemon-7.4.0-1.module+el8.5.0+11218+83343022.x86_64 since libvirt haven't implemented yank(Bug 1955195)
I guess we won't meet such issue in libvirt, because when the first "migrate-incoming" fails, qemu process on dest host will be stopped by libvirt
(In reply to Fangge Jin from comment #1) > I guess we won't meet such issue in libvirt, because when the first > "migrate-incoming" fails, qemu process on dest host will be stopped by > libvirt Got it, thanks for the explanation.
Yes afree with Fangge's comments, but it is a valid bug that we should fix.
This bugs reproduces upstream.
Hi leonardo, shall we clone this bz on rhel9 since the problem also happens.
Sure(In reply to Li Xiaohui from comment #5) > Hi leonardo, shall we clone this bz on rhel9 since the problem also happens. Sure! I have sent a v1 patch upstream fixing this issue, but it is taking a while for the archives / patchwork to update. I will soon update with a patchwork link.
I needed to re-send the patch: http://patchwork.ozlabs.org/project/qemu-devel/patch/20210622033845.603512-1-leobras.c@gmail.com/ For reference, this is the patch in my qemu repo. https://gitlab.com/LeoBras/qemu/-/commit/6d22ee2a36253416c4b4f24494d06b457b1d22db
(In reply to Leonardo Bras from comment #6) > Sure(In reply to Li Xiaohui from comment #5) > > Hi leonardo, shall we clone this bz on rhel9 since the problem also happens. > > Sure! Thank you. I have filed a bz on rhel9: Bug 1974683 - Fail to set migrate incoming for 2nd time after the first time failed > > > I have sent a v1 patch upstream fixing this issue, but it is taking a while > for the archives / patchwork to update. > I will soon update with a patchwork link.
Updates: - I sent a v2 fixing a few issues from v1 (for reference only) http://patchwork.ozlabs.org/project/qemu-devel/patch/20210629050522.147057-1-leobras@redhat.com/ But as seen in comment #2 from Peter Xu, there could be a more extended solution that would fix more possible bugs. This patch series proposed by Peter can be seen here: http://patchwork.ozlabs.org/project/qemu-devel/list/?series=251186&state=%2A&archive=both This solution got accepted, which made my v2 unnecessary. The commit IDs for this patch series are: cc48c587d25ff5dd7dddb4e5072de9ca8464c832 migration: Move yank outside qemu_start_incoming_migration() b7f9afd48e7bc5c341e55348f2c2eed08314be7d migration: Allow reset of postcopy_recover_triggered when failed
Hi Leonardo, Could we get this bz on_qa before ITM 26 (Aug 30)? And I need several days to verify it. If can't, we'd better move ITM from 8.5.0 to 8.6.0, thanks.
NB: changed ITM=26 because the RHEL rule to apply release+ requires it...
QE bot(pre verify): Set 'Verified:Tested,SanityOnly' as gating/tier1 test pass.
Test this bz on hosts(kernel-4.18.0-330.el8.x86_64 & qemu-kvm-6.0.0-29.module+el8.5.0+12386+43574bac.x86_64), test pass, mark this bz verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (virt:av bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:4684