[Bug 1859418] [NEW] disk driver with iothread setting hangs live migrations

[Bug 1859418] [NEW] disk driver with iothread setting hangs live migrations

[Mark Zealey]

Public bug reported:

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.

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1859418

Title:
  disk driver with iothread setting hangs live migrations

Status in QEMU:
  New

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1859418/+subscriptions

[Bug 1859418] Re: disk driver with iothread setting hangs live migrations

[John Snow]

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

** Changed in: qemu
       Status: New => Incomplete

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1859418

Title:
  disk driver with iothread setting hangs live migrations

Status in QEMU:
  Incomplete

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1859418/+subscriptions

[Bug 1859418] Re: disk driver with iothread setting hangs live migrations

[Mark Zealey]

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

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1859418

Title:
  disk driver with iothread setting hangs live migrations

Status in QEMU:
  Incomplete

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1859418/+subscriptions

[Bug 1859418] Re: disk driver with iothread setting hangs live migrations

[Launchpad Bug Tracker]

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

** Changed in: qemu
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1859418

Title:
  disk driver with iothread setting hangs live migrations

Status in QEMU:
  Expired

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1859418/+subscriptions