VMware vSphere 4 Thin Provisioning: Pros & Cons

vSphere 4′s thin provisioning is a pretty cool feature, but it has downsides, too.

Pros & cons for a customer, especially given all the thin provisioning talk lately.

Pros:

• Saves disk space where it isn't really being used by permitting over commitment, meaning:
• more VMs per datastore, which, for local datastores, means more VMs per host.
• better utilization of expensive storage.
• Smaller disk allocations translate into faster storage VMotion s, clones, snapshot operations. You are only copying what needs to be copied.
• Incredibly easy to convert to and from thin-provisioned disks, on the fly, using Storage VMotion.
• More flexible disk allocation strategies. VMs could have extra, unallocated space built into them, making it easy to grow later without adding additional virtual disks but not consuming all that space initially.

Cons:

• Changed block tracking is a VM v.7 feature, but thin provisioning can be done with v.4 hardware, too.
• Cannot use other advanced features of vSphere 4, such as Fault Tolerance.
• Normal maintenance operations, such as defragmentation, use of sdelete, etc., rapidly & irreversibly negate thin provisioning by causing blocks to be changed. This is especially important as strategies to maximize deduplication by zeroing filesys! tem blocks negate almost all benefits of thin provisioning.
• Over commitment of storage adds the risk that a volume may fill, causing a denial-of-service for other VMs. This can be through malicious behavior by a customer, through normal day-to-day use of VMs, or through well-intentioned but uninformed behavior (such as running a defragmenter, etc.).
• Thin provisioning may have performance concerns:
• The gradual growth of a VMDK file will likely cause fragmen! tation, which may be a performance issue. On disk arrays that are already subject to fragmentation, such as those from NetApp, the effect may be more severe. However, Storage VMotion operations also serve to defragment virtual disks.
• More VMs per LUN may introduce storage I/O performance issues.
• General understanding of how filesystems work is low. Add to that a general lack of understanding of how thin provisioning works, and how it would interact with other technologies like deduplication and snapshots, and I can see the potential for colossal mishaps.

Some of the cons are mitigated with better monitoring strategies. vCenter has a number of new ways to monitor thin provisioned VMs, and notify when datastores fill. However, if you're doing deduplication on your storage array you might have to choose which technology to go with. Many people use sdelete or custom scripts to zero out empty filesystem space so that deduplication can identify and deduplicate free space. Running "sdelete -c" on a thin-provisioned 40 GB VMDK file causes it to grow to 40 GB, though. On the back end I know it's being deduplicated very well, but on the front end it isn't thin anymore, and can't be made thin again with Storage VMotions because all those blocks have been "touched." Coupled with fragmentation and other performance issues, users of deduplicating arrays (NetApp, etc.) might consider not thin provisioning for now, a! nd work to improve their back-end deduplication rates instead.

P.S. if thin provisioning were coded to recognize zeroed blocks it'd be a different story altogether. Then normal filesystem use (file creates, deletes, etc.), or use of sdelete, defragmenters, etc. wouldn't be a problem at all.