Bug 1049380

 Image cf459b65-a3e8-4b2d-a4cd-344bd2aa793a is unacceptable: Size is 20GB and doesn't fit in a volume of size 4GB.

Please try to create a larger size volume and see if you get an error.

Created attachment 879033 [details]
Cinder volume.log

Description of problem:

Create volume from an image (iso or qcow2) status -> error, both Glance and Cinder use Gluster. Empty volume is created with status available, tested from Horizon and CLI.

# cinder --debug create 2 --image-id 8fcae10f-9cb8-4609-b835-a82d87bbd60a --display-name volZevel 

[root@orange-vdse glance(keystone_admin)]# cinder list
+--------------------------------------+-----------+--------------+------+-------------+----------+-------------+
|                  ID                  |   Status  | Display Name | Size | Volume Type | Bootable | Attached to |
+--------------------------------------+-----------+--------------+------+-------------+----------+-------------+
| 2ae7afdf-520d-4b03-ac6c-3337295b4233 |   error   |   volZevel   |  2   |     None    |  false   |             |
| 7fff0bb0-5177-44fb-be26-7e5cd655e82b |   error   |  volfromUI   |  1   |     None    |  false   |             |
| d0df18b9-985b-455c-b513-eca12a19db8c | available |     None     |  2   |     None    |  false   |             |
| fe1efdc8-5277-40a8-beeb-57af1f3a41ed | available |   volEmpty   |  2   |     None    |  false   |             |
+--------------------------------------+-----------+--------------+------+-------------+----------+-------------+

Source images are tiny, both should fit in 1Giga volumes. 
[root@orange-vdse cinder(keystone_admin)]# glance image-list
+--------------------------------------+------------+-------------+------------------+----------+--------+
| ID                                   | Name       | Disk Format | Container Format | Size     | Status |
+--------------------------------------+------------+-------------+------------------+----------+--------+
| 8fcae10f-9cb8-4609-b835-a82d87bbd60a | cirrosclie | qcow2       | bare             | 9761280  | active |
| 5c429d2a-c9a7-4bb7-b55f-924ceeb16778 | iso        | iso         | bare             | 52328448 | active |
+--------------------------------------+------------+-------------+------------------+----------+--------+



Versions:
 RHEL 7 
 openstack-cinder-2014.1-0.6.b3.el7.noarch
 openstack-glance-2014.1-0.4.b3.el7.noarch

How reproducible:
100%

Steps to Reproduce:
1. create an image
2. create an empty volume, works ok status available
3. Create volume from uploaded image, status error.

Actual results:
Volume created from image status=error

Expected results:
Volume status should be available.

Attached cinder's volume.log

I am seeing this same problem but with Ceph backend.  

I have crated volume size of 40gb but the logs report it 1gb.

the work around for me is to great a volume in the UI that has the image already copied then create a instance and then have to attach to the volume to boot.

There something odd with something passing a static 1gb size for volume on copy.

I just saw a not the on copy to volume the qcow2 image may be converted from qcow2 over to raw making the image way to big.

In order to create and export a block device from an image, the image must be converted to RAW.  So this seems like what you would expect, and I don't feel it's a bug.  But perhaps I'm misunderstanding, what is the behaviour you expect?

This isn't a bug.  This is the same issue as described in bug 1096144.

The problem is that Glance's image-list is showing the size of the image "file" rather than the virtual image size.  What matters for conversion into a volume is the virtual image size, which is unfortunately not known until conversion time.

I'll add that upstream glance is working on adding support for this in the Juno cycle, so this could be revisited (on the cinder side) once that occurs.  At the moment, however, this is expected behaviour.

This is unresolved in Juno (glance still reports the underlying file size rather than the image virtual size), but https://github.com/openstack/glance/commit/5dd82abb74628a46ee6cd8ad619d1b8dda2a3a81 looks like a first step to solving this problem.