Bug 1282654 - [RFE] Create QCOW2 disks
[RFE] Create QCOW2 disks
Status: CLOSED DUPLICATE of bug 1097843
Product: ovirt-engine
Classification: oVirt
Component: Frontend.Core (Show other bugs)
All Linux
unspecified Severity high (vote)
: ---
: ---
Assigned To: Allon Mureinik
Raz Tamir
: FutureFeature, Improvement
Depends On:
  Show dependency treegraph
Reported: 2015-11-16 19:48 EST by Christopher Pereira
Modified: 2016-12-06 06:49 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-12-06 06:49:12 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
tnisan: ovirt‑future?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?

Attachments (Terms of Use)

  None (edit)
Description Christopher Pereira 2015-11-16 19:48:41 EST
In the "New Disk" dialog, there is currently no option to select the image type (RAW or QCOW2). Disks are always created as RAW type (?).

RAW images (disks) have critical performance problems since there is currently no sparse-file support for some FS like GlusterFS [1].

QCOW2 should be used by default, or there should be an option at least to create QCOW2 images instead of RAW images.


[1] : https://bugzilla.redhat.com/show_bug.cgi?id=1220173
Comment 1 Christopher Pereira 2015-11-16 21:00:59 EST
Changing the format in the image meta didn't have any effect on the format used by vdsmd (format is fixed to RAW).
Comment 2 Christopher Pereira 2015-12-11 07:35:31 EST
I wonder what kind of storage should be used with oVirt because most network shared filesystems (glusterFS, NFS, etc) don't efficiently support sparse .RAW files [1].

We are considering dropping oVirt and going back to good old libvirt until oVirt is able to create and use .QCOW2 images without the need of inefficient .RAW images.

Implementing sparse files support will probably take much more time [2].

[1] : When copying small files with TB's of logical zeros (virtual holes), they are treated as normal TB files which take hours instead of seconds.

[2] : https://bugzilla.redhat.com/show_bug.cgi?id=1220173

Just to re-check...is oVirt really not capable of running a VM based purely on  .QCOW2 images? Is a .RAW backing-chain really mandatory?

If this is the case, please consider adding this important restriction in the documentation.
Comment 3 Christopher Pereira 2015-12-16 02:19:09 EST
Is oVirt capable of running a VM using a QCOW2 base image?
Apparently there is no option in Engine to create a QCOW2 disk.
QCOW2 images are only supported for snapshots, not for base images.
Base images must use RAW format which has performance problems when using GlusterFS [1].
To properly support GlusterFS, RAW format must be depreciated or sparse file support must be implemented in GlusterFS.

Please confirm/comment.

[1] : https://bugzilla.redhat.com/show_bug.cgi?id=1220173
Comment 4 Christopher Pereira 2016-01-26 01:05:34 EST
Can oVirt run a VM with a QCOW2 base image now?
I noticed that base images are created in RAW format when (a new disk is created) and there seems to be no way to run a VM using a QCOW2 image.
QCOW2 work only as overlays for RAW base images.
Comment 5 Yaniv Lavi 2016-12-06 06:49:12 EST
This is the page explaining the behavior:

We want to drop allocation policy and add format instead vie BZ #1097843.
The Gluster issue mentioned has been resolved in any case.
I'm closing this RFE as dup of the mentioned BZ.

*** This bug has been marked as a duplicate of bug 1097843 ***

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