Bug 1702237 - [RFE] add API for listing disksnapshots under disk resource
Summary: [RFE] add API for listing disksnapshots under disk resource
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.2.8-3
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ovirt-4.4.4
: ---
Assignee: Ahmad Khiet
QA Contact: Shir Fishbain
URL:
Whiteboard:
Depends On:
Blocks: 1691340 veritasrhv4.4features
TreeView+ depends on / blocked
 
Reported: 2019-04-23 09:53 UTC by agjadhav@gmail.com
Modified: 2021-02-02 13:57 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-02-02 13:57:12 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2021:0381 0 None None None 2021-02-02 13:57:41 UTC
oVirt gerrit 111062 0 master MERGED storage: list disk snapshots under disks resource 2021-02-02 10:46:37 UTC
oVirt gerrit 111063 0 master MERGED restapi: list disk snapshots call under disks resource 2021-02-02 10:46:37 UTC
oVirt gerrit 111373 0 master MERGED Upgrade: model 4.4.18, metamodel 1.3.2 2021-02-02 10:46:37 UTC
oVirt gerrit 111380 0 master ABANDONED restapi: added override to list disk snapshots api 2021-02-02 10:46:37 UTC
oVirt gerrit 111388 0 master ABANDONED Reintroduce: restapi: list disk snapshots call under disks resource 2021-02-02 10:46:37 UTC
oVirt gerrit 111400 0 master ABANDONED restapi: list disk snapshots call under disks resource 2021-02-02 10:46:38 UTC

Description agjadhav@gmail.com 2019-04-23 09:53:57 UTC
Description of problem:
After taking the snapshot of VM deployed from template or has a user snapshot, we get the disk ID for backup operation. If this disk is of qcow2 format, we get the "Disk snapshot ID" of backing store (parent disk) in it's header. We would like to know the REST API to find the provisioned size of this parent disk without knowing the storage domain.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Fred Rolland 2019-04-29 13:28:14 UTC
Daniel,
Do we have a way to get this information?
Thanks

Comment 2 Daniel Erez 2019-04-29 17:31:57 UTC
(In reply to agjadhav from comment #0)

The storage domain can be retrieved from the 'disk' resource:
e.g. /ovirt-engine/api/disks/123
<disk href="/ovirt-engine/api/disks/123" id="123">
...
  <storage_domains>
    <storage_domain href="/ovirt-engine/api/storagedomains/456" id="456"/>
  </storage_domains>
</disk>

Disk-snapshot resources can be fetched either from the storage domain:
- https://derezengine.usersys:8443/ovirt-engine/api/storagedomains/123/disksnapshots
or directly from the vm snapshot:
- https://derezengine.usersys:8443/ovirt-engine/api/vms/123/snapshots/456/disks

* Is it sufficient for your use case? What is the exact flow?

Comment 3 Pavan Chavva 2019-05-13 17:42:56 UTC
Hi Ajay,

Can you reply for the above comment?

Best,
Pavan.

Comment 4 agjadhav@gmail.com 2019-05-14 06:11:42 UTC
Hi Pavan,

The solution suggested is a two step process. First fetch the list of storage domains and then fetch disk info in each storage domain. 
This is a lengthy process to be done when backup process is about to start or is already in progress.

Specifically in case of QCOW2 image transfer, the backup process has already started when we encounter the backing file in it's header.
We need RHV solution to be in the form of just one API call like, image transfer API which takes only "disk_id" as input.

Thanks & Regards,
Ajay Jadhav
(ajay.jadhav)

Comment 5 Pavan Chavva 2019-05-14 12:18:03 UTC
Thanks Ajay!

@Daniel,

Is comment 4 information sufficient for us to target this for RHV 4.4?

Best,
Pavan.

Comment 6 Daniel Erez 2019-05-19 08:33:25 UTC
Hi Ajay,

IIUC, you'd like a new API for getting a disk snapshot directly from the disk entity?
I.e. /ovirt-engine/api/disks/123/disksnapshots/456/

Do you need it only for snapshot creation flow? 
If so, you can try using this API: /ovirt-engine/api/vms/123/snapshots/456/disks
Which should give you information on the disk snapshots.

Comment 7 agjadhav@gmail.com 2019-06-19 12:21:16 UTC
Hi Daniel,

Pls. see my comments inline,

IIUC, you'd like a new API for getting a disk snapshot directly from the disk entity?
I.e. /ovirt-engine/api/disks/123/disksnapshots/456/

Ajay -> We expect the new API should use the disk_snapshot_id stored in qcow2 backing file.
        This is to retrieve it's provisioned size without iterating through storage domains.

Do you need it only for snapshot creation flow? 
If so, you can try using this API: /ovirt-engine/api/vms/123/snapshots/456/disks
Which should give you information on the disk snapshots.

Ajay -> This API does not help in case of finding the provisioned size of template disk. 
        Also we want to use the API after snapshot operation is complete. i.e. during
        backup phase

Thanks,
Ajay & Gaurav

Comment 8 Pavan Chavva 2019-06-19 13:23:17 UTC
For comment 7.

Thanks,
Pavan.

Comment 9 Pavan Chavva 2019-06-19 13:23:18 UTC
For comment 7.

Thanks,
Pavan.

Comment 10 Daniel Erez 2019-07-02 12:58:03 UTC
(In reply to agjadhav from comment #7)
> Hi Daniel,
> 
> Pls. see my comments inline,
> 
> IIUC, you'd like a new API for getting a disk snapshot directly from the
> disk entity?
> I.e. /ovirt-engine/api/disks/123/disksnapshots/456/
> 
> Ajay -> We expect the new API should use the disk_snapshot_id stored in
> qcow2 backing file.
>         This is to retrieve it's provisioned size without iterating through
> storage domains.

ok, so it should be available when we introduce a new api:
/ovirt-engine/api/disks/{disk_id}/disksnapshots/{disk_snapshot_id}

I'll define this bug as an RFE for that.

> 
> Do you need it only for snapshot creation flow? 
> If so, you can try using this API:
> /ovirt-engine/api/vms/123/snapshots/456/disks
> Which should give you information on the disk snapshots.
> 
> Ajay -> This API does not help in case of finding the provisioned size of
> template disk. 
>         Also we want to use the API after snapshot operation is complete.
> i.e. during
>         backup phase

Template disks are separated in the API from VM disks.
For querying info on a specific template disk, try the following:

1. List templates disk_attachments: /ovirt-engine/api/templates/{template_id}/diskattachments
2. Get disk href from the disk_attachment.
3. Get disk /ovirt-engine/api/disks/{disk_id}

E.g.
<disk_attachments>
   <disk_attachment href="/ovirt-engine/api/templates/647e7a3d-af49-4be7-8897-9f96d0b4cd05/diskattachments/385019c8-f6d6-498c-8fcb-c14249bbf5d1" id="385019c8-f6d6-498c-8fcb-c14249bbf5d1">
      ...
      <disk href="/ovirt-engine/api/disks/385019c8-f6d6-498c-8fcb-c14249bbf5d1" id="385019c8-f6d6-498c-8fcb-c14249bbf5d1"/>
      <template href="/ovirt-engine/api/templates/647e7a3d-af49-4be7-8897-9f96d0b4cd05" id="647e7a3d-af49-4be7-8897-9f96d0b4cd05"/>
      <vm href="/ovirt-engine/api/vms/647e7a3d-af49-4be7-8897-9f96d0b4cd05" id="647e7a3d-af49-4be7-8897-9f96d0b4cd05"/>
      ...
   </disk_attachment>
</disk_attachments>


> 
> Thanks,
> Ajay & Gaurav

Comment 14 Shir Fishbain 2020-12-03 16:27:23 UTC
Verified

rhv-4.4.4-3
ovirt-engine-4.4.4.2-0.1.el8ev.noarch
vdsm-4.40.38-1.el8ev.x86_64

<disk_snapshots>
  <disk_snapshot href="/ovirt-engine/api/disks/80cd98ab-0f4c-4bca-818e-396de48a5063/disksnapshots/ed955100-ab6b-4301-97a0-5a81f095fb52" id="ed955100-ab6b-4301-97a0-5a81f095fb52">
    <name>new_vm_from_template_Disk1</name>
    <description></description>
    <actual_size>1073741824</actual_size>
    <alias>new_vm_from_template_Disk1</alias>
    <backup>none</backup>
    <content_type>data</content_type>
    <format>cow</format>
    <propagate_errors>false</propagate_errors>
    <provisioned_size>16106127360</provisioned_size>
    <qcow_version>qcow2_v3</qcow_version>
    <shareable>false</shareable>
    <sparse>true</sparse>
    <status>ok</status>
    <storage_type>image</storage_type>
    <total_size>0</total_size>
    <wipe_after_delete>false</wipe_after_delete>
    <disk_profile href="/ovirt-engine/api/diskprofiles/68daee10-6115-422b-90a3-78641b7619f5" id="68daee10-6115-422b-90a3-78641b7619f5" />
    <quota href="/ovirt-engine/api/datacenters/7e7ffcd1-b1fb-415a-9573-b26b9a28190b/quotas/e6db9e8f-b290-46b1-9d77-0c714c692c3d" id="e6db9e8f-b290-46b1-9d77-0c714c692c3d" />
    <snapshot id="5a4d9314-84a3-4b42-a3be-fa1aba9b2077" />
    <storage_domains>
      <storage_domain href="/ovirt-engine/api/storagedomains/8d0b3973-fa6f-4ae8-b995-b44fc0dd39fb" id="8d0b3973-fa6f-4ae8-b995-b44fc0dd39fb" />
    </storage_domains>
    <disk href="/ovirt-engine/api/disks/80cd98ab-0f4c-4bca-818e-396de48a5063" id="80cd98ab-0f4c-4bca-818e-396de48a5063" />
  </disk_snapshot>
</disk_snapshots>

Comment 18 errata-xmlrpc 2021-02-02 13:57:12 UTC
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 (Low: RHV-M(ovirt-engine) 4.4.z security, bug fix, enhancement update [ovirt-4.4.4]), 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://access.redhat.com/errata/RHSA-2021:0381


Note You need to log in before you can comment on or make changes to this bug.