ImageUnacceptable: Image is unacceptable: 'qemu-img info' parsing failed

Getting same error when tried to launch instance from Dashboard of devstack master.

Error: Failed to perform requested operation on instance "inst5", the instance has an error status: Please try again later [Error: Build of instance 359a93f5-ecbf-4c74-a15f-618d693a99c1 aborted: Image e77840d9-1978-4660-98e0-1f5bf33b9e3a is unacceptable: 'qemu-img info' parsing failed.].

I am also getting the error after launching Instance .

Error : InvalidDiskInfo: Disk info file is invalid: qemu-img failed
GET call to image for http://172.30.64.43/image/v2/images/cirros-0.3.5-x86_64-disk used request id req-fdbe0031-7a91-4311-9ada-f13fb6a511a5
Request returned failure status 404.

Systemctl status <email address hidden>

Stderr: u"qemu-img: Could not open '/var/lib/libvirt/images/generic.qcow2': Could not open '/var/lib/

Note : version Pike

Thanks for including the traceback paste.

Looking at this, the error is being raised because the fmt.file_format of the parsed command output is None:

https://github.com/openstack/nova/blob/stable/queens/nova/virt/images.py#L162

and that attribute comes from the oslo_utils.imageutils parsing:

https://github.com/openstack/oslo.utils/blob/stable/queens/oslo_utils/imageutils.py#L65

So, this implies that the output of the 'qemu-img info' command doesn't have 'file format' in it. But we aren't logging the command output, so we don't know what it looks like ...

Just some added information. stable/queens devstack build. Error only when creating a new instance from the openstack CLI:
Build of instance c6b46fc3-8f80-449d-a1a7-93be661a6166 aborted: Image 64325b6e-e625-4838-8f9d-7b54fff2506c is unacceptable: 'qemu-img info' parsing failed.
Code
500
Details
File "/opt/stack/nova/nova/compute/manager.py", line 1840, in _do_build_and_run_instance filter_properties, request_spec) File "/opt/stack/nova/nova/compute/manager.py", line 2108, in _build_and_run_instance reason=e.format_message())
Created
April 11, 2018, 2:24 p.m.

I can create in the dashboard with no errors, using the same image, flavor and network.

I hit this because I had a backlevel qemu-utils compared to what devstack installs in our gate jobs. Devstack installs cloud-archive:pike when deploying queens and installs qemu-utils from there. If you're on xenial and getting qemu-utils from the base distro, this may be your problem.

Note that the problem is that nova calls qemu-img info with --force-shared, which isn't in older versions, and thus it explodes without even looking at the image.

I tried a test with an older version of qemu-img in devstack and found that if the version of qemu-img does not recognize the --force-share flag, it will anyway return 0, so that explains how the bug reporter saw "returned 0" and still got the failure:

$ qemu-img info --force-share /opt/stack/data/nova/instances/_base/3d3fa687799a973799cb7f263839457ba63c3e2f
info: unrecognized option '--force-share'
qemu-img version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.31), Copyright (c) 2004-2008 Fabrice Bellard
usage: qemu-img command [command options]
QEMU disk image utility
...

$ echo $?
0

We have code that checks for the qemu version to determine whether or not the --force-share flag is available:

https://github.com/openstack/nova/blob/stable/queens/nova/virt/images.py#L49-L72

but somehow, that check is not working properly and is sending the --force-share flag anyway.

do you have any solution ? ı am getting same errors on pike.

What version of qemu-utils are people using when they hit this? It looks like --force-shared should only be used with qemu>=2.10.

(2:30:15 PM) dansmith: mriedem: pretty sure that the issue was that we installed something, got qemu-utils=something, then upgraded to cloud archive, got a new qemu, but it was fine with the older qeu-utils, and didn't upgrade it
(2:31:00 PM) mriedem: dansmith: ah ok, so qemu could be 2.10 but qemu-utils could be 2.5 or something
(2:31:01 PM) dansmith: meaning qemu==N doesn't require qemu-utils==N, just qemu-utils==anything
(2:31:04 PM) dansmith: right
(2:31:04 PM) mriedem: yeah

I guess one thing we could do is if we run with --force-share and we don't get an error, we could check the stdout/err output for "unrecognized option '--force-share'" and if we find that, we need to run it again without --force-share (the version check was meant to handle that for us, but qemu-img and qemu-utils could be different package versions...).

ImageUnacceptable: Image f083653d-e3bd-46d9-8e89-7ec031d0b8f3 is unacceptable: Image virtual size is 8GB and doesn't fit in a volume of size 1GB.

Are there any updates on the status of this ? I'm experiencing the same behavior in my Queens deployment.