Description of problem:
[root@stor01 kvm-guests]# qemu-img info Fedora-Cloud-Base-22-20150521.x86_64.qcow2
'image' uses a qcow2 feature which is not supported by this qemu version: QCOW version 3
Could not open 'Fedora-Cloud-Base-22-20150521.x86_64.qcow2': Operation not supported
[root@stor01 kvm-guests]# rpm -qf `which qemu-img`
If it's a qcow3 image, then don't use the qcow2 suffix.
NB: this is NOT a cloud-init issue, but I can't find the right component to assign this BZ.
I don't think we have a Fedora Cloud component, yet... reassigning just to 'distribution' in the meantime (and kicking assignment over to Kushal....)
I can verify this. Downloaded http://alt.fedoraproject.org/pub/fedora/linux/releases/22/Cloud/x86_64/Images/Fedora-Cloud-Base-22-20150521.x86_64.qcow2 image.
# qemu-img info Fedora-Cloud-Base-22-20150521.x86_64.qcow2
file format: qcow2
virtual size: 3.0G (3221225472 bytes)
disk size: 218M
Format specific information:
lazy refcounts: false
The compat version is supposed to be 0.10 for qcow2 image.
One can do that by the following command (I am on Fedora 21).
# qemu-img amend -f qcow2 -o compat=0.10 Fedora-Cloud-Base-22-20150521.x86_64.qcow2
# rpm -qf `which qemu-img`
So, as Dennis has pointed out, this is a result of a qemu-img callout that koji does when qcow2 is requested as an image format. qemu-img, in turn, has defaulted to the "v3" or "enhanced v2" (whatever confusing thing you want to call it) since, I believe, around the 2.0 timeframe.
We have some code in Image Factory that determines if the qemu-img command supports the backwards compat option and, if so, uses it to ensure that the output image is qcow2 v2 compatible:
I can adapt this to a patch for koji if there is interest in that.
More urgently, is there any way we can produce an errata or additional image for those who are in an environment that does not support v3? (The issue here is that anyone whose primary environment is confused by v3 is unlikely to have an easy way to install a qemu-img command that is capable of doing the downconversion).
The raw.xz file should work as a workaround, right? Not that that's beautiful in cases where it has to be unxz'd and/or cases where sparse files aren't supported.
green - is this sol'n acceptable to you for OS1? See previous comments...
(In reply to Dan Yocum from comment #5)
> green - is this sol'n acceptable to you for OS1? See previous comments...
I tried that this AM. When I try to boot the instance it complains about there being no bootable device.
We have discussed this in Fedora Cloud WG and want to release a qcow2 v2 disk as part of our updated image release process for F22.
The openstack people would like this very much. :)
The work-around is to issue the following command on a Fedora 21 or 22 system:
qemu-img amend -f qcow2 -o compat=0.10 \
But, as Ian points out in comment 3, users confused by this may be unlikely to have an F21/22 system to run this command.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.