Bug 865316 - RFE: default image file format should be raw (sparse?), not qcow2 - for performance reasons
RFE: default image file format should be raw (sparse?), not qcow2 - for perfo...
Status: CLOSED NOTABUG
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova (Show other bugs)
1.0 (Essex)
Unspecified Unspecified
medium Severity medium
: Upstream M3
: 4.0
Assigned To: Nikola Dipanov
Haim
storage
: FutureFeature, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-11 04:20 EDT by Yaniv Kaul
Modified: 2016-04-26 22:53 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-27 12:29:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Yaniv Kaul 2012-10-11 04:20:09 EDT
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:
Comment 2 Yaniv Kaul 2013-02-14 15:30:24 EST
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.
Comment 5 Nikola Dipanov 2013-05-31 03:35:45 EDT
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.
Comment 6 Ayal Baron 2013-06-02 11:59:44 EDT
(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.
Comment 10 Nikola Dipanov 2013-08-27 12:29:53 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.