Bug 827529 (RHEV_qcow2_v3)
| Summary: | [RFE] QCOW2 v3 Image Format | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Karen Noel <knoel> |
| Component: | RFEs | Assignee: | Maor <mlipchuk> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Kevin Alon Goldblatt <kgoldbla> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | --- | CC: | abaron, acanan, amureini, bugs, dyasny, eheftman, emarcus, gklein, jkt, lpeer, mlipchuk, ratamir, tnisan, ylavi |
| Target Milestone: | ovirt-4.1.0-beta | Keywords: | FutureFeature, Reopened |
| Target Release: | 4.1.0.2 | Flags: | rule-engine:
ovirt-4.1+
gklein: testing_plan_complete+ ylavi: planning_ack+ amureini: devel_ack+ ratamir: testing_ack+ |
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | https://github.com/maorlipchuk/ovirt-site/blob/cdbbfa5250af0e207ff151af67f188b3451d4c33/source/develop/release-management/features/storage/qcow2v3.html.md | ||
| Whiteboard: | |||
| 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 14:56:29 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: | |||
| Bug Depends On: | 821549, 827525, 827528, 1143872, 1417460 | ||
| Bug Blocks: | 1080372, 1213400, 1415658 | ||
|
Comment 1
Itamar Heim
2013-01-09 21:26:06 UTC
This will be handled as part of v4 storage domains. *** This bug has been marked as a duplicate of bug 1143872 *** (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). 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. Can you get the stats on improvement of this version? Restoring needinfo (In reply to Yaniv Dary from comment #5) > Can you get the stats on improvement of this version? I could not find any. (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. (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 *** Bug 1213400 has been marked as a duplicate of this bug. *** 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? (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. (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. Moving to VERIFIED |