This blog post explains when thick provisioning will be used: https://cormachogan.com/2014/05/13/vsan-part-24-why-is-vsan-deploying-thick-disks/
Btw. do you have a reason why you want to use thick provisioning on vSAN, other than for space reservation/allocation. Due to the way vSAN works, there's basically no performance benefit in using thick (even eager zereod thik) provisioning.
vSAN doesn't apply thickness at the vmdk-primitive level, we apply it on the data-objects themselves by reserving the space allocated to the Objects ( and thus as André alluded to above there are caveats such as dedupe+compression not benefitting any space-savings for these Objects).
Thus if you are using scripts that are intended for VMFS (e.g. checking for ddb.thinProvisioned = "1" etc.) then this won't work.
There are multiple ways of achieving the same checks on vSAN - some examples include:
- Checking proportionalCapacity=100 via RVC (e.g. against vsan.vm_object_info <pathToVm> or vsan.object_info <pathToObject> )
- The above can also be checked against the data from # esxcli vsan debug object list
- Via cmmds-tool data looking at reserved space (though of course this is not intended for normal users e.g. all in bytes not GB so any scripts have to apply formulae).
Having a google of the multiple times I have talked about looking at 'thick' Objects on Communties previously might give more insight (sorry I can't linky link more - on mobile as on holiday).