Bug 1282654

Summary:	[RFE] Create QCOW2 disks
Product:	[oVirt] ovirt-engine	Reporter:	Christopher Pereira <kripper>
Component:	Frontend.Core	Assignee:	Allon Mureinik <amureini>
Status:	CLOSED DUPLICATE	QA Contact:	Raz Tamir <ratamir>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	3.6.0.1	CC:	bugs, tnisan, ykaul, ylavi
Target Milestone:	---	Keywords:	FutureFeature, Improvement
Target Release:	---	Flags:	tnisan: ovirt-future? rule-engine: planning_ack? rule-engine: devel_ack? rule-engine: testing_ack?
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-12-06 11:49:12 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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 ***