<div dir="ltr"><div>Software in use:<br><br><i>Source hypervisor:</i> <b>Qemu:</b> stable-2.12 branch <b>Libvirt</b>: v3.2-maint branch <b>OS</b>: CentOS 6</div><div><i>Destination hypervisor: </i><b>Qemu:</b> stable-2.12 branch <b>Libvirt</b>: v4.9-maint branch <b>OS</b>: CentOS 7</div><div><br></div>I'm experiencing an intermittent live migration hang of a virtual machine (KVM) with a ceph RBD volume attached.<div><br><div>At the high level what I see is that when this does happen, the virtual machine is left in a paused state (per virsh list) on both source and destination hypervisors indefinitely.<br></div><div><br>Here's the virsh command I am running on the source (where 10.30.76.66 is the destination hypervisor):</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">virsh migrate --live --copy-storage-all --verbose --xml /root/live_migration.cfg test_vm qemu+ssh://<a href="http://10.30.76.66/system">10.30.76.66/system</a> tcp://<a href="http://10.30.76.66">10.30.76.66</a></blockquote><div><br></div><div>Here it is in "ps faux" while its in the hung state:<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">root     10997  0.3  0.0 380632  6156 ?        Sl   12:24   0:26          \_ virsh migrate --live --copy-storage-all --verbose --xml /root/live_migration.cfg test_vm qemu+ssh://<a href="http://10.30.76.66/sys">10.30.76.66/sys</a><br>root     10999  0.0  0.0  60024  4044 ?        S    12:24   0:00              \_ ssh 10.30.76.66 sh -c 'if 'nc' -q 2>&1 | grep "requires an argument" >/dev/null 2>&1; then ARG=-q0;else ARG=;fi;'nc' $ARG -U</blockquote> </div><div>The only reason i'm using the `--xml` arg is so the auth information can be updated for the new hypervisor (I setup a cephx user for each hypervisor). Below is a diff between my normal xml config and the one I passed in --xml arg to illustrate:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">60,61c60,61<br><       <auth username="source"><br><               <secret type="ceph" uuid="d4a47178-ab90-404e-8f25-058148da8446"/><br>---<br>>       <auth username="destination"><br>>               <secret type="ceph" uuid="72e9373d-7101-4a93-a7d2-6cce5ec1e6f1"/></blockquote><div><br></div><div>The libvirt secret as shown above is properly setup with good credentials on both source and destination hypervisors. </div><div><br>When this happens, I don't see anything logged on the destination hypervisor in the libvirt log. However in the source hypervisors log, I do see this:<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">2019-06-21 12:38:21.004+0000: 28400: warning : qemuDomainObjEnterMonitorInternal:3764 : This thread seems to be the async job owner; entering monitor without asking for a nested job is dangerous</blockquote><div><br></div><div>But nothing else logged in the libvirt log on either source or destination. The actual `virsh migrate --live` command pasted above still runs while stuck in this state, and it just outputs "Migration: [100 %]" over and over. If I strace the qemu process on the source, I see this over and over:<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">ppoll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=15, events=POLLIN}, {fd=18, events=POLLIN}, {fd=19, events=POLLIN}, {fd=35, events=0}, {fd=35, events=POLLIN}], 9, {0, 14960491}, NULL, 8) = 0 (Timeout)</blockquote><div><br></div><div>Here's those fds:<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[root@source ~]# ll /proc/31804/fd/{8,4,6,15,18,19,35}<br>lrwx------ 1 qemu qemu 64 Jun 21 13:18 /proc/31804/fd/15 -> socket:[931291]<br>lrwx------ 1 qemu qemu 64 Jun 21 13:18 /proc/31804/fd/18 -> socket:[931295]<br>lrwx------ 1 qemu qemu 64 Jun 21 13:18 /proc/31804/fd/19 -> socket:[931297]<br>lrwx------ 1 qemu qemu 64 Jun 21 13:18 /proc/31804/fd/35 -> socket:[931306]<br>lrwx------ 1 qemu qemu 64 Jun 21 13:18 /proc/31804/fd/4 -> [signalfd]<br>lrwx------ 1 qemu qemu 64 Jun 21 13:18 /proc/31804/fd/6 -> [eventfd]<br>lrwx------ 1 qemu qemu 64 Jun 21 13:18 /proc/31804/fd/8 -> [eventfd]<br>[root@source ~]#  <br> <br>[root@source ~]# grep -E '(931291|931295|931297|931306)' /proc/net/tcp<br>   3: 00000000:170C 00000000:0000 0A 00000000:00000000 00:00000000 00000000   107        0 931295 1 ffff88043a27f840 99 0 0 10 -1                    <br>   4: 00000000:170D 00000000:0000 0A 00000000:00000000 00:00000000 00000000   107        0 931297 1 ffff88043a27f140 99 0 0 10 -1                    <br>[root@source ~]# </blockquote></div></div> </div></div><div>Further, on the source, if I query the blockjobs status, it says no blockjob is running:<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[root@source ~]# virsh list<br> Id    Name                           State<br>----------------------------------------------------<br> 11    test_vm                         paused<br>[root@source ~]# virsh blockjob 11 vda<br>No current block job for vda<br>[root@source ~]# </blockquote><div><br></div><div>and that nc/ssh connection is still ok in the hung state:<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[root@source~]# netstat -tuapn|grep \.66<br>tcp        0      0 <a href="http://10.30.76.48:48876">10.30.76.48:48876</a>           <a href="http://10.30.76.66:22">10.30.76.66:22</a>              ESTABLISHED 10999/ssh          <br> [root@source ~]# <br>root     10999  0.0  0.0  60024  4044 ?        S    12:24   0:00              \_ ssh 10.30.76.66 sh -c 'if 'nc' -q 2>&1 | grep "requires an argument" >/dev/null 2>&1; then ARG=-q0;else ARG=;fi;'nc' $ARG -U /var/run/libvirt/libvirt-sock' </blockquote></div><div><br></div><div>Here's the state of the migration on source while its stuck like this:<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[root@source ~]# virsh qemu-monitor-command 11 '{"execute":"query-migrate"}'<br>{"return":{"status":"completed","setup-time":2,"downtime":2451,"total-time":3753,"ram":{"total":2114785280,"postcopy-requests":0,"dirty-sync-count":3,"page-size":4096,"remaining":0,"mbps":898.199209,"transferred":421345514,"duplicate":414940,"dirty-pages-rate":0,"skipped":0,"normal-bytes":416796672,"normal":101757}},"id":"libvirt-317"}<br>[root@source ~]# </blockquote><div><br></div><div>I'm unable the run the above command on the destination while its in this state however, and get a lock error (which could be expected perhaps, since it never cutover to the source yet):<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[root@destination ~]# virsh list<br> Id   Name     State  <br> -----------------------<br> 4    test_vm   paused  <br>[root@destination ~]# virsh qemu-monitor-command 4 '{"execute":"query-migrate"}'<br>error: Timed out during operation: cannot acquire state change lock (held by monitor=remoteDispatchDomainMigratePrepare3Params)<br>[root@destination ~]# </blockquote> </div></div><div><br></div><div>Does anyone have any pointers of other things I should check? Or if this was/is a known bug in perhaps the old stable-3.2?</div><div><br></div><div>I haven't seen this when migrating on a host with libvirt 4.9 on both source and destinations. However the ones I have with the older 3.2 are centos 6 based, and aren't as easily upgraded to 4.9. Or, if anyone has ideas of patches I could potentially look to port to 3.2 to mitigate this, that would also be welcome. Would also be interested in forcing the cutover in this state if possible, though I suspect that isn't safe since the block-job isnt running while in this bad state.<br><br></div></div><div>Thanks in advance</div></div>