Bug 1271988
| Summary: | [RFE] Add support for qcow2 disks, adding the ability to choose qcow2 disk format when creating a VM from template. | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Yaniv Lavi <ylavi> | |
| Component: | RFEs | Assignee: | Fred Rolland <frolland> | |
| Status: | CLOSED ERRATA | QA Contact: | Elad <ebenahar> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 3.6.0 | CC: | acanan, ahadas, amureini, fdanapfe, ichute, iheim, jcall, juwu, lmiccini, lpeer, lsurette, rbalakri, rbinkhor, s.kieske, srevivo, tnisan, tspeetje, uwe.menges, ykaul, ylavi | |
| Target Milestone: | ovirt-4.0.0-beta | Keywords: | FutureFeature | |
| Target Release: | 4.0.0 | Flags: | lsvaty:
testing_plan_complete-
|
|
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Enhancement | ||
| Doc Text: |
When creating a virtual machine from a template, the user is able to choose the format of the disks: either RAW or QCOW2. The Allocation Policy section is now hidden. If the Template Provisioning is Thin, the format of the disks will be marked as QCOW2 and the user won't be able to change it. If the Template Provisioning is Clone, the user will be able to select either QCOW2 or RAW.
|
Story Points: | --- | |
| Clone Of: | 1168576 | |||
| : | 1317453 (view as bug list) | Environment: | ||
| Last Closed: | 2016-08-23 20:30:00 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: | 1317453 | |||
| Bug Blocks: | ||||
|
Comment 3
Yaniv Kaul
2016-03-03 14:56:33 UTC
(In reply to Yaniv Kaul from comment #3) > Isn't it exactly the opposite of bug 1097843 ? No. The format I(QCOW vs. raw) is something an admin can make an informed decision about. Thew allocation policy is a fallacy, as it's completely coupled to the combination of foramt+storage type. Executed the feature basic flows after setup upgrade (3.6 -> 4.0): https://polarion.engineering.redhat.com/polarion/#/project/RHEVM3/testrun?id=4_0_Storage_Ability_to_change_disk_interface_for_a_VM_disk_run_31_06_2016 Tested using Webadmin, All passed. Note that for REST API, we're still block due to: Bug 1352657 - GET of diskattachment returns a list of objects without the href property Tested using: rhevm-4.0.0.6-0.1.el7ev.noarch vdsm-4.18.4-2.el7ev.x86_64 libvirt-daemon-1.2.17-13.el7_2.5.x86_64 qemu-kvm-rhev-2.3.0-31.el7_2.18.x86_64 I accidentally verified this bug. Moving back to ON_QA Executed according to the following Polarion test run: https://polarion.engineering.redhat.com/polarion/#/project/RHEVM3/testrun?id=4_0_Storage_Ability_to_choose_qcow2_disk_format_when_creating_a_VM_from_%20template_run_19_07_2016 Moving to VERIFIED. Tested using: rhevm-4.0.1.1-0.1.el7ev.noarch vdsm-4.18.5.1-1.el7ev.x86_64 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-1743.html |