2:04 p.m.
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>
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>
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.