Created attachment 1261324 [details] engine & vdsm logs Description of problem: After amend different qcow version is seen of the same snapshot disk from 2 different API paths Version-Release number of selected component (if applicable): Engine: ovirt-engine-4.1.1.3-0.1.el7.noarch VDSM: 4.19.6-1 How reproducible: 100% Steps to Reproduce: 1.create Data center + cluster + storage domain on with compatibility version 4.0 . 2. upgrade DC + cluster . 3.create VM + 1 disk + 1 snapshot on storage domain with comparability version on 4. amend disk - success ( also all snapdisks should be amended) 5.check RESTAPI the qcow version of the snapshot disks via 2 PATHS : PATH 1 -from VM path you see from the same snap disk 'qcow_v2' full path: https://storage-ge-04.scl.lab.tlv.redhat.com/ovirt-engine/api/vms/73f21062-3fa5-4fc4-bd5a-8778d3240be9/snapshots/08decaa9-7727-458c-8471-3ec005be22f1/disks GET API response: <disks> <disk id="e9d1b789-34b9-4479-9368-36dde94702a9"> <name>vm_TestCase18336_REST_ISCS_0811134095_Disk1</name> <actual_size>1073741824</actual_size> <alias>vm_TestCase18336_REST_ISCS_0811134095_Disk1</alias> <format>cow</format> <image_id>00033ccf-7c8d-4adf-928c-7b1452f67167</image_id> <propagate_errors>false</propagate_errors> <provisioned_size>6442450944</provisioned_size> <qcow_version>qcow2_v2</qcow_version> <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="08decaa9-7727-458c-8471-3ec005be22f1"/> <storage_domains> <storage_domain id="0b54b1f7-a438-4690-b858-35ce3ba93123"/> </storage_domains> </disk> </disks> 2) from SD(storage domain) path you see 'qcow_v3' for SAME snapshot disk (e9d1b789-34b9-4479-9368-36dde94702a9) full path: https://storage-ge-04.scl.lab.tlv.redhat.com/ovirt-engine/api/storagedomains/0b54b1f7-a438-4690-b858-35ce3ba93123/disksnapshots <disks> <disk id="e9d1b789-34b9-4479-9368-36dde94702a9"> <name>vm_TestCase18336_REST_ISCS_0811134095_Disk1</name> <actual_size>1073741824</actual_size> <alias>vm_TestCase18336_REST_ISCS_0811134095_Disk1</alias> <format>cow</format> <image_id>00033ccf-7c8d-4adf-928c-7b1452f67167</image_id> <propagate_errors>false</propagate_errors> <provisioned_size>6442450944</provisioned_size> <qcow_version>qcow2_v2</qcow_version> <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="08decaa9-7727-458c-8471-3ec005be22f1"/> <storage_domains> <storage_domain id="0b54b1f7-a438-4690-b858-35ce3ba93123"/> </storage_domains> </disk> Actual results: We get different qcow version of the same snapshot disk taken from 2 different API paths ( VM vs StorageDomain) Expected results: We should get the same qcow version of the same snapshot disk object Additional info: When checking with a new DC(V4) on the 2 paths(VM , SD) we see consistent result , both are qcow_v3 . So it looks like the amend only update 1 path which is the SD path and not the VM path .
Maor - IIUC, this should be covered by your recent work.
I don't understand. both outputs show the same qcow version qcow2_v2 full path: https://storage-ge-04.scl.lab.tlv.redhat.com/ovirt-engine/api/vms/73f21062-3fa5-4fc4-bd5a-8778d3240be9/snapshots/08decaa9-7727-458c-8471-3ec005be22f1/disks GET API response: <disks> .... <qcow_version>qcow2_v2</qcow_version> 2) from SD(storage domain) path you see 'qcow_v3' for SAME snapshot disk (e9d1b789-34b9-4479-9368-36dde94702a9) full path: https://storage-ge-04.scl.lab.tlv.redhat.com/ovirt-engine/api/storagedomains/0b54b1f7-a438-4690-b858-35ce3ba93123/disksnapshots <disks> ... <qcow_version>qcow2_v2</qcow_version> ... </disk>
(In reply to Maor from comment #2) > I don't understand. > both outputs show the same qcow version qcow2_v2 > > > full path: > https://storage-ge-04.scl.lab.tlv.redhat.com/ovirt-engine/api/vms/73f21062- > 3fa5-4fc4-bd5a-8778d3240be9/snapshots/08decaa9-7727-458c-8471-3ec005be22f1/ > disks > > GET API response: > <disks> > .... > <qcow_version>qcow2_v2</qcow_version> > > > 2) from SD(storage domain) path you see 'qcow_v3' for SAME snapshot disk > (e9d1b789-34b9-4479-9368-36dde94702a9) > > full path: > https://storage-ge-04.scl.lab.tlv.redhat.com/ovirt-engine/api/storagedomains/ > 0b54b1f7-a438-4690-b858-35ce3ba93123/disksnapshots > > <disks> > ... > <qcow_version>qcow2_v2</qcow_version> > ... > </disk> Wrong copy-paste in second path (SD path) , this is the right one with qcow_version = 'qcow2_v3' : <disks> <disk id="e9d1b789-34b9-4479-9368-36dde94702a9"> <name>vm_TestCase18336_REST_ISCS_0811134095_Disk1</name> <actual_size>1073741824</actual_size> <alias>vm_TestCase18336_REST_ISCS_0811134095_Disk1</alias> <format>cow</format> <image_id>00033ccf-7c8d-4adf-928c-7b1452f67167</image_id> <propagate_errors>false</propagate_errors> <provisioned_size>6442450944</provisioned_size> <qcow_version>qcow2_v3</qcow_version> <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="08decaa9-7727-458c-8471-3ec005be22f1"/> <storage_domains> <storage_domain id="0b54b1f7-a438-4690-b858-35ce3ba93123"/> </storage_domains> </disk> </disks>
Thanks for the info, I understand now. The API request vms/73f21062-3fa5-4fc4-bd5a-8778d3240be9/snapshots/08decaa9-7727-458c-8471-3ec005be22f1/disks fetched the disks data from the OVF. Since in that time of the snapshot creation, those disks were qcow version 0.10, even after you amend the disk you still see the version in the OVF of the snapshot, which I think is ok since it tells the user what was the qcow version in that time. Regarding the qcow version in the OVF, functionality wise it is not relevant, since the qcow version is determined by the VDSM. Based on the functionality section in http://www.ovirt.org/develop/release-management/features/storage/qcow2v3/: "new QCOW volumes that will be created on a V4 Storage Domains will be created with 1.1 compatibility level. That also includes snapshots" I can update the wiki that will also indicate this scenario more specifically.
(In reply to Maor from comment #4) > Thanks for the info, I understand now. > The API request > vms/73f21062-3fa5-4fc4-bd5a-8778d3240be9/snapshots/08decaa9-7727-458c-8471- > 3ec005be22f1/disks > fetched the disks data from the OVF. > Since in that time of the snapshot creation, those disks were qcow version > 0.10, even after you amend the disk you still see the version in the OVF of > the snapshot, which I think is ok since it tells the user what was the qcow > version in that time. > Regarding the qcow version in the OVF, functionality wise it is not > relevant, since the qcow version is determined by the VDSM. > > Based on the functionality section in > http://www.ovirt.org/develop/release-management/features/storage/qcow2v3/: > "new QCOW volumes that will be created on a V4 Storage Domains will be > created with 1.1 compatibility level. That also includes snapshots" > > I can update the wiki that will also indicate this scenario more > specifically. In amend you change QCOW version of both diskX + all disksnapshots of that diskX. So when you use GET API from VM/<snapshot-id>/disks you get the snapshot disks at the point in time when the snapshot was taken , right ? This is what is confusing here from my POV : If you change the disksnapshots ( which is the same disk in different point in time) qcow_version its like you are changing its qcow_version of the disk in all of the points in time snapshot was taken . Can you please clarify here or in wiki .
Can not Verify due to Bug 1445950 (qoow_version field does not exist from vms path)
Maor , This bug still can not be verified due to Bug 1445950 (qcow_version field does not exist from vms path). If the fix is not to show qcow_version than from the vms path than please close this bug as won't fix .
GET API from VM/<snapshot-id>/disks returns the snapshot's disks at a specific point in time when the snapshot was taken, based on the snapshot's OVF. The QCOW compat from the OVF might be misleading for two reasons: 1. Once amend is being executed on the snapshot's volume, the volume's compatibility level is changed and the OVF will reflect wrong QCOW compat. 2. Reflecting the compatibility level of the snapshot might be misleading once previewing a snapshot, since a new volume will be created with compatibility level compatible to the storage domain's version. Because of that reason, the compatibility level will not be part of the OVF. The VM's API: /VM/<snapshot-id>/disks, reflects the data from the snapshot's OVF and therefore the compatibility level will not be reflected from this API. The QCOW volume's compatibility level of the snapshots will be reflected only through the storage domain's API, for example: /storagedomains/1111/disksnapshots Since /VM/<snapshot-id>/disks does not reflect any QCOW compat data based on Avihai's comment in https://bugzilla.redhat.com/show_bug.cgi?id=1430447#c6, we can assume this is the right approach. After discussing this approach/behavior with Tal it was decided to close this bug as not a bug. (Avihai, I think we can also mark this bug as verified since the QCOW compat is not reflected through the OVF. Please feel free to change the status if you think otherwise.)