We use thick LUNs always, and thin datastores frequently.

Capacity:  Obviously, you lose over-subscription at the LUN level.  As the 'storage guy' that makes my life easier, by putting the burden for monitoring capacity shortages on the VMWare admins, but I honestly think that is better than either sharing that, or reversing it.  In our environment I tend to provision out all new storage to our various clusters as soon as it is installed and configured, then just maintain and troubleshoot on an on-going basis rather than hand out, and extend, LUNs as they are needed.  Our storage administration group is me...and a fraction of one other guy to cover for vacations and such, for ~10+PBs of arrays; that drives me to spend more time on engineering, configuration, and install/decommissioning, so that I need less time for ad-hoc work.

Performance:

Thin LUNs on backend storage can provide geographical locality of reference when they are first created; all the data from all the LUNs in a pool are physically close together on the disk platters, so seek times are better than if they were thick, and had big jumps between them.

As they age though, thin LUNs that become relatively 'fat' can show some performance degradation by being scattered.  This is most pronounced in end-to-end operations like full backups.  So thin works best for things that are never going to (or at least unlikely to) use most of their allotted size.

We also notice that thin/lazy datastores can experience a 'paving the way' penalty during restores and storage VMotions.  Some arrays handle that better, by not bothering to actually write zero blocks.

Generally we use thick LUNs throughout the environment, and thin datastores for 'cattle', but often thick datastores for 'pets'.

Hello,

The main recommendation is to use Thin LUNs. Here's a reply I put on another post:

From the VNX with MCx Virtual Provisioning White Paper, page 42:

For VMware environments, the Virtual Machine File System (VMFS) has many

characteristics that are thin-friendly. First, a minimal number of thin extents are

allocated from the pool when a VMware file system is created on thin LUNs. Also, a

VMFS Datastore reuses previously allocated blocks that are beneficial to thin LUNs.

When using RDM volumes, the file system or device created on the guest OS dictates

whether the RDM volume is thin-friendly.

When creating a VMware virtual disk, LUNs can be provisioned as:

 Thick Provision Lazy Zeroed

 Thick Provision Eager Zeroed

 Thin Provision

Thick Provision Lazy Zeroed is the default and recommended virtual disk type for thin

LUNs. When using this method, the storage required for the virtual disk is reserved in

the Datastore, but the VMware kernel does not initialize all the blocks at creation.

The VMware kernel also provides other mechanisms for creating virtual drives that are

not thin-friendly. The Thick Provision Eager Zeroed format is not recommended for

thin LUNs because it performs a write to every block of the virtual disk at creation.

This results in equivalent storage use in the thin pool.

When using Thin Provision, space required for the virtual disk is not allocated at

creation. Instead, it is allocated and zeroed out on demand.

As of vSphere 5, there is also the ability to perform thin LUN space reclamation at the

storage system level. VMFS 5 uses the SCSI UNMAP command to return space to the

storage pool when created on thin LUNs. SCSI UNMAP is used any time VMFS 5

deletes a file, such as Storage vMotion, delete VM, delete snapshot, etc. Earlier

versions of VMFS would only return the capacity at the file system level. vSphere 5

greatly simplifies the process by conducting space reclaim automatically.

In addition, features such as VMware DRS, Converter, VM Clones, Storage vMotion,

Cold Migration, Templates, and vMotion are thin-friendly.

For the full paper:

https://www.emc.com/collateral/white-papers/h12204-vp-for-new-vnx-series-wp.pdf

- You can covert a Thick LUN to a Thin one, but not vice versa. But you can migrate any type of LUN.

- Thin LUNs' performance is limited compared to Thick or Classic LUNs, due to the overhead associated with Thin LUN provisioning. You trade off performance for ease or management and efficiency.

Hope this helps.
Post back with any further questions.

Adham