other: 0.172
semantic: 0.126
device: 0.092
PID: 0.081
performance: 0.081
graphic: 0.068
socket: 0.062
vnc: 0.059
permissions: 0.051
files: 0.049
debug: 0.047
network: 0.041
KVM: 0.036
boot: 0.034
KVM: 0.202
debug: 0.172
device: 0.096
other: 0.088
files: 0.073
socket: 0.065
PID: 0.064
performance: 0.055
semantic: 0.044
network: 0.038
vnc: 0.035
boot: 0.030
graphic: 0.019
permissions: 0.019

disk driver with iothread setting hangs live migrations

Per report raised at https://bugzilla.redhat.com/show_bug.cgi?id=1790093

Description of problem:

A disk driver definition using iothread parameter causes live migration with copy storage to hang during or just before the final ram sync stage.

Interestingly, having the scsi controller as a separate iothread does not trigger the issue.

Version-Release number of selected component (if applicable):

I can reproduce this on centos7 with qemu-ev and with centos 8:

qemu-kvm-ev-2.12.0-33.1.el7_7.4.x86_64
qemu-kvm-2.12.0-65.module_el8.0.0+189+f9babebb.5.x86_64

Steps to Reproduce:
1. Create a definition with 1 iothread on the disk image:

      <driver name='qemu' type='qcow2' iothread='1' />

2. Issue a live migrate request like: virsh migrate --live --copy-storage-all vm qemu+tcp://remote/system
3. Live migrate on source copies storage and then hangs at 80-99%, I guess during the ram copy phase.

Keeping exactly the same config but without the iothread on the disk driver has successful migrations every time.

Initially I suspected that https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg03048.html may have addressed this issue, but I think because you're not using backup it might not.

...Oh, qemu 2.12 is *quite old* and not supported upstream anymore. Do you have the ability to test on a more modern QEMU version?

If not, I might need to redirect you back to the RH Bugzilla for issues with the stable version they ship for RH/CentOS. I don't want to play bug tracker pingpong with you, so I'll leave this issue open (but marked "incomplete") and wait for a reply.

--js

I will try the newest version as you suggest. However please note that this is a redhat/centos 2.12 version which means it has a load of the newest patches on it so probably closer to a 4-series than real 2.12...

Mark

[Expired for QEMU because there has been no activity for 60 days.]