The only reason nowadays to select thick over thin provisioned disks in a VMware environment is for capacity management purposes.
Agree or disagree?
With the performance standards available today, the difference between thick and thin provisioned disks is so minimal that it is hard to even measure. Why pay up front for that storage space that you will never even get to use? If you are leveraging already the cloud mentality, why not pay/grow as you go?
Specially keeping in mind that most vDisks are created with a certain expectation in mind (always over provisioned) and you cannot shrink them later on (you can always add more space with the VM powered on, but shrinking a disk is a manual, time consuming process that requires downtime).
Thick provisioned vDisks on vSphere used to be evangelized in the past before SSDs were standard, but things have certainly changed. Nowadays there is no measurable performance gain, and you give end up giving up flexibility and savings over time.
Below is some information on a different hypervisor (AHV) that clearly states there is no different in their technology:
“Nutanix does not write zeros by design. When you create a Thick Eager Zero on the storage layer (Nutanix DSF) the behaviour is the same to creating a Thin Provisioned disk. Do you gain performance or do you lose performance? Is it better or is worse for you? The answer is ‘It is different’ on Nutanix then it would be on a traditional non-HCI system.
Nutanix was designed with performance in mind. Read/write latency is decreased by the use of the OpLog which is file-specific and is always located on Tier 0.
On a Nutanix system, there is no performance difference between thin and thick disks. This means that a thick eager zeroed virtual disk has no performance benefits over a thin virtual disk. With Nutanix, a thick disk is the one that includes a field in the configuration, which means that the resulting disk will be the same whether the disk is a thin or a thick disk (despite the configuration differences).”
More info here
