Archive for 2009

Everywhere I turn, everybody’s talking about cloud computing.  And I agree with Mike DiPetrillo, very few people understand what the cloud is today and what it could and/or should be tomorrow.  I’ve kept silent on the topic of cloud computing on this blog until now, mainly because I prefer to know what I’m talking about before I put something out there for the world to see   But now that I believe I’ve got a good grasp on it, I’d like to share a few of my thoughts …

What’s in a name?

First of all, I don’t like the name "cloud."  I think it’s a stupid name.  Let me explain why.  I was with a customer the other day talking about the future of cloud computing and he said, "man, what a horrible name, it just sounds like the most insecure, undefined, unmanageable place … why would I ever want to put my apps in a cloud?"  I couldn’t agree more.  For years we’ve been preaching about putting applications in data centers, and the importance of securing data with things like firewalls and intrusion detection.  You don’t even have to know what a firewall is, what it does or how it works, but the name just sounds safe.  And in my opinion, referring to the next generation of computing as the "cloud" would be like if someone called the first firewall "come on in" and the industry adopted it. 

To me (and many of the customer I’ve spoken to), the word cloud conjures up images of dancing ferries, unicorns and other mythical creatures all prancing around in some fluffy place somewhere northeast of never-never-land.  But alas, cloud is the name the industry seems to have settled on.  And since, at this point, I don’t have a better name to offer, I too will refer to it as the cloud.  But for the record, I think the name should be something strong and manly, like Spike, or Butch, or Krull the Warrior King! 

By the way, I like the name vShield Zones, a new VMware offering that will logically partition a cloud.  I think a name like this conveys a much better image about where an organization’s apps and data “live.” 

What is the cloud?  An explanation for the business owner (IT people, you may want to stop reading now)

Most people still think about IT as servers and networks and storage, all powered by a bunch of computer geeks that hibernate in a data center or crawl around under desks when a computer breaks.  Actually, they probably still think about IT this way because this is by and large the reality for almost all organizations. 

But let me ask you this … why are thinking about IT at all?  Unless you’re in the IT / Hosting business, shouldn’t you be thinking about, um, your business?  You don’t think about electricity or the plumbing do you?  No, you don’t.  Unless of course, the electricity goes out or the toilets backup … then you can’t stop thinking about them!   But I’m pretty sure an advertising company, for example, doesn’t have an electrician or a plumber on staff. 

When cloud computing is fully realized, IT should be very much the same thing.  It is a tool that should serve you and your business, not the other way around.  Now, it’s not like servers and networks and storage and IT geeks like myself will cease to exist.  No, we’ll still be here, but you won’t think or care about us anymore.  *sniffle*

To understand the cloud, you need to STOP thinking about the plumbing behind the applications (i.e. servers / networks / storage), and you need to START thinking about what matters most, the applications and data you need to run your business. 

When the cloud is fully realized, your applications will be always on, extremely reliable, accessible anytime and from anywhere, and they will “live” in a cloud.  Now that cloud might be external to your organization, or it might be an internal cloud, built on your existing infrastructure.  Either way, you’ll be able to self-provision new applications with a few clicks of a mouse and pay only for what you use. 

Sounds pretty good, yes?  Don’t go beating up your IT department just yet.  While many pieces of cloud computing are in place, the cloud is still forming.  Standards are being hammered out, committees are being formed, and it seems like everyone has a SOAP box, apparently even me   (yes, I meant to capitalize SOAP, it’s a little joke for the developers)

I have more thoughts. More to come.

Me too.  Actually, I’ve been studying for a few weeks now.  A while back, a friend of mine and fellow VMware SE (and SRM super freak), Michael White, turned me on to Evernote, an awesome tool for capturing my web research and lab notes (among other other things).  So, as I’ve been studying for the exam, I’ve been saving everything in Evernote, which I have installed on my iPhone and my XP desktop.  (Now, if only they made a version for Linux, I’d be all set.  *sigh*  Yet another company with a great app that chooses to ignore the Linux community).

Anyway, now I just need to go back and do some simple formatting and VOILA!, I’ve got quite a few ready-made blog posts.  Which is handy, given my recent commitment to a post a day. 

So if you too are studying for the exam (or planning to) and looking for study material, feel free to check back here from time to time over the next few weeks.  In addition, you might want to check out the following list, which contains everything I’m using to prepare.

• Hands down, the best “cheat sheet” for VI3 is the vmreference vi3 card, by Forbes Guthrie
• Duncan Epping over at Yellow Bricks has put together a great list of documents in his blog post VCDX Design Exam, how to prepare?
• Looks like Jon Owings is also studying for the exam and has a number of good posts on his blog, 2 VCP’s and a Truck
• The best, and most comprehensive study guide I’ve found is the VMware Enterprise Administration Exam study guide 3.5 by Peter van den Bosch.
• Oh, and don’t forget the official VMware Enterprise Administration Exam Blueprint v3.5

Also, send me an email if you’d like to be part of a weekly online VCDX study group I’m trying to put together.

Wow!  I can’t believe it’s been almost two months since my last post!  Sorry for my extended absence.  I’ve been super busy with VMware events, customer presentations and meetings … oh yeah, and there was a nice ski trip to Vail too.  Time flies when you’re having fun

Over the past few weeks, with the little spare time I had, I actually completed my conversion to a virtual desktop.  So now, my corporate VMware desktop is 100% in a VM, always on and "lives" on the virtual infrastructure in my home lab.  And with my shiny new AT&T 3G wireless laptop card, I can access it anytime, anywhere (though admittedly, this is a last resort).

You might have guessed by the title, for this post I’ll focus on my network setup.  I stress the word “my” because when I first started to write this section almost a month ago, I had a lot of trouble trying to address all possible network configurations (or at least, a good majority of them).  Finally I gave up, realizing this was an impossible task.  There are just way too many options.  So, I’m simply going to document my network.  If you have VDI network configuration questions that aren’t answered in this section, email me directly (aaron at sweemer dot com) and I’ll be happy to help out.

I think the best place to start would be showing you a high level diagram of my network (click the graphic to see the full image). 

As you’re reviewing the diagram, here are a couple things to keep in mind:

• All IP addresses have been changed and domain names have been removed for security purposes.  Hostnames, however, remain unchanged.
• You do not need to have a similar setup.  In fact, you can have as little as a single physical server with local storage.  You might not be able to get the full benefits that a fully loaded virtual infrastructure can provide (e.g. VMotion, DRS, HA).  But if you’re just looking to test out virtual desktops with VMware View, you can certainly go with a slimmed down environment.  
• The configuration of the physical servers (cincylab-esx1, 2 and 3) as well as the iSCSI SAN (cincylab-ts1) will be addressed in the next section.
• The ISP router is a fairly unintelligent device which I’ve configured to simply forward all network traffic to cincylab-rtr1.  As such, I won’t address the configuration here.

I love Visio diagrams, they make everything look so pretty and shiny!  What does this actually look like?  Here’s a photo of my lab …

Notice the PC on the right (cincylab-rtr1)?  That’s an old Gateway I had lying around, which has a single 2.2GHz processor, 1Gig of RAM and a single 100Mbps NIC.  I installed Ubuntu server 8.04.1 (kernel 2.6.24-19-server) on it and made it the gateway between my lab and the DMZ (aka, my home network).  It’s on this PC that I route between VLANs, terminate external VPN connections and run my DHCP server.  Additionally, it’s where I run scripts that continually scan for changes to my public IP address and when necessary, automatically updates my dynamic DNS provider.

Since this post is getting long, I decided to break this section into two parts.  In part two, I’ll walk through the all the configurations of cincylab-rtr1 and cincylab-sw1.  And before you say anything … no, it won’t be another two months before I post part two

So…that crazy, proprietary company, VMware, today released the first open-source VDI client! (Just a small jab) It’s actually a very exciting event in terms of the possibilities it opens up. Already out of the gates, VMware has announced in the press release a bunch of different partners that are leveraging this View Open client in their own solutions (ChipPC, Novell, HP, Sun…). http://vmware.com/company/news/releases/view_open_client.html

The new View Open Client includes all the major components needed for someone to take the software, adapt it to their needs and package up a rich, customized solution. This should really assist all the players in the eco-system to reduce their time to market on solutions. I’m hoping this results in some new and innovative ways to deliver virtual desktops!

Another great use case that I hope we soon see more of are commercially supported (by the vendor and VMware), turn-key solution for turning your fat PC into a dumb, highly managed “thin client’. There are some solutions out there today, but I would think that this new View Open Client would allow someone to put together a package to do this easily with out-of-the-box View integration. The great part is, that a solution someone in the eco-system puts together using the View Open Client can be submitted to VMware for formal certification and support!

If you have some good ideas on how to apply this, have at it: http://code.google.com/p/vmware-view-open-client/

I finally got the VMware Infrastructure Client running directly on my Ubuntu Linux.  I use the word running, because I’m not prepared to use the word working just yet.  Though the application seems fairly stable and most feature / functionality I’ve tested thus has worked, I’ve already found two bugs, one of which will hang your entire terminal.  And believe me, I’ve only just begun to test, so who knows how many more bugs I’ll find?

But until today, I couldn’t even get the client to launch and I haven’t been able to find anyone else that has been able to do so either.  So I’m going to consider this a minor success and a step in the right direction.  But just to be clear, I would NOT advise you start managing your environment with the VIC on wine just yet!

OK, here’s the proceedure I used get this running.

1. My environment (I haven’t yet tried this proceedure on any other combination of Linux and Wine):
   • ubuntu 8.10 (kernel 2.6.27-11)
   • wine-1.1.14
2. Download and install the latest version of winetricks.
3. Run winetricks and select ONLY the following options:  dotnet20, ie6 and winxp.  Now, for future reference, I believe the bugs I’ve already found can be cured with a few more options.  But, one step at a time.  I also know that a couple options will crash the application.
4. Download and install the VMware Infrastructure Client.  You can get this by going to http://<ip of your vCenter server>.
5. Here’s the critical part, you need to modify your vCenter (or ESX) server to accept both HTTP and HTTPS.  By defult, vCenter and ESX will accept HTTP requests, but they are immediately redirected to HTTPS.  And currently, this will break the VIC on wine.  Do NOT do this on a production vCenter server!! To modify your vCenter server, do the following:
   • On your vCenter server, go to C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter
   • Copy proxy.xml to proxy.xml.bak
   • Open proxy.xml with a text editor
   • Find the lines with httpsWithRedirect and replace with httpAndHttps
   • Restart the “VMware VirtualCenter Server” Service
6. Back on your linux workstation, go to ~/.wine/drive_c/Program Files/VMware/Infrastructure/Virtual Infrastructure Client/Launcher/
7. Execute wine VpxClient.exe and you should see the following:

   

8. Make sure you put an http:// in front of the IP or DNS name of your vCenter server.  Otherwise, it will try to connect via HTTPS and again, this is currently problematic.
9. That should do it.

OK, here are the bugs that I’ve found so far (other than SSL, which I’ve already mentioned):

• Using the right click menu will freeze your screen about 50% of the time.  When it freezes, you’ll have to connect to another TTY, find the process and kill it.  But the alternative menus seem to work.  For example, if you right click on a host and click “New Virtual Machine … ” your screen will likely freeze.  However, if instead you click the “New Virtual Machine” link on the Summary tab, the New Virtual Machine Wizard will properly launch.
• The New Virtual Machine Wizard will not advance past the Virtual Disk Capacity step.  It produces the error “The disk capacity entered was not a properly formatted number or was out of range …”  It gives this same error no matter what value I enter.  Actually, simply clicking Cancel will produce the error.  Weird.
• The Getting Started tab correctly renders the proper HTML, but the viewing area is about 100 x 100 pixels and not adjustable.  (This is nothing more than an annoyance).
• You can create a folder in a datastore, but you can’t delete one.  Deleting files on a datastore seems to work fine.

Most of the navigation (other than the right click menu I mentioned above), seems to work well.  VMotion worked fine.  Configuring HA and DRS worked fine.  Performance stats rendered fine.  But I’ve got a lot more to test and I’ll update again with my test results as I progress.

Thanks to Dan Kegel (www.kegel.com) and Jeff Warnica (don’t know his website/blog) for your help and pointing me in the right direction!

Here are a few more screenshots of the client in action.  Click on each image for the full scale picture.

Performance stats, and completed VMotion (in Recent Tasks at bottom)

Datastore browser

This is the first post in my e.t.d.f (eating the dog food) series.  I had hoped to get this first one typed up quickly.  But instead, my week was consumed with customer meetings and the logistics around rescheduling a big event I am putting on for the Commonwealth of Kentucky.  (Thanks to a ton of snow and ice, we had to postpone it a few weeks.)  So now that I’ve got a little free time again, let’s get started.

In case you’re just joining us, as a quick recap, this series will document my conversion to a virtual desktop.  Meaning, when this series is over, I will no longer be tied to any physical laptop, PC, mobile phone or whatever.  My dedicated VMware corporate desktop will live full-time on the virtual infrastructure in my house.  I will then connect to my desktop remotely (whether I’m a few rooms away, or a few hundred miles away) via a VMware client or a web interface.  Sounds easy, right?  Well it really is, though we will have some challenges around multimedia, working offline, and accessing some local devices … all of which will be addressed as we progress.

But for now, first things first.  I want to establish some requirements and goals.

1. The desktop needs to be always on.  When connecting to my desktop, I don’t want to wait for it to power on.  I want to simply launch the client and connect.
2. I want to be able to securely connect to it anytime, anywhere.  This might sound obvious, but my home Internet connection has a dynamic IP address.  How do I connect remotely when my IP address changes?  And what about security?  Will other people be able to access my desktop from the web too?
3. My desktop has to be at least as performant as my current local desktop.  The only exception I’ll make here is for high end mulitmedia.
4. I want my desktop completely maintenance and worry free.  To me, that means:
   • My data is always backed up.
   • My desktop can be destroyed by a hacker or virus (or my own stupidity) and restored to its previous state with little effort and under 30 min.
   • Updating and patching my desktop has to be done automatically, or at least, a fairly painless process.
5. I want to be able to carry my desktop on a USB stick or LiveCD.  (If you don’t know what this means, I’ll be covering this in more detail when we discuss options for connecting to the desktop)
6. Finally, I want this to be scalable.  Keeping in mind that this series aimed to also serve as a loose guide to a Proof of Concept, I need to be able to add users and deploy desktops quickly and with minimal effort.

If at the end of this series I have met these goals, then I will consider my conversion a success and my desktop will permanently remain virtual.

So now let’s discuss what we’ll need to make this all a reality.

Server Requirements

VMware virtual desktops run on ESX, so ideally you would want at least one server that is currently on the HCL (Hardware Compatability List).  If you have a server but can’t find it in the “Systems” section of the HCL, then search for the components of your server in “I/O Devices.”  If your components are listed, there’s a good chance that ESX will run just fine.

If you don’t have a server and don’t have a big budget to buy a new one, then have a look at Mike D’s Building a $500 ESXi Host.  Or another great resource is VM-Help.com, which maintains the Unofficial ESX Whitebox HCL.  Keep in mind that anything not on the official HCL won’t be supported by VMware.

As for me, I have three servers in my lab, all of which are HP ML150′s with 8GB of RAM and 300GB of local storage.  Each server is connected to a Buffalo TeraStation iSCSI SAN with close to 1TB of storage.

Network Requirements

At a bare minimum, we’ll need a dedicated Internet connection.  Mine is a business grade, cable modem service provided by Cincinnati Bell with 5Mbps down, 1Mbps up, and a single dynamic external IP address.  We will also need an internal DHCP server with a range of IP addresses set aside for our desktops.  If you’re setting this up as a Proof of Concept for your company, you probably already have a solid Internet connection.  So make sure you’ve got DHCP enabled with enough available IPs for the number of desktops you plan to deploy.

VMware Software

If you haven’t already done so, go sign up for the free 60 day evaluation of VMware View and download the software bundle.  It will contain everything we’ll need from VMware for this project.

Desktop Operating System

My corporate desktop is Windows XP, so I’ll stick with that.  Make sure you’ve got the proper Microsoft licenses secured before deploying desktops.

That’s about it for our planning session.  Now for our homework assignment.  In the next day or two, please be sure to do the following:

1. Identify at least one server upon which VMware ESX can be installed.  Two servers would be better, if possible.
2. Make sure you’ve got an internal DHCP server set up.
3. If you have a separte network team, try to secure a dedicated external IP address.
4. Download the 60 day evaluation of VMware View.
5. Download the VMware View Manager Administration Guide.  It’s close to 200 pages long, so don’t worry about reading it now.  And really, following this series will cover most of what’s in the guide anyway.  But it’s nice to have handy as we move along.

On a final note, I’ll be making a separate page next to the “About the Author(s)” page at the top, for quicker access.  See ya next time

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 …

1. Planning the environment
2. Setting up the network and dedicated remote access
3. Getting the virtual infrastructure set up correctly
4. Setting up VMware View (the broker)
5. Preparing the desktops
6. ThinApp’ing my applications
7. 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 *
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.