Description of problem: The default image file format should be raw/sparse, not qcow2, for improved IO performance of the VMs. Looks like it currently default to qcow2. Version-Release number of selected component (if applicable): Essex How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
There are two issues here: 1. Today we convert from qcow2 to raw. 2. If we don't, we are left with a bit less performance image format (qcow2 vs. raw). Note that his bug is related to bug 904920 in a way, but not directly - the issue here is ho we transfer a raw-sparse format from Glance to Nova.
I believe that the choice of backing images is a deployment specific choice and using qcow images is as sane a default as any since there are trade-offs involved (in this case performance vs disk usage). Nova provides libvirt_images_type config opion which can be set to raw, qcow or lvm, so tweaking this is quite straightforward. I am closing this as not-a-bug.
(In reply to Nikola Dipanov from comment #5) > I believe that the choice of backing images is a deployment specific choice > and using qcow images is as sane a default as any since there are trade-offs > involved (in this case performance vs disk usage). When the backing storage is file based then it is sparse by nature and there is no disk usage advantage. In fact there will be a disadvantage due to the overhead of the qcow2 metadata so it's bad all over. When using block devices then since there is no mechanism in openstack to automatically grow the device when more space is required then qcow2 still makes no sense. Only the second file in the chain should be qcow2, the first one should be raw. > > Nova provides libvirt_images_type config opion which can be set to raw, qcow > or lvm, so tweaking this is quite straightforward. > > I am closing this as not-a-bug.
(In reply to Ayal Baron from comment #6) > (In reply to Nikola Dipanov from comment #5) > > I believe that the choice of backing images is a deployment specific choice > > and using qcow images is as sane a default as any since there are trade-offs > > involved (in this case performance vs disk usage). > > When the backing storage is file based then it is sparse by nature and there > is no disk usage advantage. In fact there will be a disadvantage due to the > overhead of the qcow2 metadata so it's bad all over. > > When using block devices then since there is no mechanism in openstack to > automatically grow the device when more space is required then qcow2 still > makes no sense. > > Only the second file in the chain should be qcow2, the first one should be > raw. > OK - there seems to have been a misunderstanding - In our out of the box RHOS setup. The base image - so files that are downloaded from glance will be inflated to raw (sparse) after being downloaded from Glance: [root@rhel-test c10aca02-a8b9-4c5b-abff-dc27e7f65db0(keystone_admin)]# rpm -q openstack-nova-compute openstack-nova-compute-2013.1.3-3.el6ost.noarch [root@rhel-test _base(keystone_admin)]# pwd /var/lib/nova/instances/_base [root@rhel-test _base(keystone_admin)]# ls 75347aa6053645e6fe97161ec31cfc7e92f5021d [root@rhel-test _base(keystone_admin)]# qemu-img info 75347aa6053645e6fe97161ec31cfc7e92f5021d image: 75347aa6053645e6fe97161ec31cfc7e92f5021d file format: raw virtual size: 39M (41126400 bytes) disk size: 12M This is because nova config option force_raw_images is set to True by default, and all image backends will use the same code to download images. Starting an instance will then cause an instance image to be created (by default) by calling 'qemu-img create -f qcow2' with a backing file option. so the actual instance image will be a QCOW2 image by default: [root@rhel-test c10aca02-a8b9-4c5b-abff-dc27e7f65db0(keystone_admin)]# pwd /var/lib/nova/instances/c10aca02-a8b9-4c5b-abff-dc27e7f65db0 [root@rhel-test c10aca02-a8b9-4c5b-abff-dc27e7f65db0(keystone_admin)]# ls console.log disk libvirt.xml [root@rhel-test c10aca02-a8b9-4c5b-abff-dc27e7f65db0(keystone_admin)]# qemu-img info disk image: disk file format: qcow2 virtual size: 39M (41126400 bytes) disk size: 1.3M cluster_size: 65536 backing file: /var/lib/nova/instances/_base/75347aa6053645e6fe97161ec31cfc7e92f5021d There seems to be some terminology overload that may have caused this confusion (what is considered a backing file I guess). Coming back to the original bug report - I still think this is not a bug (it may have been when it was reported though). > > > > Nova provides libvirt_images_type config opion which can be set to raw, qcow > > or lvm, so tweaking this is quite straightforward. > > > > I am closing this as not-a-bug.