Just some info.
When the disk is being created , but the new VM wizzard is still active (so no new VM yet), once you click Edit on the disk - the disk is marked as 'Preallocated' and the drop down is grayed out.

It seems that my previous comment is not completely true - when pressed Edit -> the disk is again preallocated , but the dropdown allows changing. Clicking "OK" and again into "Edit" shows that the disk is again preallocated.

Some more info on this issue:

1) The issue has a simple reproduction by creating via webadmin a thin glusterfs SD floating disk => preallocated this is created.
2) This does not occur in ovirt-engine 4.2.8.6-0.1.el7ev thus regression.
3) Issue occur only on glusterfs , nfs works fine.
4) The default allocation policy for glusterfs is 'preallocated'(it was thin in 4.2 and it's thin for an NFS SD)
4) Attached a video capture showing the issue.
5) Work around -> Via RESTAPI creation of a glusterfs disk works fine .

RESTAPI used, gluster storage domain id = "db1acaed-4380-4501-a951-537bf6827e51" :

method:
POST

Body:
<disk>
  <storage_domains>
    <storage_domain id="db1acaed-4380-4501-a951-537bf6827e51"/>
  </storage_domains>
  <name>restGlusterthin</name>
  <provisioned_size>1073741824</provisioned_size>
  <format>cow</format>
</disk>

From Engine we see the disk creation is with volumeFormat='RAW':

2019-05-06 08:44:06,449+03 INFO  [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand] (default task-155) [794f5027-8382-48f4-ab47-ec3493df6df2] START, CreateImageVDSCommand( CreateImageVDSCommandPa
rameters:{storagePoolId='126908b3-4afb-4492-acdf-5dad110cae40', ignoreFailoverLimit='false', storageDomainId='db1acaed-4380-4501-a951-537bf6827e51', imageGroupId='38a919dc-7422-4954-9897-ec1bc59955d5', imageSiz
eInBytes='1073741824', volumeFormat='RAW', newImageId='36badbbf-5b55-49d7-8d89-89c99561c45f', imageType='Preallocated', newImageDescription='{"DiskAlias":"gluster_thin_disk3","DiskDescription":""}', imageInitia
lSizeInBytes='0'}), log id: a49748b

Created attachment 1564224 [details]
video_capture_engine_vdsm logs_4.3.3.3-0.1.el7

Should I expect a fix in 4.3.4 ?

This bug report has Keywords: Regression or TestBlocker.
Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.

Verified at ovirt-engine 4.3.4.1-0.1.el7.

Details:
Creating a thin-provisioned disk via webadmin -> disk is created as thin-provisioned as expected.
Tested gluster/iscsi/NFS storage flavors.
Tested also that preallocated allocation policy disks are created as expected.

Engine log output shows imageType='Sparse' as expected checked via also via UI/REST get commands for the created disk.

2019-05-26 13:12:36,474+03 INFO  [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand] (default task-4) [4709636f-fb8d-4fb6-b986-fe55ebe6182b] START, CreateImageVDSCommand( CreateImageVDSCommandPara
meters:{storagePoolId='6138aa72-4b02-4706-ae6a-30209d52402e', ignoreFailoverLimit='false', storageDomainId='97e00877-9224-4a21-be41-64b9856a2a14', imageGroupId='9c01bb5f-bec3-416c-acf1-8edf5394311e', imageSizeI
nBytes='1073741824', volumeFormat='RAW', newImageId='32f7e210-f002-4deb-a2ed-e96f7c69910d', imageType='Sparse', newImageDescription='{"DiskAlias":"vm1_Disk1","DiskDescription":""}', imageInitialSizeInBytes='0'}
), log id: 201d6ffe

Just tested with ovirt 4.3.4 RC2 and the default policy is still Preallocated.
Yet , when selecting "Thin Provision" - it works :

[root@ovirt1 2fc0f871-34c4-44ff-821f-ca7a93f17d22]# qemu-img info 1df3ab4b-b58b-4de3-8b4e-813084002c55
image: 1df3ab4b-b58b-4de3-8b4e-813084002c55
file format: raw
virtual size: 20G (21474836480 bytes)
disk size: 779M

Should we expect that the default policy is returned to "Thin Provision" ?

Just installed oVirt 4.3.4 RC3 on the engine and the default policy is still "Preallocated".

(In reply to Strahil Nikolov from comment #11)
> Should we expect that the default policy is returned to "Thin Provision" ?

AFAIK, the fix only handled only the "doesn't allow creation of VM with Thin Provision" and left the default policy of gluster disk to be "Preallocated".

See https://gerrit.ovirt.org/#/c/100180 commit message :

"

The fix caused setting the volume format of each Gluster based disk
to preallocated even if the user requested for sparse volume.

This patch reverts this behavior and set only the default value
of a Gluster based storage domain disk to be preallocated and allow to
the user to select different volume format.
"

Eyal, as the one who fixed this issue, what is your take on this?

As the bug is a regression, shouldn't all issues to be fixed in order to claim it fixed?
If not, please update me so I can open a new bug for restoring the default policy (so it can be consistent with other file-based storages' policies).

The default was changed due to bug 1644159


However, i can't reproduce this performance disparity between thin and preallocated disks. I get the same speeds (roughly 900MB/s on 10GB networking), on both disk types. Should bug 1644159 be re-evaluated?

Hm... despite the fact that my setup is 'exotic' (using gluster v6.1 from CentOS repos), I also noticed that "Preallocates" perform better (but I never calculated the performance diff).

What is your test setup's gluster options ? The only difference I have noticed recently is that read.local is explicitly set to 'no' (virt gluster group) and had issues with direct I/O not enabled.

Maybe 1644159 should be reevaluated , but gluster options should be checked. Maybe something else in the defaults has been changed.

I'm using gluster 5 from ovirt repo.

I have changed some options, as many of the defaults for ovirt are based on old gluster bugs that don't exist anymore, they probably should be re-evaluated.

features.barrier: disable
cluster.choose-local: off
performance.client-io-threads: on
nfs.disable: on
transport.address-family: inet
user.cifs: off
auth.allow: *
performance.quick-read: off
performance.read-ahead: on
performance.io-cache: off
performance.low-prio-threads: 32
network.remote-dio: off
cluster.eager-lock: enable
cluster.quorum-type: auto
cluster.server-quorum-type: server
cluster.data-self-heal-algorithm: full
cluster.locking-scheme: granular
cluster.shd-max-threads: 8
cluster.shd-wait-qlength: 10000
features.shard: on
storage.owner-uid: 36
storage.owner-gid: 36
performance.strict-o-direct: on
cluster.granular-entry-heal: enable
network.ping-timeout: 30
performance.io-thread-count: 32
client.event-threads: 4
server.event-threads: 8
performance.stat-prefetch: on
performance.flush-behind: on
performance.write-behind-window-size: 64MB
auto-delete: enable

(In reply to Alex McWhirter from comment #17)
> I'm using gluster 5 from ovirt repo.
> 
> I have changed some options, as many of the defaults for ovirt are based on
> old gluster bugs that don't exist anymore, they probably should be
> re-evaluated.
> 
> features.barrier: disable
> cluster.choose-local: off
> performance.client-io-threads: on
> nfs.disable: on
> transport.address-family: inet
> user.cifs: off
> auth.allow: *
> performance.quick-read: off
> performance.read-ahead: on
> performance.io-cache: off
> performance.low-prio-threads: 32
> network.remote-dio: off
> cluster.eager-lock: enable
> cluster.quorum-type: auto
> cluster.server-quorum-type: server
> cluster.data-self-heal-algorithm: full
> cluster.locking-scheme: granular
> cluster.shd-max-threads: 8
> cluster.shd-wait-qlength: 10000
> features.shard: on
> storage.owner-uid: 36
> storage.owner-gid: 36
> performance.strict-o-direct: on
> cluster.granular-entry-heal: enable
> network.ping-timeout: 30
> performance.io-thread-count: 32
> client.event-threads: 4
> server.event-threads: 8
> performance.stat-prefetch: on
> performance.flush-behind: on
> performance.write-behind-window-size: 64MB
> auto-delete: enable

I think that the discussion should continue under bug 1644159.
It is not relevant for this bug.

I agree. This one is OK while bug 1644159 should be reevaluated.

This bugzilla is included in oVirt 4.3.4 release, published on June 11th 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.3.4 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.

*** Bug 1728019 has been marked as a duplicate of this bug. ***