View Composer
Eating the Dog Food (my Conversion to a Dedicated Virtual Desktop)
Jan 20th
I’m a big believer in “practice what you preach” and I try to do my best to live by this motto. Now, let me be the first to say that I also believe that by being human, almost by definition, makes me a hypocrite and I am certainly not saying that I’ve never failed at this. All I’m saying is that I try my best.
All day long, as a VMware Systems Engineer, I spend my time evangelizing the wonderful things that virtualization and VMware software can do for companies. I can do this because I’ve been working with VMware software almost since VMware began. And I’ve helped implement virtual infrastructures for many different clients, long before actually being employed at VMware. I even helped build VDI’s (Virtual Desktop Infrastructures) before VMware had a VDI product offering.
VDI is really starting to take off this year and most of my conversations these days are about giving corporate users a virtual desktop. And while I’ve helped build VDI solutions before, am I actually using a virtual desktop myself? No! Well technically I do, given that I run my corporate destkop in VMware Workstation on top of Ubuntu Linux. But this is not the same solution I’m preaching to my customers. A virtual desktop running locally is a very different beast than running a virtual desktop remotely on VI3 via a desktop broker. Normally, I would be able to rationalize this and say “I’m not a corporation that has the virtual infrastructure to run a virtual destktop.” But this is no longer true. I have a dedicated Internet connection and at least three good servers always running in my lab.
So, I’m about to start practicing what I preach and “eating my own dog food.” I’m going to begin a series of blog posts that document my conversion to a dedicated virtual desktop. I hope that this can also serve as inspiration, and possibly even a guide to a proof of concept, for those who are interested in virtual desktops. I’m sure this blog series evolve as I progress, but I envision the upcoming posts will look something like this …
- Planning the environment
- Setting up the network and dedicated remote access
- Getting the virtual infrastructure set up correctly
- Setting up VMware View (the broker)
- Preparing the desktops
- ThinApp’ing my applications
- Troubleshooting, tweaking and optimizing
Again, as I progress, this could all change. But for now, this is the blog series I’ll begin in the next day or two and hope to complete over the next few weeks. I hope you join me. If you plan to follow along and, better yet, get involved, please sign up for a Disqus account. It’s the system I use for commenting and discussions.
By the way, do you know who originally coined the term “eating our own dog food?” VMware’s CEO, Paul Maritz. But he didn’t coin the term while on duty at VMware. From Wikipedia …
In 1988, Microsoft manager Paul Maritz sent Brian Valentine, test manager for Microsoft LAN Manager, an email titled “Eating our own Dogfood” challenging him to increase internal usage of the product; from there, the usage of the term spread through Microsoft, as chronicled in the book Inside Out: Microsoft—In Our Own Words (ISBN 0446527394)
The irony is so thick, you can cut it with a knife!! 
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!