VM /ETC

VMware has been running a blogging contest in order to promote the new vSphere Blog. The current contest topic is vSphere Thin Provisioning. A lot has been written on this topic already, but I thought I would point out a storage design conclusion I’ve come up with based mostly from the explanations and recommendations of others about handling what happens when an over allocated, thin provisioned LUN runs out of space.

This post first walks through an basic explanation of the administrative concern caused by thin provisioning and how built in vSphere monitoring and alerting can be used to proactively handle an over allocation issue. I’m using quotes from a few bloggers to help describe the potential for problem and offer ways to handle it. At the end I make a simple LUN provisioning suggestion based on combining the vSphere feature with storage device’s thin provisioning capabilities. 

vSphere Thin Provisioning and over allocation

First of all VMware explains thin-provisioned virtual disks as a feature that lets you:

“subscribe more capacity to virtual machines than they actually have, eliminating the waste of resources and space caused by unused over-allocated storage.”

To be clear, VMware vSphere provides thin provisioning independent of any storage device’s similiar features. In fact, vSphere can create thin provisioned virtual disks on the local or shared storage (VMFS or NFS) of any ESX host.

VMware vSphere even makes it easy to convert existing guests to thin provsioned virtual hard disks. The blog post Using Storage VMotion to Leverage Thin Provisioning explains:

On the surface thin provisioining is great! If a virtual machine (VM) is created with a 20 GB C:\ drive with only 10 GB actually in use then that VM only takes up 10 GB of physical space of the physical storage. A problem arises after stacking multiple thin provisioned VMs in a storage volume, and then one or more of those VMs has data growth that “cashes in” in all of it’s allocated storage. To thier credit, VMware has thought this scenario through and provides monitoring and alerting to make sure administrators can be notified before this happens.

Here are a few blog post examples that demonstrate using vSphere monitoring and alerting of vSphere thin provisioning.

Responsible Thin Provisioning in VMware vSphere

“Now in vSphere 4 there is a new element in the capacity section of the datastore summary tab that shows total provisioned space — the maximum potential growth of all virtual machines if thin provisioned disks were fully utilized:

“

From that borrowed screen shot you can see that 371 GB of VM disks have been provisioned in a 49 GB LUN!

Get Thin Provisioning working for you in vSphere

“This is one of the most important pieces to thin provisioning in my opinion.  At the minimum you need to setup Virtual Center alerts to monitor when your datastores are approaching critical levels.  You can’t implement thin disks in your vSphere environment and walk away.  The smart people over at VMware have given us the ability to monitor datastore disk space usage and over-allocation with the latest release of Virtual Center.  Setup your monitors so you are e-mailed when some of these thin disks begin to grow and you need to take some action.”

PowerShell Prevents Datastore Emergencies

“When a datastore is about to run out of space, the fastest resolution may be to simply migrate virtual disks to another datastore.   VMware Storage VMotion provides that capability with zero downtime for VMs and no disruption to end users.”

Additional advice creating an alarm and the next screen shot is also provided in the same post

“Create a new alarm at an appropriate level in the vCenter hierarchy, such as a datacenter, and configure like this:

On the Triggers tab, add a “Datastore Disk Usage (%)” trigger to alert at a reasonable percentage — I opted for 93″

Combine vSphere Thin Provisioning with Storage Device Thin Provisioning

When you consider that a common feature of a lot of storage devices today is the ability to thin provision physical disk usage when creating LUNs regardless of which OS or file system will be used, you end up with the possibility to “double dip” thin provisioning with vSphere. Although a scarey thought for a lot of administrators, the possibility exists to do so. Personally, I’m not sold on the thin provisioning “double-dip”. Especially without a complete monitoring solution, a storage device’s ability to hot add disks or shelves to dynamically expand LUNs, and a budget that gets me new hardware ASAP!

However, I have no problem using storage device thin provisioning on the LUN created to hold ISO files for the VMs. Normally, this LUN would be provisioned < 50GB in size, but why not make it big enough to hold your largest VM + 20%? Thin provisioning from the storage device means it’s not actually taking up any space, but when your vSphere datastores need breathing room you could temporarily storage vmotion a VM or 2 to the ISO LUN as needed to resolve other over allocation issues.

Cashing in the storage needed for the ISO LUN still requires reserve physical disk capacity. Be aware that the same over allocation problem exists at the storage device level, but leveraging the hardware’s dynamic add ability gives an administrator more flexibility to re-allocate the capacity without taking systems down. For example, if some of your disk space is dedicated to LUN snap shots or VM backups, you might be able to afford to delete the oldest copies, free up some disk space, and then dynamically shrink/grow volumes/arrays/LUNs to create some needed space.

You could also provision a stand by LUN independent of the ISO LUN to accomplish the same purpose.

Does combining the storage thin provisioning with vSphere thin provisioning make sense to you? Any advantages or disadvantages I am missing with the strategy I describe in this post? Let me know!

Related Posts

• Real Thin Provisioning And Over Allocation – The VI Admin (28)
• Tap into vSphere PVSCSI Performance with Separate VM Boot and Data Drives (11)
• VCP4 Upgrade Deadline Extended to January 31st, 2010. Second Shot Testing Program Extended Also. (5)
• Don’t Hit Ctrl+Alt+Del On the ESX 4 Console (12)
• Quick List Of VCP 4 Study Links Posts (16)
• vSwitch With Multiple VMKernel Portgroups for vSphere iSCSI Round Robin MPIO (12)
• Recommended Reading (0)
• vSphere 4.0 Best Practices (6)
• Reasons For Using NFS With VMware Virtual Infrastructure (14)
• vSphere Migration Checklist (2)