[Bug 1859418] Re: disk driver with iothread setting hangs live migrations
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: 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] [NEW] disk driver with iothread setting hangs live migrations
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: 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: 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 1854910] [NEW] Support VHDX differencing images (ie images with backing)
Public bug reported: The qemu vhdx driver does not support type 2 (differencing) vhdx images (usually stored with file extension .avhdx). This means that any hyperv images with snapshots are not supported by qemu-img. It would be great to be able to convert to a new qcow image from a backing + set of differencing images from hyperv, and/or convert an individual differencing vhdx image to a qcow2 image with a backing file specified. ** 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/1854910 Title: Support VHDX differencing images (ie images with backing) Status in QEMU: New Bug description: The qemu vhdx driver does not support type 2 (differencing) vhdx images (usually stored with file extension .avhdx). This means that any hyperv images with snapshots are not supported by qemu-img. It would be great to be able to convert to a new qcow image from a backing + set of differencing images from hyperv, and/or convert an individual differencing vhdx image to a qcow2 image with a backing file specified. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1854910/+subscriptions
