Archive for January, 2009
I got a comment on yesterday’s post from Rodney Haywood, a.k.a. Rodos, a fellow virtualization (or, as he would probably type it, virtualisation) blogger, that said …
Cool. Maybe you were inspired by my post http://rodos.haywood.org/2009/01/life-without-v…
Be great to hear about your progress and journey. It can be done. I miss my VDI!
Now, before I officially started the Eating the dog food series, I was going to type up a post on all the reasons why I want to run a virtual desktop in the first place (other than “practicing what I preach”). But after reading Rodos’ post last night, I realized I could save myself the time by just pointing everyone to his blog. He pretty much sums up everything I was going to say anyway So check out his post Life without VDI sucks if you want to know why I’m eager to run a virtual desktop.
Rodos, great work and thanks for the comment. And where did you get that sticker?! I want one!!
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!!
It’s no secret that I’m a big Linux fan. And us Linux weenies frequently like to point and snicker whenever we see the infamous BSOD or any other Microsoft flaw we stumble across. But in the spirit of fairness, I thought I’d share this picture I took on a recent flight …
Evidently, the entertainment systems on Delta airlines are powered by Linux (very cool). BUT, on this particular flight, my screen — and only my screen — was in a never ending reboot!! That made for a fun 4 hour flight and I can tell you was NOT happy with the Penguin at the and of that trip. Of course, I think it’s funny now, so I thought I’d share.
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 *
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.
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.
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
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
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 *
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.