Hi Alexander, This issue impacts upstream only since qemu-img is taken from fedora, and no impact on downstream (since qemu there is taken from rhel), right?
The only one we know for certain that is broken is qemu 3.1.X upstream. If there are downstream builds based on that, then those would be broken as well. But for now we should assume downstream works, unless proven otherwise.
We should re-assign this bug to the qemu component.
This is already fixed for qemu 4.0.x its just that fedora 30 doesn't include the 4 series yet.
Ok, then this should be marked as a duplicate of the qemu bug.
Could we catch this issue on CDI upstream to make sure we have test case to cover it.
We have added a functional test using a known image that triggered the issue. So if it happens again that test should start failing.
(In reply to Alexander Wels from comment #3) > The only one we know for certain that is broken is qemu 3.1.X upstream. If > there are downstream builds based on that, then those would be broken as > well. But for now we should assume downstream works, unless proven otherwise. Can you please provide a pointer to a public image that triggers this issue? We would like to review the problem to understand which versions are affected and have a test in RHEL as well.
Sure, so the combination of things that need to happen is pretty specific. You have to do a streaming conversion from an http source. If you download the file to a local location and then convert it works. qemu-img convert -p -O raw https://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img That particular one will start converting and usually hang around 4.7% progress. I have heard other people mention any qcow2 from an http source will exhibit the same behaviour. So this appears to happen with the 3.1.z series of qemu. We had to downgrade the version we were using to 3.0.z series in our upstream releases. We have also verified that the 4.0.0 version works as well. But we had no viable source to get it from easily (maybe Fedora 31?) In short for 3.1.z version qemu any qcow2 from http source will display the problem, but the cirros image in small and easily usable in tests.
(In reply to Alexander Wels from comment #11) > Sure, so the combination of things that need to happen is pretty specific. > You have to do a streaming conversion from an http source. If you download > the file to a local location and then convert it works. > > qemu-img convert -p -O raw > https://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img > > That particular one will start converting and usually hang around 4.7% > progress. I have heard other people mention any qcow2 from an http source > will exhibit the same behaviour. So this appears to happen with the 3.1.z > series of qemu. We had to downgrade the version we were using to 3.0.z > series in our upstream releases. We have also verified that the 4.0.0 > version works as well. But we had no viable source to get it from easily > (maybe Fedora 31?) > We have a "virt-preview" repository for Fedora which gets frequent upstream rebases. It's less stable, but might be useful: https://fedoraproject.org/wiki/Virtualization_Preview_Repository > In short for 3.1.z version qemu any qcow2 from http source will display the > problem, but the cirros image in small and easily usable in tests. This is useful info, thank you. I'll clone this BZ and ask our QE to try to reproduce it and work on a test to avoid regressions.
Verified in CNV 2.1 - the described issue wasn't reproduced in downstream.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2019:3282