Bug 1282654 - [RFE] Create QCOW2 disks
Summary: [RFE] Create QCOW2 disks
Keywords:
Status: CLOSED DUPLICATE of bug 1097843
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Frontend.Core
Version: 3.6.0.1
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
: ---
Assignee: Allon Mureinik
QA Contact: Raz Tamir
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-11-17 00:48 UTC by Christopher Pereira
Modified: 2016-12-06 11:49 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-06 11:49:12 UTC
oVirt Team: Storage
Embargoed:
tnisan: ovirt-future?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)

Description Christopher Pereira 2015-11-17 00:48:41 UTC
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-17 02:00:59 UTC
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 12:35:31 UTC
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 07:19:09 UTC
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 06:05:34 UTC
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 11:49:12 UTC
This is the page explaining the behavior:
http://wiki.ovirt.org/develop/developer-guide/vdsm/disk-images/

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.