1 files changed, 71 insertions, 0 deletions
diff --git a/results/classifier/118/none/1859418 b/results/classifier/118/none/1859418
new file mode 100644
index 000000000..58c86b0b0
--- /dev/null
+++ b/results/classifier/118/none/1859418
@@ -0,0 +1,71 @@
+graphic: 0.738
+performance: 0.737
+x86: 0.710
+device: 0.706
+architecture: 0.631
+hypervisor: 0.618
+socket: 0.568
+user-level: 0.557
+KVM: 0.515
+semantic: 0.502
+PID: 0.501
+register: 0.495
+network: 0.468
+vnc: 0.464
+permissions: 0.460
+mistranslation: 0.446
+files: 0.418
+VMM: 0.417
+ppc: 0.415
+boot: 0.412
+risc-v: 0.409
+kernel: 0.407
+peripherals: 0.373
+virtual: 0.368
+TCG: 0.284
+arm: 0.279
+debug: 0.274
+i386: 0.257
+assembly: 0.200
+
+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.]
+