| Summary: | Upload image: qcow image format on client side is identified as qcow2 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Natalie Gavrielov <ngavrilo> | ||||
| Component: | Frontend.WebAdmin | Assignee: | Amit Aviram <aaviram> | ||||
| Status: | CLOSED DEFERRED | QA Contact: | Aharon Canan <acanan> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 4.0.4 | CC: | amureini, bugs, ngavrilo, tnisan | ||||
| Target Milestone: | --- | Flags: | tnisan:
ovirt-4.1?
ngavrilo: planning_ack? ngavrilo: devel_ack? ngavrilo: testing_ack? |
||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2016-11-21 10:47:09 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: | |||||
| Attachments: |
|
||||||
How was this qcow created? Something done the lines of "qemu-img create -f qcow file.img 1M"? (In reply to Allon Mureinik from comment #1) > How was this qcow created? Something done the lines of "qemu-img create -f > qcow file.img 1M"? I used qemu-img convert.. why? Who cares? No one is using the (original?!) qcow format. It's not available anywhere. The whole world is using qcow2 or qcow2v3, which we aim to support in 4.1. I'd close with WONTFIX, unless there are implications I'm missing here. For the time being, pushing to 4.1 for re-evaluation. (In reply to Yaniv Kaul from comment #3) > Who cares? No one is using the (original?!) qcow format. It's not available > anywhere. The whole world is using qcow2 or qcow2v3, which we aim to support > in 4.1. > I'd close with WONTFIX, unless there are implications I'm missing here. > For the time being, pushing to 4.1 for re-evaluation. Closing. We know even support qcow2v3, so really all the *real* variants of qcow that are available are supported. |
Created attachment 1198721 [details] engine.log, vdsm.log, image-proxy.log Description of problem: When uploading an image, the client side identifies a qcow image as qcow2. Version-Release number of selected component: rhevm-4.0.4-0.1.el7ev.noarch vdsm-4.18.12-1.el7ev.x86_64 ovirt-imageio-proxy-0.3.0-0.el7ev.noarch ovirt-imageio-common-0.3.0-0.el7ev.noarch ovirt-imageio-daemon-0.3.0-0.el7ev.noarch How reproducible: 100% Steps to Reproduce: Try to upload a qcow (not qcow2!) image. Actual results: Image is identified as qcow2 with compat N/A. When trying to upload the upload pauses with the following audit log: Unable to upload image to disk e0f21e3f-1d0b-49f0-8f15-9e4ea0c06a23 due to a network error. Make sure ovirt-imageio-proxy service is installed and configured, and ovirt-engine's certificate is registered as a valid CA in the browser. Expected results: Not to identify the qcow image as qcow2