Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: the images produced by qemu-img sometime in the recent past changed format when you tell it to produce a qcow2 image it produces a newer format. the correct behaviour should be for qemu to produce qcow2 images for the old format and use a qcow3 format and extention for the newer format. It causes many issues. In part Images produced can not be read on RHEL6, which means many openstack installations. there is no good way we know of to detect the format produced by qemu which means we need to try and add ugly workarounds to detect what can be done or what flags need to be passed to qemu-img. the correct way for this to be dealt with is for qemu-img to do what it always has for qcow2 and introduce qcow3 This happens on all current Fedora Releases Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I'm guessing you need to use '-o compat=0.10' if you want qcow2 images readable by RHEL 6. There is a bug about this, just trying to find it ...
I can't find the other bug right now, but: https://lists.fedoraproject.org/pipermail/virt/2014-April/004041.html If you have an existing image that you wish to convert, use: qemu-img amend -o compat=0.10 -f qcow2 img.qcow2
(In reply to Dennis Gilmore from comment #0) > Description of problem: > the images produced by qemu-img sometime in the recent past changed format > when you tell it to produce a qcow2 image it produces a newer format. > FWIW the commit in qemu is: http://git.qemu.org/?p=qemu.git;a=commit;h=9117b47717ad208b12786ce88eacb013f9b3dd1c > the correct behaviour should be for qemu to produce qcow2 images for the old > format and use a qcow3 format and extention for the newer format. It causes > many issues. In part Images produced can not be read on RHEL6, which means > many openstack installations. > > there is no good way we know of to detect the format produced by qemu which > means we need to try and add ugly workarounds to detect what can be done or > what flags need to be passed to qemu-img. the correct way for this to be > dealt with is for qemu-img to do what it always has for qcow2 and introduce > qcow3 > Detecting the format is straightforward if you know what to look for: $ qemu-img create -f qcow2 1g qemu-img: 1g: Image creation needs a size parameter $ qemu-img create -f qcow2 foo.qcow2 1g Formatting 'foo.qcow2', fmt=qcow2 size=1073741824 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 [crobinso@colepc ~]$ qemu-img info foo.qcow2 image: foo.qcow2 file format: qcow2 virtual size: 1.0G (1073741824 bytes) disk size: 196K cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false The compat: 1.1 bit is what you're looking for. An old style image looks like this: $ qemu-img create -f qcow2 foo.qcow2 1g -o compat=0.10 Formatting 'foo.qcow2', fmt=qcow2 size=1073741824 compat='0.10' encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 $ qemu-img info foo.qcow2 image: foo.qcow2 file format: qcow2 virtual size: 1.0G (1073741824 bytes) disk size: 196K cluster_size: 65536 Format specific information: compat: 0.10 refcount bits: 16 There's some more details here: https://lists.fedoraproject.org/pipermail/virt/2014-April/004041.html http://blog.wikichoon.com/2014/12/virt-manager-10-creates-qcow2-images.html My suggestion is to change your qemu-img command to use -o compat=0.10 to generate images that work on RHEL6 as well. I'd wager there's zero chance that the qemu default is going to be changed back, or that the current version of qcow2 is going to be renamed qcow3, regardless of the annoyance it causes WRT RHEL6 compat
This does not work when all you have is rhel 6. The bug is in qemu. when the format changes it needs to identify it correctly
the issue we have is that in rhel 6 "-o compat=0.10" is not valid argument. kojid has no idea what qemu-img version it is running and no way to know that it needs to pass it on. qemu-img should not change in ways the breaks compatibility. we need to have a command that woks from RHEL 5 all the way though current fedora. This is a major regression and needs to be fixed.
(In reply to Dennis Gilmore from comment #5) > the issue we have is that in rhel 6 "-o compat=0.10" is not valid argument. Really wish I could find the bug or discussion about this. I'm sure there was a plan at some point to add such an argument to old qemu-img. Damn you Bugzilla! As Cole said, there's no chance that the default could be changed on RHEL 7. It would break absolutely everything.
It was this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1139707 Why not do something like this? if qemu-img create -f qcow2 -o compat=0.10 `mktemp` 1K; then compat_option_supported=yes else compat_option_supported=no fi
Actually https://bugzilla.redhat.com/show_bug.cgi?id=1139707#c8 suggests an even better way to test if the feature is supported.
You should not think of this as a different image format. The QCow2 format has the ability to define various extensions, and naturally older versions of QEMU are not guaranteed to know about new extensions. This is the same situation as ext3/4 filesystems. If you have RHEL6/7 and you format an ext4 filesystem, it is liable to have extensions enabled that make it impossible to use that ext4 filesystem on RHEL-5 since the kernel lacks knowledge of those extensions. The mkfs.ext4 command is liable to automatically enable new extensions over time, so you need to take care to explicitly ask for back compatible fs. So in both scenarios (qcow2 and ext4) if you want an image that is portable to older versions of RHEL you need to take care to explicitly ask for an image without the new extensions present. With qcow2 this is done with the flag that Rich supports. IOW, if you want to create Fedora cloud images (or other qcow2 images) that are portable to old OS, the bug report needs to be filed against the tool responsible for creating those images, not QEMU.
[dennis@ra ~]$ qemu-img --help|grep compat [dennis@ra ~]$ qemu-img --version qemu-img version 2.4.0 (qemu-2.4.0-4.fc23), Copyright (c) 2004-2008 Fabrice Bellard [dennis@ra ~]$ qemu-img create -f qcow2 -o compat=0.10 `mktemp` 1K Formatting '/tmp/tmp.bQq4BYWREx', fmt=qcow2 size=1024 compat='0.10' encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 [dennis@ra ~]$ qemu-img create -f qcow2 `mktemp` 1K Formatting '/tmp/tmp.Ld9wlVEfvo', fmt=qcow2 size=1024 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 [dennis@ra ~]$ file /tmp/tmp.bQq4BYWREx /tmp/tmp.Ld9wlVEfvo /tmp/tmp.bQq4BYWREx: QEMU QCOW Image (v2), 1024 bytes /tmp/tmp.Ld9wlVEfvo: QEMU QCOW Image (v3), 1024 bytes my issue with all of this is that the image states it is v3 so lets make things right. use qcow3 for v3 images qcow2 for v2 images.
That is a bug in the file command. The QEMU community does *not* consider there to be any such thing as qcow3. There is only the qcow2 file format. When QEMU introduced support for header extensions in qcow2, they used the version field in the qcow2 file format to indicate this. Despite the fact that the version field says '3', this is still the qcow2 file format. Calling it qcow3 is wrong.
This was Kevin's viewpoint when it was discussed (extensively) upstream a few years ago: https://www.redhat.com/archives/libvir-list/2013-March/msg00100.html