Created attachment 893929 [details] logs Description of problem: I tried creating a 5GB volume from a qcow image which is reported as 666M root@orange-vdsf images(keystone_admin)]# qemu-img info 571a0217-838b-445e-a84b-e651fc4fc479 image: 571a0217-838b-445e-a84b-e651fc4fc479 file format: qcow2 virtual size: 6.0G (6442450944 bytes) disk size: 666M cluster_size: 65536 Format specific information: compat: 0.10 we fail to create the volume with: Image 571a0217-838b-445e-a84b-e651fc4fc479 is unacceptable: Size is 6GB and doesn't fit in a volume of size 5GB Version-Release number of selected component (if applicable): [root@orange-vdsf images(keystone_admin)]# rpm -qa |grep cinder openstack-cinder-2014.1-3.el7ost.noarch python-cinderclient-1.0.8-1.el7ost.noarch python-cinder-2014.1-3.el7ost.noarch How reproducible: 100% Steps to Reproduce: 1. download a qcow image 2. try to create a new volume from the image when the volume size is smaller than the image's virtual size 3. Actual results: we fail to create the volume Expected results: we should succeed to create the volume. Additional info: logs 2014-05-09 12:32:22.235 26019 ERROR oslo.messaging._drivers.common [req-52a2d89a-29a0-43fa-9d7e-adafe5186a6f c9062d562d9f41e4a1fdce36a4f176f6 4ad766166539403189f2caca1ba306aa - - -] ['Traceback (most recent call last):\n', ' File "/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py", line 133, in _dispatch_and_reply\n incoming.message))\n', ' File "/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py", line 176, in _dispatch\n return self._do_dispatch(endpoint, method, ctxt, args)\n', ' File "/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py", line 122, in _do_dispatch\n result = getattr(endpoint, method)(ctxt, **new_args)\n', ' File "/usr/lib/python2.7/site-packages/cinder/volume/manager.py", line 363, in create_volume\n _run_flow()\n', ' File "/usr/lib/python2.7/site-packages/cinder/volume/manager.py", line 356, in _run_flow\n flow_engine.run()\n', ' File "/usr/lib/python2.7/site-packages/taskflow/utils/lock_utils.py", line 51, in wrapper\n return f(*args, **kwargs)\n', ' File "/usr/lib/python2.7/site-packages/taskflow/engines/action_engine/engine.py", line 118, in run\n self._run()\n', ' File "/usr/lib/python2.7/site-packages/taskflow/engines/action_engine/engine.py", line 128, in _run\n self._revert(misc.Failure())\n', ' File "/usr/lib/python2.7/site-packages/taskflow/engines/action_engine/engine.py", line 81, in _revert\n misc.Failure.reraise_if_any(failures.values())\n', ' File "/usr/lib/python2.7/site-packages/taskflow/utils/misc.py", line 487, in reraise_if_any\n failures[0].reraise()\n', ' File "/usr/lib/python2.7/site-packages/taskflow/utils/misc.py", line 494, in reraise\n six.reraise(*self._exc_info)\n', ' File "/usr/lib/python2.7/site-packages/taskflow/engines/action_engine/executor.py", line 36, in _execute_task\n result = task.execute(**arguments)\n', ' File "/usr/lib/python2.7/site-packages/cinder/volume/flows/manager/create_volume.py", line 594, in execute\n **volume_spec)\n', ' File "/usr/lib/python2.7/site-packages/cinder/volume/flows/manager/create_volume.py", line 556, in _create_from_image\n image_id, image_location, image_service)\n', ' File "/usr/lib/python2.7/site-packages/cinder/volume/flows/manager/create_volume.py", line 463, in _copy_image_to_volume\n raise exception.ImageUnacceptable(ex)\n', "ImageUnacceptable: Image 571a0217-838b-445e-a84b-e651fc4fc479 is unacceptable: Size is 6GB and doesn't fit in a volume of size 5GB.\n"] 2014-05-09 12:32:34.428 26019 DEBUG cinder.openstack.common.periodic_task [-] Running periodic task VolumeManager._publish_service_capabilities run_periodic_tasks /usr/lib/python2.7/site-packages/cinder/openstack/common/periodic_task.py:178
'virtual size: 6.0G (6442450944 bytes)' The raw disk size matters, not the qcow file size. Is it working with 6 or 7 GiB volume ?
1. there should not be raw size on a qcow image when we copy the image to a volume. 2. virtual size should not be considered as raw (so we should not zero based on virtual size but only copy the actual written data - which is a valid option if we for example, use qemu-img to do that). 3. of course we can create a larger volume than the virtual size of the image :) this is not related to this bug - what I am saying is that we should be able to create a volume based on the actual size and not the virtual size and that how we copy the information from the image should allow that.
This is not a bug. If the disk image has a 6 GB virtual size, you must create a Cinder volume of at least that size or the data may be truncated. disk size: 666M only indicates that 666MB of data has been written into that 6GB. But you don't know where it has been written. Cinder can't arbitrarily shrink the volume size to 666MB when the source is a 6GB image, even if that 6GB is sparsely populated.
cinder doesn't have to know where is the data written because qemu does. if you use qemu-img command to copy the info you should not have a problem...
Product Management has reviewed and declined this request. You may appeal this decision by reopening this request.