+++ This bug was initially created as a clone of Bug #1226979 +++

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`
qemu-img-rhev-0.12.1.2-2.448.el6_6.3.x86_64


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.

--- Additional comment from Matthew Miller on 2015-06-01 11:17:49 EDT ---

I don't think we have a Fedora Cloud component, yet... reassigning just to 'distribution' in the meantime (and kicking assignment over to Kushal....)

--- Additional comment from Kushal Das on 2015-06-01 14:35:24 EDT ---

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 
image: Fedora-Cloud-Base-22-20150521.x86_64.qcow2
file format: qcow2
virtual size: 3.0G (3221225472 bytes)
disk size: 218M
cluster_size: 65536
Format specific information:
    compat: 1.1
    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`
qemu-img-2.1.3-2.fc21.x86_64

--- Additional comment from Ian McLeod on 2015-06-01 15:32:16 EDT ---

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:

https://github.com/redhat-imaging/imagefactory/blob/master/imgfac/FactoryUtils.py#L315

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).

--- Additional comment from Matthew Miller on 2015-06-01 16:20:41 EDT ---

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.

--- Additional comment from Dan Yocum on 2015-06-01 17:06:48 EDT ---

green - is this sol'n acceptable to you for OS1?  See previous comments...

--- Additional comment from Anthony Green on 2015-06-01 17:12:43 EDT ---

(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.

--- Additional comment from Dusty Mabe on 2015-06-11 14:42:56 EDT ---

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. 

See https://fedorahosted.org/cloud/ticket/94