Since the days of VMware ESX 3, many IT folks have been wary of thin virtual disks -- storage that grows as data is written to it. It’s a common belief that thin provisioning offers inferior performance compared to thick virtual disks, which come in a fixed size.
There is plenty of research that indicates
Requires Free Membership to View
almost no performance
hit (PDF) with thin virtual disks, however. And now that VMware has added thin
disk creation to vSphere’s user interface, the popular views about thin provisioning need an
overhaul.
This tip debunks misunderstandings about thin virtual disks and their use cases, and it covers how to overcome common thin provisioning mistakes.
Thin provisioning misunderstandings
Most of my customers have stuck with thick virtual disks for virtual machines (VMs) that generate a
significant volume of disk input/output operations per second (IOPS) -- despite research that
indicates the performance benefits of thick disks may be nominal. But they do use thin virtual
disks on server-based VMs that generate little or no disk IOPS (e.g., infrastructure VMs for domain
name servers and DHCP).
I understand their caution, but I feel they are missing out. Thin provisioning offers wonderful disk savings and saves admins from having to answer questions such as, “What is the right size for a virtual disk?”
Before thin virtual disks became easy to create, you could waste disk space if a thick virtual disk was too large. But if a thick disk was too small, you could run out of free space within the VM. It was a problem I faced regularly in my lab environment, where free disk space was at a premium.
Overcoming thin-provisioning problems
That’s not to say that thin provisioning doesn’t have potential problems. If you aren’t aware of
the pitfalls, thin disks can cause catastrophic problems. Can you tell I’m speaking from bitter
personal experience?
It’s entirely possible to create virtual disks that consume the entire logical unit number/volume, for example. Let’s say I created 10 VMs, each with a 40-GB thin virtual disk. At first, the thin disks consume only a couple of megabytes, but if they fill to capacity, the disks would collectively consume 400 GB. As a result, horrible things would happen if the logical unit number/volume was sized to 350 GB.
This scenario isn’t farfetched. There are a couple of seemingly innocent VM tasks that can rapidly balloon a thin disk. First, watch out for how you format virtual disks within Windows. In Windows, I was taught to never use the Quick Format option, because Quick Format can actually slow down disk access in most environments.
But if you use the full-format option with thin-provisioned disks, it writes to every block in the virtual disk -- ballooning the thin virtual disk up to its maximum size. Now imagine simultaneously full-formatting several VMs on the same volume. You could find yourself looking like Wile E. Coyote, as he runs off the edge of a cliff.
The message is: For thin virtual disks, always use the Quick Format option in Windows. If you don’t, you negate the whole point of using thin virtual disks.
Figure 1
(Click image for an enlarged view.)
My thin disk won’t shrink
Another way to accidently inflate a thin disk involves VMware Tools’ shrink feature, which recoups disk space consumed by deleted files. Before making a VM into a template, I used to recommend that users defragment the disk and run the shrink feature to optimize the disk.
When you delete a file in Windows, it isn’t actually deleted from the disk. It merely gets marked to be overwritten in the file system. As such, these deleted files waste disk space.
Figure 2
The shrink feature is not available for all virtual disk types or operating systems. It may be
disabled, depending on the your version of VMware Tools. (Click image for an enlarged
view.)
Because of this process, defragmentation and the shrink feature don’t really work with thin virtual disks. Both processes move files around and write to the disk, which can increase the thin virtual disk’s size. And you might find that the shrink option isn’t available in the affected virtual machine.
If you had a task that created and deleted large files on a regular basis, pretty soon the thin virtual disk would grow, and that free space wouldn’t return to the storage array. So how can you reclaim this orphaned disk space? You can use SDelete with –c option to securely remove the deleted files inside the virtual disk.
This action causes the virtual disk to temporarily grow. But then you can use VMware’s Storage vMotion and its thin disk option to compress the virtual disk back to its actual size. It’s a clunky process, but it works.
I hope VMware adds a shrink option to the data store-browser utility, which has only an inflate option. (The inflate option converts a thin virtual disk into a thick disk.)
Ultimately, this problem will be fixed when VMware works with storage partners to add new features to the vStorage application programming interfaces, so the storage array knows that deleted files in the virtual disk can be freed up to show the disk’s true size.
Given this situation, however, you might decide to stick with thick virtual disks for VMs that regularly create and delete large files.
This was first published in February 2011
Join the conversationComment
Share
Comments
Results
Contribute to the conversation