Virtualization: Top 3 Limitations of Thin Provisioning

In my previous post, I discussed reasons why thin provisioning generally is the best way to allocate disk space in virtual storage scenarios. Why? Because of:

1. Flexibility
2. Savings

With thin provisioning you can create multiple VMs (virtual machines) on a physical hard drive without worrying whether you have the space to cover it because your hypervisor will apportion only the amount of space the VM is using. As a result, you can buy more storage space as you need it, rather than having to guess the amount ahead of time. But thin provisioning does have its limitations. Here are the three most common disadvantages I’ve come across so far: 1. Decreased Performance I’ve read several posts and threads debating the difference in performance between thin provisioned VMs and thick provisioned ones. The general consensus? Thin provisioning doesn’t offer the same level of performance of thick provisioning. A Server Fault thread discusses the risk of thin provisioned disks becoming heavily fragmented, which affects overall performance. As commenter wazoox explains:

[T]he performance hit is mostly fragmentation. When initializing a drive, all its block[s] are contiguous…while they may become heavily fragmented when thin-provisioned. "Monitoring the size and extending it" simply doesn't happen; sparse files are actually a "free" file system feature and they simply grow automatically when blocks are allocated to them.

But on a recent Spiceworks thread, Scott Alan Miller of MSP Niagara Technology Group says that, in most cases, the difference is nominal, and worrying about it is counterproductive for most SMBs:

Unless you have a latency sensitive, IO bound application [emphasis mine], thick is rarely a good choice. It just brings too many problems or lack of advantages…The problem is…SMBs have a mindset, much of the time, of "performance over everything" when, in reality, performance is about the last thing that SMBs need. What they need is reliability, ease of management, cost management, etc.

2. Over-Allocating Space For simplicity’s sake, let’s say you have 1TB of physical storage. You could create 10 (or 100) thin-provisioned VMs of 200GB each, even though your physical storage couldn’t handle all of them if a majority of them neared their capacity, because currently each VM is using at most 50GB apiece. But what happens if you fail to monitor all those different VMs? As wazoox says,

If you ever run out of real disk space on thin provisioned storage where you over-allocated space, any write can bring a catastrophic failure on one or several VM drives, usually beyond any repair, so you'd better monitor your actual disk usage on the storage host carefully.

That’s a legitimate concern, but IT professionals should be monitoring that disk usage as a best practice in the data center. In the previously quoted Spiceworks thread, commenter Darth Hoody explains it better than I can:

The only reason NOT to thin provision is if you don't want to, know how to, or otherwise can't or won't monitor and manage your storage. Yes, if can definitely cause issues if you overprovision to the point where you run your datastores out of space and knock out all your VMs. There could be legit reasons for it, but to me it's wasteful and just bad practice. [Italics mine]

3. Lack of Elasticity Although thin provisioning lets you expand your disk space as you need it, the technology isn’t elastic. In other words, you can expand your space allocation, but you can’t contract it. SearchVirtualStorage, a TechTarget publication, discusses this problem in its post VMware thin provisioning: Pros and cons:

Thin provisioning creates disks that grow but don't really shrink; they don't return space back to the overall free pool. In the VMware case, if you create a thin-provisioned disk, it's going to grow; if you delete data off that disk, the VMDK is going to shrink so there will be more space available in that data store, but the data store doesn't shrink and so it won't be available to the array controller for other purposes -- unless the array controller does zero recognition, which a lot of array controllers that do thin provisioning do -- and you create either a zeroed thick [disk] or an eager-zeroed thick disk. Those types of disks will allocate disk space and fill it with zeroes.

When Steve Snyder and I chatted a couple of weeks ago, we agreed that one of the many hypervisor platforms out there will eventually come out with truly elastic provisioning. But neither of us has succeeded in finding any concrete news about this development. If you have heard or read something to this effect, please let us know in the comments!