On Mon, Mar 26, 2018 at 11:41 AM Richard W.M. Jones <rjones@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

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.