Ask Your Question

Creating cinder volume from image is extremely slow

asked 2014-06-04 16:43:07 -0500

Chris L gravatar image

I'm running OpenStack Havana with Cinder and Neutron. I am trying to create volumes from images stored in Glance to attach to a new instance at boot time (i.e. i'm not trying to create a bootable volume, I'm trying to create additional volumes for an instance). Unfortunately, creating these volumes seems extremely slow. It takes well over a minute per GB to create these volumes. I'm wondering if this is expected behavior or if perhaps there is a problem with my configuration.

I have Cinder configured in a somewhat un-orthodox way:

  • I have an HP Proliant server running Ubuntu 12.04LTS that acts as a compute node as well as the Cinder node.
  • This server has 4 1TB disks configured using Raid 5 (so they look like on 3TB drive).
  • Ubuntu is configured to use LVM,
  • The whole 3TB drive is exposed as one single Volume Group -The physical host uses one logical volume for the Ubuntu OS
  • Cinder is configured to allocate volumes from the same Volume Group (i.e. there is no separate volume group dedicated to Cinder)

Everything seems to work fine, except for the performance aspect. Is anything wrong here?

I'm attaching my cinder.conf in case that helps:



verbose = True policy_file=policy.json rootwrap_config = /etc/cinder/rootwrap.conf


sql_connection = mysql://cinder:Ll6BbUvloSDSW836D1Z4@


iscsi_helper = tgtadm iscsi_ip_address =


rpc_backend=cinder.openstack.common.rpc.impl_kombu rabbit_host = rabbit_port = 5672 rabbit_ha_queues = True

notification_driver = cinder.openstack.common.notifier.no_op_notifier notification_topics = notifications


auth_strategy = keystone api_paste_confg = /etc/cinder/api-paste.ini notification_driver=cinder.openstack.common.notifier.rpc_notifier osapi_volume_listen = osapi_volume_listen_port = 8776


state_path = /var/lib/cinder lock_path = /var/lock/cinder volumes_dir = /var/lib/cinder/volumes volume_name_template = volume-%s storage_availability_zone = nova max_gigabytes = 10000 glance_host =


volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver volume_group=ubctsrv1-vg volume_clear=zero volume_clear_size=0 volume_pool_size=None


[keystone_authtoken] signing_dirname = /tmp/keystone-signing-cinder service_protocol = http service_host = service_port = 5000 auth_host = auth_port = 35357 auth_protocol = http admin_tenant_name = service admin_user = cinder

edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted

answered 2014-06-25 23:28:36 -0500

jgriffith gravatar image

Hi Chris,

Despite some of the other answers you've received elsewhere... yes, this is unfortunately "expected' behavior. The problem is the number of things that have to be done to fetch, convert and load the image. The process goes something like this: 1. Fetch/Download the image from Glances backing store to your Cinder node 2. Run qemu-convert on it to make sure it's valid and that it's raw format suitable for being written straight to a volume 3. Copy the converted image off to the Cinder Volume

There's a bunch of overhead here and it's something we're aware of and know needs fixing. One of the problems is that qemu-convert can't pipe the conversion process out to the device, that alone would help quite a bit.

One thing that I recommend to people is limit this by building template volumes. This way you "suffer" through creating the bootable volume once per image; then just use Cinders clone and extend features to build new bootable volumes off of your templates rather than fetching and converting every time.

Meanwhile, hopefully we'll find some ways to make this better/faster.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower


Asked: 2014-06-04 16:43:07 -0500

Seen: 2,766 times

Last updated: Jun 25 '14