Bug 827529 - (RHEV_qcow2_v3) [RFE] QCOW2 v3 Image Format
[RFE] QCOW2 v3 Image Format
Status: CLOSED CURRENTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: RFEs (Show other bugs)
---
Unspecified Unspecified
medium Severity high (vote)
: ovirt-4.1.0-beta
: 4.1.0.2
Assigned To: Maor
Kevin Alon Goldblatt
https://github.com/maorlipchuk/ovirt-...
: FutureFeature, Reopened
: 1213400 (view as bug list)
Depends On: 821549 827525 827528 1143872 1417460
Blocks: 1080372 1213400 1415658
  Show dependency treegraph
 
Reported: 2012-06-01 13:38 EDT by Karen Noel
Modified: 2017-02-15 09:56 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
This release introduces QCOW2 v3 which has a compatibility level of 1.1. This enables the QEMU to use this volume in a more efficient way, with its improved performance capabilities. In addition, it is fully backwards-compatible with the QCOW2 feature set, it is easy to upgrade from QCOW2 v2 to QCOW2 v3, and it supports extensibility.
Story Points: ---
Clone Of: 821546
Environment:
Last Closed: 2017-02-15 09:56:29 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.1+
gklein: testing_plan_complete+
ylavi: planning_ack+
amureini: devel_ack+
ratamir: testing_ack+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 66655 master MERGED API: Introduce SDM.amend_volume. 2016-11-28 13:30 EST
oVirt gerrit 67193 master MERGED vdsm-api: Rename ImageInfo to PreparedImageInfo 2016-11-28 09:56 EST
oVirt gerrit 67195 master MERGED hsm: Refactor get_hostid as pool attribute 2016-11-28 09:56 EST
oVirt gerrit 67196 master MERGED Introduce sdm.api.amend_volume 2016-12-08 13:57 EST
oVirt gerrit 67198 master MERGED core: Introduce amend VDS command. 2016-12-11 10:37 EST
oVirt gerrit 67199 master MERGED core: Introduce AmendImageCommand 2016-12-11 10:37 EST
oVirt gerrit 67243 master MERGED core: Add condition DC version 4.1 to get QemuImageInfo. 2016-11-24 03:47 EST
oVirt gerrit 67351 master MERGED rest: Set qcow compat and qcow version for disk. 2016-12-11 10:37 EST
oVirt gerrit 67849 master MERGED rest: Add implementation for update disk qcow2 compat. 2016-12-11 10:37 EST

  None (edit)
Comment 1 Itamar Heim 2013-01-09 16:26:06 EST
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.
Comment 2 Allon Mureinik 2015-01-24 04:49:24 EST
This will be handled as part of v4 storage domains.

*** This bug has been marked as a duplicate of bug 1143872 ***
Comment 3 Allon Mureinik 2015-01-27 17:31:06 EST
(In reply to Allon Mureinik from comment #2)
> This will be handled as part of v4 storage domains.
> 
> *** This bug has been marked as a duplicate of bug 1143872 ***

Actually, let's use this BZ to track the inclusion in RHEV (as opposed to oVirt).
Comment 4 Aharon Canan 2015-06-28 08:13:49 EDT
Need to verify that in case creating storage domain v4 in case of creating snapshot we are using qcow 1.1 instead of 0.1 .

Allon - Please correct me if I am wrong.
Comment 5 Yaniv Lavi (Dary) 2016-01-27 06:00:00 EST
Can you get the stats on improvement of this version?
Comment 6 Yaniv Lavi (Dary) 2016-01-28 15:16:42 EST
Restoring needinfo
Comment 7 Yaniv Kaul 2016-10-30 07:08:25 EDT
(In reply to Yaniv Dary from comment #5)
> Can you get the stats on improvement of this version?

I could not find any.
Comment 8 Raz Tamir 2016-11-15 10:22:37 EST
(In reply to Aharon Canan from comment #4)
> Need to verify that in case creating storage domain v4 in case of creating
> snapshot we are using qcow 1.1 instead of 0.1 .
> 
> Allon - Please correct me if I am wrong.
Comment 9 Maor 2016-11-22 07:48:52 EST
(In reply to Raz Tamir from comment #8)
> (In reply to Aharon Canan from comment #4)
> > Need to verify that in case creating storage domain v4 in case of creating
> > snapshot we are using qcow 1.1 instead of 0.1 .
> > 
> > Allon - Please correct me if I am wrong.

yes, the new snapshot on a V4 storage domain should be with qcow compat 1.1
Comment 10 Yaniv Lavi (Dary) 2016-12-06 18:37:07 EST
*** Bug 1213400 has been marked as a duplicate of this bug. ***
Comment 11 Emma Heftman 2017-01-19 11:24:07 EST
Hi Maor, Can you please let me know whether this topic needs to be updated in 4.1 in order to reflect this enhancement.

https://access.redhat.com/documentation/en/red-hat-virtualization/4.0/paged/technical-reference/24-storage-formats-for-virtual-machine-disk-images

Is any other document affected?
Comment 12 Maor 2017-01-22 07:06:18 EST
(In reply to emma heftman from comment #11)
> Hi Maor, Can you please let me know whether this topic needs to be updated
> in 4.1 in order to reflect this enhancement.
> 
> https://access.redhat.com/documentation/en/red-hat-virtualization/4.0/paged/
> technical-reference/24-storage-formats-for-virtual-machine-disk-images
> 
> Is any other document affected?

I think it will be better to add a general explanation of the QCOW2 version 3.
Something like this:

"""
QCOW3 includes a version number increase in order to introduce some incompatible features, however it's strictly an extension of QCOW2 and keeps the fundamental structure unchanged, so that a single codebase will be enough for working with both QCOW2 and QCOW3 images.

Newer QEMU versions (1.7 and above) support a new format of QCOW2 version 3, which is not backwards compatible and introduce many improvements like zero clusters, and performance improvement.
"""

Regarding the rest of the documentation, I'm not sure, but it should be stated that 4.1 Data Centers will create QCOW volumes with 1.1 compatibility level instead of 0.10 which was until now.
Comment 13 Allon Mureinik 2017-01-23 05:25:27 EST
(In reply to Maor from comment #12)
> Regarding the rest of the documentation, I'm not sure, but it should be
> stated that 4.1 Data Centers will create QCOW volumes with 1.1 compatibility
> level instead of 0.10 which was until now.
We should stress that this means that once you upgrade a DC to 4.1 (or above, in newer versions) you cannot downgrade it again to 4.0 or below.
This also means you cannot detach a storage domain from a 4.1 DC and attach it to an older DC.

You COULD, however, export a VM/template from a newer DC to an EXPORT DOMAIN, and then import it to an older setup.
Comment 14 Kevin Alon Goldblatt 2017-02-01 11:17:30 EST
Moving to VERIFIED

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