Bug 1143872
| Summary: | [RFE] vdsm: QCOW2 v3 Image Format | ||
|---|---|---|---|
| Product: | [oVirt] vdsm | Reporter: | Allon Mureinik <amureini> |
| Component: | RFEs | Assignee: | Maor <mlipchuk> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Kevin Alon Goldblatt <kgoldbla> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | --- | CC: | apinnick, bazulay, bgraveno, bmcclain, bugs, eheftman, fkust, fsimonce, knoel, lsurette, mgoldboi, mkalinin, mlipchuk, nsoffer, pdwyer, ratamir, rbalakri, scohen, shipatil, s.kieske, srevivo, tnisan, ykaul, ylavi |
| Target Milestone: | ovirt-4.1.0-beta | Keywords: | FutureFeature |
| Target Release: | --- | Flags: | rule-engine:
ovirt-4.1+
gklein: testing_plan_complete+ ylavi: planning_ack+ rule-engine: 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: | hc | 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: | Environment: | ||
| Last Closed: | 2017-02-15 14:54:22 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: | 821546, 1417460 | ||
| Bug Blocks: | 827529, 1080372, 1185830, 1415658 | ||
|
Description
Allon Mureinik
2014-09-18 07:47:03 UTC
Open issue - what to do with pre-existing images when upgrading V3 to V4? Offhand, there are several issues: 1. Nothing. Leave them as is, and just create new images with compat=1.1 2. Option #1 + a manual tool to "upgrade" images 3. Option #1 + engine support to "upgrade" images (disk -> right click -> upgrade) 4. Upgrade all of them synchronously when upgrading the domain. *** Bug 827528 has been marked as a duplicate of this bug. *** *** Bug 827529 has been marked as a duplicate of this bug. *** Will be handled after removing SPM, need to see how this fits the timeline I thought most of the work is already done by Maor? The current status regarding this RFE is as follow: 1. Upgrading a DC to 4.1 should upgrade all data storage domains to V4. 2. All new volumes created on a 4.1 Data Center should be created with qcow version 1.1. That includes new disks, snapshots, Templates or VMs based on Templates (only the active volumes if thin provisioned) Old volumes will be configured with 0.10 compat level. 3. A user will be able to check its disk's qcow version through REST: http://localhost:8080/ovirt-engine/api/storagedomains/1234/disks/ 4. If a user will want to upgrade its disk's qcow version he can use the REST API upgrade to amend the disk's qcow compat to 1.1 I will add the relevant patches to this bug so it can be better tracked. Should be MODIFIED? (In reply to Yaniv Dary from comment #17) > Should be MODIFIED? yes Hi Maor Is there a need to update any of the documentation with this new version of QCOW2? (In reply to emma heftman from comment #20) > Hi Maor > Is there a need to update any of the documentation with this new version of > QCOW2? Yes, we should indicate that new volumes on DC 4.1 will be with qcow compat of 1.1 as described in here: http://www.ovirt.org/develop/release-management/features/storage/qcow2v3/ MOVING TO VERIFIED Removing doc text because this bug is duplicated in the release notes. Sync with Jira |