Thin Disks
Get Thin Provisioning working for you in vSphere
Oct 12th
Going Thin and not looking back.
Yes, I am slowly losing my hair like many other aging men out there, but it wouldn’t be virtual insanity if I were blogging about my personal male pattern baldness issues. With the latest release of VMware vSphere comes a lot of new features and functionality that can be leveraged to make our lives easier. One of these features, that I personally have been looking forward to for a while, is Thin Provisioning. If you aren’t familiar with this technology, jump over to Gestalt IT for a great explanation of what it is and how it works.
One of the exciting promises of thin provisioning, is getting more “bang for your buck” out of the expensive enterprise storage you have been investing in for your ESX environment. But, as Bret Michael’s once said, “Every rose has its thorn” and there are some things to look out for and considerations to make, before implementing thin disk technologies.
Efficiencies are great if they work right and don’t over
complicate the environment.
Do your homework and make sure you understand the characteristics of the virtual machine that you are considering migrating into a thin disk configuration. The last thing you want to do is convert every VM to thin disk, and four months down the road all of your data stores are filling up and you’re scrambling for a storage CAPEX. Some people are of the opinion to do thin provisioning either on the host side (VMware) or on the storage array side, but not both. Take a gander at Chad Sakac’s blog that discusses thin on thin and some thoughts around each of these approaches. I’m not going to go into all of the pluses and minuses of thin provisioning but rather focus on how to make it work for you.
Coffee Talk
So now that we have some of the basics out of the way, I wanted to share my thoughts on thin provisioning. Like many organizations, we get requests from our customers that err on the side of caution. They want to plan for the worse case and ensure that their project and/or application isn’t setup for failure. I don’t blame them really, I do it myself all the time when I make coffee at home. I always end up making more coffee than I typically drink, just in case I might need that extra charge. The best way to do that is pad it, request more than what you might really need, just in case something comes up down the road. Virtual machine disk storage in some cases fits this same profile. If my coffee maker granted me access to hot coffee on demand, I would stop making extra coffee. Thin disks can give your end users that capacity on demand so you can gain control of the padding effect that typically takes place in most corporate organizations.
Take it back…
So now you have done your research, you’re starting to get a feel for what this thin stuff is and how it might play out in your shop. It’s go time. If you’re a smaller VMware customer, you probably already have an idea of what are good target disks to convert. If you’re a larger environment, it might be a little more difficult to gauge where the bloated pigs are hiding.
I worked at GE for a couple of years and was exposed to some of the Six Sigma methodologies they preach as well as practice. Sounds boring, right? Not really. You can really leverage DMAIC for a lot of IT related problems/issues/projects. You don’t have to take it to the extreme, use the framework to help guide you on your quest:
DMAIC
The DMAIC project methodology has five phases:
- Define high-level project goals and the current process.
- Measure key aspects of the current process and collect relevant data.
- Analyze the data to verify cause-and-effect relationships. Determine what the relationships are and attempt to ensure that all factors have been considered.
- Improve or optimize the process based upon data analysis using techniques like Design of experiments.
- Control to ensure that any deviations from target are corrected before they result in defects. Set up pilot runs to establish process capability, move on to production, set up control mechanisms and continuously monitor the process.
We have already defined our project goals and what we are trying to accomplish. We need a good “Measure” tool to really find where we might benefit from thin provisioning. Powershell is a great tool that most VMware administrators use, or have at least heard of. So this was the first place I turned to for assistance.
Alan Renouf of “Virtu-AL” http://www.virtu-al.net/ gave me a hand in writing the powershell script needed. (Thanks again, Alan!). Alan already had a one liner script to produce a list of vm’s, their disks assigned, and how much data each disk was consuming. I needed the ability to see this data outside a powershell window and be able to analyze it in a better format. We have a decent-sized VMware environment and exporting this out to a .csv for analysis is extremely helpful. Here is the script!
************************************************************************
# Set the Filename for the exported data
$Filename = “C:\VMDisks.csv”
Connect-VIServer MYVIServer
$AllVMs = Get-View -ViewType VirtualMachine
$SortedVMs = $AllVMs | Select *, @{N=”NumDisks”;E={@($_.Guest.Disk.Length)}} | Sort NumDisks -Descending
$VMDisks = @()
ForEach ($VM in $SortedVMs){
$Details = New-object PSObject
$Details | Add-Member -Name Name -Value $VM.name -Membertype NoteProperty
$DiskNum = 0
Foreach ($disk in $VM.Guest.Disk){
$Details | Add-Member -Name “Disk$($DiskNum)path” -MemberType NoteProperty -Value $Disk.DiskPath
$Details | Add-Member -Name “Disk$($DiskNum)Capacity(MB)” -MemberType NoteProperty -Value ([math]::Round($disk.Capacity/ 1MB))
$Details | Add-Member -Name “Disk$($DiskNum)FreeSpace(MB)” -MemberType NoteProperty -Value ([math]::Round($disk.FreeSpace / 1MB))
$DiskNum++
}
$VMDisks += $Details
Remove-Variable Details
}
$VMDisks | Export-Csv -NoTypeInformation $Filename
***********************************************************************
So now that you have this great spreadsheet, you can do all sorts of crazy sorting and reporting, within Excel. Take some time on phase 3, “Analyze” what you’re seeing. Talk to your VM stakeholders to see how things might be changing from their perspective. Try to plan for the surprises and position yourself accordingly.
Next is the “Improve” phase of DMAIC (see it’s easy!). This is the part where you actually do the work. It’s time to start leveraging the storage VMotion API’s, and reclaim some of that unused disk.
- Select the target VM in the VC client.
- Right click on the VM and select the option “Migrate”.
- Select the option “Change Datastore”.
- Select the destination, or click advanced if you are targeting one particular disk.
- Select “Thin provisioned format”.
- Select Finish.
Rinse and Repeat for the rest of that spreadsheet you have worked so hard on.
The last phase of DMAIC is “Control”. 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.
Eric Gray of VMware takes this to the next level, check out his blog post on utilizing powershell to prevent datastore emergencies. My personal approach to this concept is to setup a “hotspare” datastore for your environment. A good practice to implement here would be to try reclaiming enough storage from your migrations to thin disks to free-up a “hot spare datastore”. Implementing an automated recovery solution like Eric’s will help you sleep easier at night. Worried about what might happen if your script doesn’t work or you do hit the perfect storm and end up with a full VMFS volume? Intelligence has been built into vSphere to automatically pause the virtual machines, impressive. Check out Eric’s video:
Wrapping it all up
Thin disk provisioning is a great feature that you should consider leveraging in your environment. With some forward thinking and best practices you can achieve higher ROI for your ESX storage. VMware vSphere offers the ability for you to migrate from thick to think with no downtime, so you can begin reclaiming storage on the fly. Keep it simple, start out with a high level analysis of your infrastructure. Identify the candidates that are a good fit and worth focusing on. Setup your alerts on the datastores as soon as you migrate your first virtual machine so you are protecting yourself from problems down the road. Consider taking automated actions if your datastores are reaching critical thresholds.
I hope you found this article helpful, good luck!
Scott Sauer
How Much Storage Will You Save With View Composer?
Jan 5th
It depends
But to help you better guesstimate how much storage you’ll save with View Composer, let’s take a look at the actual storage savings in my home lab. Keep in mind that VMware View isn’t just something I’m playing around with. There are currenlty 5 other VMware Systems Engineers using my lab on a regular basis. And I use VMware View to give each lab user a dedicated, persistent desktop VM which they connect to remotely via the View Client. And from their dedicated lab desktop, they have full access to the lab environment I’ve built. So, while my home lab environment may be small and by no means a production enviornment, I’m still using VMware View as a “production” application, so to speak. It’s the one application in my lab that needs to be up, and it gets heavily used.
Let’s first look at how much storage my virtual desktop infrastructure would require without the use of View Composer. As I said, each lab user has a dedicated desktop, which has a 12G partition for OS and a 4G partition for user data. Also, each desktop has 1G of memory with zero memory reservation, which transltates into a 1G swap file. That’s a total of 17G per user. Right now there are 5 other remote users, plus I have a desktop for myself. And I have 2 desktops on standby for new users (so they don’t have to wait for a new VM to be built upon first login). So, that brings the total virtual desktops to 8. Therefore the total storage requirement for virtual desktops in my lab without View Composer would be 136G (17G * 8 desktops).
Now let’s look and see how much space is actually being used in my lab. Here’s a cut and paste showing the disk usage of the volume holding the desktop VMs …
[root@cincylab-esx1 cincylab-vol1]# du -sh *
3.1G labuser-01
2.9G labuser-02
3.6G labuser-03
2.6G labuser-04
3.1G labuser-05
1.9G labuser-06
1.5G labuser-07
1.5G labuser-08
2.0G replica-774c678b-e6b5-495a-b8ff-
448K source-lc-8ae5400e-4af3-4a09-8d8
13G parent_desktop
[root@cincylab-esx1 cincylab-vol1]#
The grand total here is 33.2G, which is about a 75% reduction in storage. Not bad. The storage reduction is achieved through two technologies, Linked Clones and Thin Disks.
Linked Clones
In my environment, the virtual disks for the desktops are located in the labuser-0* directories (this is done automatically for me during the deployment process). These virtual disks are not thick, monolithic disks like they used to be in the previous version. Rather, they are delta disks, which only store data differences between the desktop OS and the OS of the parent VM. In the cut and paste above, notice the 13G parent_desktop? That’s my starting point and contains my golden image. That direcotry also contains a snapshot, which I took when I was ready to being deploying desktops. The replica-774c678b-e6b5-495a-b8ff- VM is derived from this snapshot and ultimately serves as the parent VM (for now, this can change over time) of the labuser-0* desktops. Linked Clones have other benefits too, especially around patching and updateing. But that’s a topic for a later post.
Thin Disks
Remember how I said the users need a 17G? (12G for OS, 4G for user data and 1G for swap) But did you notice that the parent_desktop directory is only 13G in size (12G OS plus 1G swap)? From the administration guide “Thin provisioned disks (thin disks) are used by the linked clones to store user data, and are not linked to the Parent VM.” So I didn’t need to include the user partition in the parent VM. The user partition is handled for me when a desktop is deployed and included with each of the user desktops. User data disks are persistent and they are thin, meaning they occupy no more space than the data requires. In my environment, looking at the virtual disks for labuser-03:
[root@cincylab-esx1 labuser-03]# ls -lah
total 3.6G
drwxr-xr-x 1 root root 1.8K Dec 27 09:23 .
drwxr-xr-t 1 root root 3.7K Jan 5 06:10 ..
-rw——- 1 root root 1.0G Dec 27 09:23 labuser-03-a2263868.vswp
-rw——- 1 root root 8.5K Dec 27 09:23 labuser-03.nvram
-rw——- 1 root root 4.0G Jan 5 08:07 labuser-03-vdm-user-disk-D-flat.vmdk
-rw——- 1 root root 443 Dec 27 09:24 labuser-03-vdm-user-disk-D.vmdk
-rw——- 1 root root 75 Dec 27 09:21 labuser-03.vmsd
-rwxr-xr-x 1 root root 3.9K Dec 31 06:58 labuser-03.vmx
-rw——- 1 root root 265 Dec 31 06:58 labuser-03.vmxf
-rw——- 1 root root 2.5G Jan 5 08:07 replica-774c678b-e6b5-495a-b8ff–cl1-delta.vmdk
-rw——- 1 root root 379 Dec 27 09:24 replica-774c678b-e6b5-495a-b8ff–cl1.vmdk
-rw-r–r– 1 root root 62K Dec 27 09:21 vmware-1.log
-rw-r–r– 1 root root 36K Jan 5 06:21 vmware.log
[root@cincylab-esx1 labuser-03]#
Look at the size of labuser-03-vdm-user-disk-D-flat.vmdk, see how the file system “thinks” it’s 4.0G? It’s really not. A closer look at disk usage reaveals:
[root@cincylab-esx1 labuser-03]# du -sh *
1.0G labuser-03-a2263868.vswp
64K labuser-03.nvram
43M labuser-03-vdm-user-disk-D-flat.vmdk
64K labuser-03-vdm-user-disk-D.vmdk
64K labuser-03.vmsd
64K labuser-03.vmx
64K labuser-03.vmxf
2.6G replica-774c678b-e6b5-495a-b8ff–cl1-delta.vmdk
64K replica-774c678b-e6b5-495a-b8ff–cl1.vmdk
64K vmware-1.log
64K vmware.log
[root@cincylab-esx1 labuser-03]#
It’s actually only taking up 43M, not 4G. And a quick look inside the VM confirms it too “thinks” it has 4G:
So that’s my real world example of how much storage I’m saving with View Composer. How much will you save? Again, it depends
There are things that I haven’t discussed in this post (e.g. desktop refresh, desktop recomposition and desktop rebalance), which will also affect storage savings. Also, using ThinApp’d applications that live on a file share (as opposed to putting them in the OS) could have a big positive impact on storage savings. In my lab, with only linked clones and thin disks, I’m getting a 75% reduction. With a little more effort and planning on my part, I’m confident I could achieve 85% or better.
Project Minty Fresh (Desktop)
Dec 10th
The fresh flavor that lasts and lasts……that’s goal behind one of my customer’s latest desktop projects. This customer has been working the View3 pre-release code for some time now. Using View Composer, we now have the capability to very easily, and programmatically refresh a user’s desktop back to the original golden master image state. View Composer supports three primary operations after initial linked clone creation:
1: Refresh – A Refresh takes a desktop back to the original state of the master
2: Recompose – A Recompose takes a linked clone and re-homes it if you will, to a new parent image (think instant OS updates or software rollouts)
3: Rebalance – A rebalance takes all the linked clone VM’s in a pool and re-balances them across a set of LUN’s
For the sake of this conversation, we will focus on the Refresh operation.
Problem:
My customer’s goal is to maintain the integrity of their corporate desktop image deployed to users. Over time, their user’s have a particular habit of destroying their desktops. So much so, that they had to put in place a mandatory, ongoing re-imaging program so that all desktops never go more than six months without a re-image. This policy has had some very positive results in terms of reduced help desk calls and time spent just sustaining a rotting OS. That said, the effort required to sustain an perpetual, semi-manual re-imaging program is substantial.
Solution?:
Enter VMware View Refresh. Right now, they have rolled out a program for a set of 50 users to see how well it would work to refresh a user’s desktop much more aggressively (every 5 days to start). This means that after a linked clone is created and the user begins to use the VM, the VM will automatically refresh every 5 days back to it’s original state (configured in the desktop pool settings…screenshot to come). The goal is to make this a highly seamless event for the users. With View Composer’s User Identity Disk, C:\Documents and Settings\ is redirected to another, persistent (thin provisioned) .vmdk that is presented as the D: drive. This is configured when you create the pool as shown below:

Based upon our initial tests, this is working really well. We can refresh a user’s desktop without them ever knowing, as the next time they log on their profile is completely intact. Currently we are testing all of their applications to ensure this will work across the board. I am sure we will find some applications that do not, gasp!, save their preferences in the user’s profile (something TS/Citrix admins deal with constantly). For those applications, our plan is to ThinApp the application and set the User Sandbox to live in the proper, user’s profile directory. We have also found that we need to re-register each VM with the anti-virus console after a refresh operation which we are now achieving through a post-sync script.
I’ll be sure to keep everyone posted on our progress and experiences. It’s certainly something to consider and explore. Let me know what you think! Until then, I wish you a very minty fresh desktop experience!

