On Mon, Mar 26, 2018 at 11:41 AM Richard W.M. Jones <rjones(a)redhat.com>
wrote:
On Sun, Mar 25, 2018 at 08:05:14PM +0000, Nir Soffer wrote:
> When using the sdk, you can select both the image format and sparse, so
you
> can create invalid combinations. oVirt selects the allocation for you.
>
> storage type image format sparse | allocation creating
>
-----------------------------------|--------------------------------------------------------
> file qcow2 true | thin sparse file of image
> size bytes
> file raw false | preallocated preallocated file of
> provisioned_size bytes
> file raw true | thin sparse file of
> provisioned_size
> bytes
> file qcow2 false | - unsupported
> block qcow2 true | thin logical volume of
> initial_size bytes
> block raw false | preallocated logical volume of
> provisioned_size bytes
> block qcow2 false | - unsupported
> block raw true | - unsupported
>
> The only case when selecting the sparse value is useful is raw file
> on file based storage domain, allowing creation of sparse or preallocated
> disk.
I don't think this is true. Both LVs (lvmthin) and SAN LUNs can
support sparse allocation meaningfully.
"sparse" is just another way for selecting "thin" or
"preallocated"
allocation
policy. In oVirt we emulate thin volume on block storage using regular
logical
volumes.
lvmthin does not support sharing a logical volume in a cluster. SAN LUN can
support
thin provisioning, but we don't support upload to LUN yet.
Nir