Description of problem: CloudForms is unable to smartstate QEMU images created by qemu-img-rhev package on RHEL 7 with compat version 0.11. Images must be converted using qemu-img convert -O qcow2 -o compat=0.10 for them to be smartstate-able in latest CloudForms. Version-Release number of selected component (if applicable): 5.3.2.6.20150108100920_387a856 How reproducible: Always Steps to Reproduce: 1. Create or Convert a template using qemu-img on RHEL 7 with qemu-img-rhev latest installed 2. Attempt to smartstate said image 3. Actual results: SmartState analysis silently fails for the UI user. evm log has lines such as the following: [----] E, [2015-02-12T21:45:24.787194 #50082:6ec83c] ERROR -- : Q-task_id([333f987e-b300-11e4-9638-001a4ad53400]) action-abort: job aborting, Uknown Version: 3 - /tmp/hwd1-windows-2012r2.x6420150212-50082 -izsr0o [----] I, [2015-02-12T21:45:24.794263 #50082:6ec83c] INFO -- : Q-task_id([333f987e-b300-11e4-9638-001a4ad53400]) action-finished: job finished, Uknown Version: 3 - /tmp/hwd1-windows-2012r2.x6420150212-50 082-izsr0o Expected results: Image is successfully smartstated Additional info: This can be worked around by coverting the image like so: qemu-img convert -O qcow2 -o compat=0.10 <original_image> <new_image> It is important to recognize that this is the new default compat version for RHEL 7. The upshot is that anyone who creates an Image "snapshot" in OpenStack using Juno or later will experience this problem. That said, the rhel-guest-image-{6|7} images seem to be fine right now. Lastly, here is the qemu-img info for a broken image: [root@hwd1-oscon-01 ~(keystone_admin)]# qemu-img info hwd1-windows-2012r2.x64.qcow2 image: hwd1-windows-2012r2.x64.qcow2 file format: qcow2 virtual size: 40G (42949672960 bytes) disk size: 16G cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false And here it is for a good image which has been converted: [root@hwd1-oscon-01 ~(keystone_admin)]# qemu-img info hwd1-windows-2012r2.x64-dave.qcow2 image: hwd1-windows-2012r2.x64-dave.qcow2 file format: qcow2 virtual size: 40G (42949672960 bytes) disk size: 16G cluster_size: 65536 Format specific information: compat: 0.10
Should this be compat = 1.1? As in your qemu-img info output. 0.11 results in an error locally where as 1.1 does not $ qemu-img create -f qcow2 -o compat=0.11 foo.img 1M Formatting 'foo.img', fmt=qcow2 size=1048576 compat='0.11' encryption=off cluster_size=65536 lazy_refcounts=off Invalid compatibility level: '0.11' qemu-img: foo.img: error while creating qcow2: Invalid argument $ qemu-img create -f qcow2 -o compat=1.1 foo.img 1M Formatting 'foo.img', fmt=qcow2 size=1048576 compat='1.1' encryption=off cluster_size=65536 lazy_refcounts=off
It should be "-o compat=0.10" my bad on that type-o.
"0.10" isn't an issue, can run that fine. I can't use "0.11" though and was wondering if that should be "1.1" as indicated in your output.
Definitely not 1.1. The issue is with smart state analysis of images created with the 1.1 compat level. Apparently, this is the default for RHEL 7, at least in OpenStack Juno. NOTE: this did not affect rhel-guest-image-* packages. Only new templates created on RHEL 7. This may also RHEV, but I am unsure about that at this time.
(In reply to david.costakos from comment #6) > The issue is with smart state analysis of images created with the 1.1 compat level. Yes but the bug subject and description state "0.11" not "1.1" No worries, will test with "1.1" going forward (would update the issue though)
Filed PR #2000 containing the fix https://github.com/ManageIQ/manageiq/pull/2000
PR merged
Verified with 5.4.0.0.24.20150427192818_1fd9e49
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://rhn.redhat.com/errata/RHBA-2015-1100.html