Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1445950

Summary: RestAPI: snapshot disk qcow version is not seen of the same from vms API path but works from storagedomains API path
Product: [oVirt] ovirt-engine Reporter: Avihai <aefrat>
Component: BLL.StorageAssignee: Allon Mureinik <amureini>
Status: CLOSED NOTABUG QA Contact: Raz Tamir <ratamir>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.1.1.8CC: bugs, mlipchuk
Target Milestone: ---   
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: 2017-04-27 07:09:05 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:    
Bug Blocks: 1430447    
Attachments:
Description Flags
engine & vdsm logs none

Description Avihai 2017-04-26 21:28:25 UTC 
Created attachment 1274417 [details]
engine & vdsm logs

Description of problem:
snapshot disk qcow version is not seen of the same  from vms API path but works from storagedomains API path
Version-Release number of selected component (if applicable):
Engine :
ovirt-engine-4.1.2-0.1.el7.noarch

VDSM:
4.19.10.1-1

How reproducible:
100%

Steps to Reproduce:
Via WebAdmin do :
1.Create DC on 4.0
2.Create cluster on 4.0 + Storage domain
3.Create VM + thin disk + snapshot

Time Snapshot 'snap_test' creation for VM 'vm1' has been completed:
Apr 26, 2017 5:55:50 PM

Actual results:
snapshot disk qcow version is not seen of the same  from vms API path but works from storage domains API path

Expected results:
from both API path qcow version should be seen & be the same.

Additional info:
DC& cluster on 4.0, via VM we cann't see qcow_version field at all ! 

-Rest Get responses from both paths :

* PATH 1, via vms : 
URL:
https://storage-ge-04.scl.lab.tlv.redhat.com/ovirt-engine/api/vms/04296ada-f3af-4f8f-b127-eaada55f6724/snapshots/c6a2c271-fb58-40ae-9b39-d4ba7e4e599c/disks

Response body :
<disks>
<disk id="ced7db15-7e4c-43a4-848a-efa4ea3fced3">
<name>vm1_Disk1</name>
<actual_size>1073741824</actual_size>
<alias>vm1_Disk1</alias>
<format>cow</format>
<image_id>d9037e2b-2472-49d1-ab1d-55e7bdad7483</image_id>
<propagate_errors>false</propagate_errors>
<provisioned_size>1073741824</provisioned_size>
<read_only>false</read_only>
<shareable>false</shareable>
<sparse>true</sparse>
<status>ok</status>
<storage_type>image</storage_type>
<wipe_after_delete>false</wipe_after_delete>
<snapshot id="c6a2c271-fb58-40ae-9b39-d4ba7e4e599c"/>
<storage_domains>
<storage_domain id="8039e21e-559f-4d58-8ccb-a75138018502"/>
</storage_domains>
</disk>
</disks>

Path-2 via storagedomains:

URL:

https://storage-ge-04.scl.lab.tlv.redhat.com/ovirt-engine/api/storagedomains/8039e21e-559f-4d58-8ccb-a75138018502/disksnapshots

Response body :
<disk_snapshots>
<disk_snapshot href="/ovirt-engine/api/storagedomains/8039e21e-559f-4d58-8ccb-a75138018502/disksnapshots/d9037e2b-2472-49d1-ab1d-55e7bdad7483" id="d9037e2b-2472-49d1-ab1d-55e7bdad7483">
<name>vm1_Disk1</name>
<actual_size>1073741824</actual_size>
<alias>vm1_Disk1</alias>
<format>cow</format>
<propagate_errors>false</propagate_errors>
<provisioned_size>1073741824</provisioned_size>
<qcow_version>qcow2_v2</qcow_version>
<shareable>false</shareable>
<sparse>true</sparse>
<status>ok</status>
<storage_type>image</storage_type>
<wipe_after_delete>false</wipe_after_delete>
<disk_profile href="/ovirt-engine/api/diskprofiles/738784c2-f339-4aba-9c3d-da1f51c5ea2a" id="738784c2-f339-4aba-9c3d-da1f51c5ea2a"/>
<quota id="589e3dd5-c8c5-4455-a47d-326e3d7eea77"/>
<snapshot id="c6a2c271-fb58-40ae-9b39-d4ba7e4e599c"/>
<storage_domain href="/ovirt-engine/api/storagedomains/8039e21e-559f-4d58-8ccb-a75138018502" id="8039e21e-559f-4d58-8ccb-a75138018502"/>
<storage_domains>
<storage_domain id="8039e21e-559f-4d58-8ccb-a75138018502"/>
</storage_domains>
<disk href="/ovirt-engine/api/disks/ced7db15-7e4c-43a4-848a-efa4ea3fced3" id="ced7db15-7e4c-43a4-848a-efa4ea3fced3"/>
</disk_snapshot>
</disk_snapshots>
Comment 1 Avihai 2017-04-26 21:31:22 UTC 
This looks somewhat in the area of Bug 1430447 (that is fixed at 4.1.2)

If this indeed the same root cause please notify & I'll reopen 1430447.
Comment 2 Avihai 2017-04-26 21:37:22 UTC 
Also another bug that reminds me of this issue Bug 1432493 (that is fixed at 4.1.2)

If this indeed the same root cause please notify & I'll reopen 1432493.
Comment 3 Maor 2017-04-27 07:09:05 UTC 
The API api/vms/1111/snapshots/2222/disks reflects the OVF data in the snapshot .
Since this information might be mismatched with the disk's compat level in the storage domain it could be misleading for the user so we decided not to present it in the OVF (see commit message in [1])

[1] https://gerrit.ovirt.org/#/c/74008/ - 
core: Remove compat from OVF.