Why are Thick provisioned disks showing as thin

[mpatriche]

We have a new vSAN and are trying to migrate VM's to it VMware 6 to 6.7.

On the vSAN system we created a new Storage Policy that call for Object Space Reservation to be THICK. I have made this the default policy.

When we migrate a VM to 6.7 we also tell the wizard to set the disk as Thick.

When we check vSphere after the migration it says the drive is THIN. The same is true when running scripts for the drive type.

We have also taken a VM that was marked as THIN and inflated the VMDK to turn it into a THICK file but it still shows as THIN

Is the thick provisioning just for show?

[a_p_]

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.

André

[TheBobkin]

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).

Bob