Bug 1413983
| Summary: | qcow_compat for uploaded images displays incorrect value - always 0 / 2 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Natalie Gavrielov <ngavrilo> | ||||
| Component: | BLL.Storage | Assignee: | Maor <mlipchuk> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Natalie Gavrielov <ngavrilo> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 4.1.0 | CC: | bugs, tnisan | ||||
| Target Milestone: | ovirt-4.1.0-beta | Keywords: | Reopened | ||||
| Target Release: | 4.1.0.3 | Flags: | rule-engine:
ovirt-4.1+
|
||||
| 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: | 2017-02-15 14:59:56 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: | |||||||
| Attachments: |
|
||||||
Since upload image creates a new disk on the destination storage domain the qcow2 compat should be related to the storage domain. If the image is uploaded to a V4 storage domain the uploaded volume should be with qcow2v3. If the upload is being done to a 4.0 DC the qcow compat of the new volume should be qcow2v2 (In reply to Maor from comment #1) > Since upload image creates a new disk on the destination storage domain the > qcow2 compat should be related to the storage domain. > If the image is uploaded to a V4 storage domain the uploaded volume should > be with qcow2v3. > If the upload is being done to a 4.0 DC the qcow compat of the new volume > should be qcow2v2 I will add this description in the wiki (In reply to Maor from comment #2) > (In reply to Maor from comment #1) > > Since upload image creates a new disk on the destination storage domain the > > qcow2 compat should be related to the storage domain. > > If the image is uploaded to a V4 storage domain the uploaded volume should > > be with qcow2v3. > > If the upload is being done to a 4.0 DC the qcow compat of the new volume > > should be qcow2v2 > > I will add this description in the wiki (In reply to Maor from comment #3) > (In reply to Maor from comment #2) > > (In reply to Maor from comment #1) > > > Since upload image creates a new disk on the destination storage domain the > > > qcow2 compat should be related to the storage domain. > > > If the image is uploaded to a V4 storage domain the uploaded volume should > > > be with qcow2v3. > > > If the upload is being done to a 4.0 DC the qcow compat of the new volume > > > should be qcow2v2 > > > > I will add this description in the wiki The upload image should also run over the meta data and it should be changed as well, therefore re-open it Performed scenario described in comment 0 Verified using: (rhv-4.1.0-11) rhevm-4.1.0.3-0.1.el7.noarch ovirt-imageio-common-1.0.0-0.el7ev.noarch ovirt-imageio-proxy-1.0.0-0.el7ev.noarch vdsm-4.19.4-7.gitc2f748c.el7.centos.x86_64 ovirt-imageio-daemon-1.0.0-1.el7.noarch |
Created attachment 1241779 [details] logs: engine, vdsm. proxy, daemon , query from db, xml from rest api, Description of problem: After uploading qcow2 (both v2 and v3) images, check rest-api / engine report the qcow2 version correctly - it doesn't on both rest and db. Version-Release number of selected component (if applicable): vdsm-4.19.1-1.el7ev.x86_64 ovirt-engine-4.1.0-0.4.master.20170111000229.git9ce0636.el7.centos.noarch How reproducible: 100% Steps to Reproduce: 1. Upload a qcow2 image (both versions: v2, v3) 2. Verify that both engine and rest api report qcow version correctly. Actual results: * Rest api for nfs based storage domain reports qcow version as v3 (regardless of the actual qcow version, it can be v2..) * For block storage domain, it does not report the qcow_version tag at all. When looking at the db I found the following: engine=# SELECT image_guid,volume_type,volume_format,qcow_compat FROM images; image_guid | volume_type | volume_format | qcow_compat --------------------------------------+-------------+---------------+------------- 00000000-0000-0000-0000-000000000000 | 2 | 4 | 1 00440768-a652-493c-9a06-f58430f45172 | 2 | 4 | 2 <--test-upload-16-01-23-50-compressed-v2, nfs d258ec3e-c7c8-484f-bc2a-91f5fe60ac14 | 2 | 4 | 2 <-- vm-1_Disk1, iscsi, qcow2-v3 5f3a0892-ed42-4cff-8e60-9eff9b7172a5 | 2 | 4 | 0 <-- qcow-2-v2-upload, qcow2-v2, iscsi ee78baa3-50a8-44ca-bc8f-2d80908f9041 | 2 | 4 | 2 <-- thin-provision-1gb-disk, created in ovirt, iscsi 656d2a5c-dee8-4f7c-8770-a6c22847e740 | 2 | 4 | 0 <-- qcow2-v2-another-test , iscsi ac79dff2-23b5-4a86-8f70-972a7e56f524 | 2 | 4 | 0 <-- test-upload-qcow2-v2, iscsi, qcow2-v2 ced7cfd7-ad7c-4cb7-8512-a593e70a03b8 | 2 | 4 | 2 <-- test-upload-17-01-v2, nfs f9cb3f89-a066-4a2d-b766-a4b83a59db60 | 2 | 4 | 2 <-- test-upload-16-01-23-20-compressed, nfs 46d14502-7f8d-4934-8bf8-348fd5b9d0b3 | 2 | 4 | 0 <-- test-upload-qcow2-v3, iscsi, qcow2 v3 b91f657c-ec66-45e0-bb40-ff7ac91d7a61 | 2 | 4 | 2 <-- vm-1_Disk1, nfs 2b885cc7-0497-445d-92ce-ffb24a527016 | 2 | 4 | 2 <-- test-upload-17-01-qcow2-v2-compressed-nfs, nfs 82060596-94c5-4f90-995b-a155dbb1688d | 2 | 4 | 2 <-- test-upload-17-01-qcow2-v2-compressed-nfs, nfs 1. The qcow_compat for qcow2 images on nfs is always 2 (even when the uploaded image was qcow2 v2) 2. The qcow_compat for qcow2 images on iscsi is always 0. Expected results: For the qcow_compat in each case to have a right value: In the DB: for raw images to have qcow_compat = 0 for qcow2 v2 images to have qcow_compat = 1 and for qcow2 v3 images to have qcow_compat = 2 Additional info: