Hi Nir, Daniel And Devel Guys,

We have query regarding initial size attribute that we need specify in create 
disk  API  for qcow2 format.

As per our discussions with you all it came up that we need initial size to be 
specified at qcow2 disk creation/restore so that that much size is preallocated.
Based on that we specify request body for qcow2 to /ovirt-engine/api/disks as 
follows:-

<disk>
<storage_domains> <storage_domain id="aaaa"/> </storage_domains>
<name>mydisk</name>
<provisioned_size>xxxx</provisioned_size>
<initial_size>yyyy<initial_size>
<format>cow</format>
</disk>

Consider provisioned_size = 1 GB (Guest offset)(raw thick disk)
Initial_size = > 1GB
Initial_size > provisioned_size

Also as per disk struct specified in 
http://ovirt.github.io/ovirt-engine-api-model/4.3/#types/disk
Initial_size and provisioned size both are different attributes .Therefore 
these need to specified differently as per above request body.

But unfortunately  we saw it fails at write offset greater that provisioned 
size at data restore time. It doesn't consider initial_size attribute specified 
in request body
only considers provisioned size .

Can you please confirm whether for COW format what attributes and actual 
values(consider 1GB example)  are needed in request body of create disk API 
/ovirt-engine/api/disks  ?

Thanks
Himani Vaidya

From: Mohammed Eliyas Shaikh
Sent: Thursday, January 31, 2019 8:39 PM
To: Daniel Erez <de...@redhat.com>; Nir Soffer <nsof...@redhat.com>
Cc: pcha...@redhat.com; Suchitra Herwadkar <suchitra.herwad...@veritas.com>; 
Abhay Marode <abhay.mar...@veritas.com>; DL-VTAS-ENG-NBU-Midas 
<dl-vtas-eng-nbu-mi...@veritas.com>; Himani Vaidya <himani.vai...@veritas.com>
Subject: RE: Query regarding initial size for QCOW2 file restore

Hi Pavan,

Can we get direct number of Nir / Daniel to check if they are available for a 
short call now?

Thanks,
Mohammed Eliyas.

From: Mohammed Eliyas Shaikh
Sent: Thursday, January 31, 2019 1:39 PM
To: Daniel Erez <de...@redhat.com<mailto:de...@redhat.com>>; Nir Soffer 
<nsof...@redhat.com<mailto:nsof...@redhat.com>>
Cc: pcha...@redhat.com<mailto:pcha...@redhat.com>; Suchitra Herwadkar 
<suchitra.herwad...@veritas.com<mailto:suchitra.herwad...@veritas.com>>; Abhay 
Marode <abhay.mar...@veritas.com<mailto:abhay.mar...@veritas.com>>; 
DL-VTAS-ENG-NBU-Midas 
<dl-vtas-eng-nbu-mi...@veritas.com<mailto:dl-vtas-eng-nbu-mi...@veritas.com>>; 
Himani Vaidya <himani.vai...@veritas.com<mailto:himani.vai...@veritas.com>>
Subject: Query regarding initial size for QCOW2 file restore

Hi Nir and Daniel,

We had a few questions around restoring a qcow2 file to RHV.
We plan to support restoring a qcow2 file to RHV. The source of the backups 
could be from RAW thin/thick or qcow2.
When restoring qcow2 we need to provide an initial size. The backup image being 
restored will have guest data in fragments. When writing these fragments into 
the qcow2 file we would need to pad them to the qcow2 cluster boundary for 
every fragment. When providing the initial size to RHV we should have included 
the amount of padding we would need for every fragment and this would be 
difficult to get upfront when the qcow2 file is being created at restore time. 
It will be a function of the guest data fragmentation which would be difficult 
to get upfront at the start of the restore.

We would like to check if there is an easy way around this situation from the 
RHV side.

  1.  Can we make the initial size requirement optional when creating a qcow2 
file?
  2.  If not then
     *   Can we write beyond the initial size we provided when creating the 
file?
     *   Can we use the provisioned size of the virtual disk as the initial 
size of the qcow2 file (after adding size for headers) and then truncate the 
file to its actual size after writing the file completely. Though we could run 
into cases where customers don't have enough space for the provisioned size.

Any other ideas to work around this initial size requirement.

Thanks,
Himani and Mohammed Eliyas.

_______________________________________________
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/2GMKMZIBMEMRNSNPML6CVBW7TPBLUUYR/

Reply via email to