vSphere 4’s thin provisioning is a pretty cool feature, but it has downsides, too. I was putting together a concise list of pros & cons for a customer, and I thought I’d share (especially given all the thin provisioning talk lately). Please leave me a comment if I’ve missed something.
- Saves disk space where it isn’t really being used by permitting overcommitment, 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 VMotions, 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.
- Requires VM hardware version 7. Not the case — 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 filesystem blocks negate almost all benefits of thin provisioning.
- Overcommitment 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 fragmentation, 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, and 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.