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 <derez(a)redhat.com>; Nir Soffer <nsoffer(a)redhat.com&gt; Cc: pchavva(a)redhat.com; Suchitra Herwadkar <Suchitra.Herwadkar(a)veritas.com>; Abhay Marode <Abhay.Marode(a)veritas.com>; DL-VTAS-ENG-NBU-Midas <DL-VTAS-ENG-NBU-Midas(a)veritas.com>; Himani Vaidya <Himani.Vaidya(a)veritas.com&gt; 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 <derez@redhat.com<mailto:derez@redhat.com>>; Nir Soffer <nsoffer@redhat.com<mailto:nsoffer@redhat.com>> Cc: pchavva@redhat.com<mailto:pchavva@redhat.com>; Suchitra Herwadkar <Suchitra.Herwadkar@veritas.com<mailto:Suchitra.Herwadkar@veritas.com>>; Abhay Marode <Abhay.Marode@veritas.com<mailto:Abhay.Marode@veritas.com>>; DL-VTAS-ENG-NBU-Midas <DL-VTAS-ENG-NBU-Midas@veritas.com<mailto:DL-VTAS-ENG-NBU-Midas@veritas.com>>; Himani Vaidya <Himani.Vaidya@veritas.com<mailto:Himani.Vaidya@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.