How VMware is misleading everyone about the cost savings of VDI

I just got out of my first breakout session here at VMworld Europe 2009. It was a session about the cost savings of VDI.

I just got out of my first breakout session here at VMworld Europe 2009. It was a session about the cost savings of VDI. The presenter was good and the content was basically good. In the session, the presenter walked step-by-step through a comparison of a traditional fat-client desktop computing model with a VMware View 3-based VDI model. She covered capex and opex expenses and looked at all the reasons customers could save money (both hard and soft costs) by going with VDI.

I agreed with MOST of the content of the session. However, I think VMware left out two very, very important things. In fact these omissions are so great that they would "break" VMware's VDI cost savings model. But instead of addressing them, VMware just ignored them. (They weren't even mentioned!) Most of the audience was new to VDI (as evidenced by the number of hands that went up when the presenter asked how many people had heard of VECD and who had used ThinApp.)

This is a big problem. After this presentation was over, 200 people walked out of that room thinking that VDI is great and provides great savings, but VMware mislead them all by not providing the complete picture.

Misleading Tactic #1 - VMware compares VDI to traditional computing, yet ignores TS

The whole session was basically a cost savings analysis of VDI over traditional fat-client computing. Fundamentally I don't have a problem with that. I even agree with all the savings numbers that were presented. The BIG PROBLEM I have is that for EVERY POINT made in the "pro" VDI category, the exact same point could have been made in a "pro" Terminal Server category. So while I agree 100% that yes, VDI could have saved the amount of money the presenter was suggesting, I think that a Terminal Server-based solution could have saved EVEN MORE money.

The biggest savings would be on the capital expenditure of the server hardware. The VMware VDI session listed $150-200 per user for server hardware. This was assuming a fairly standard Dell server with 6 to 8 users per core. Again, I agree 100%. HOWEVER, the exact same architecture based on Terminal Server could have what, 20 or 30 users per core? Even if we assume only 20 users per core, we'll still looking at a 3x difference in hardware costs per user.

In fact one of the case studies used a customer was going with Vista, so the presenter said that customer got even less than 6 users per core since they needed the performance. And that's a good point. If you have very intense apps, you can also dial-down the number of users on a Terminal Server too. (I'll take a Terminal Server with 6 users per core over a VDI solution with 6 users per core any day...)

The bottom line: VDI was a lower cost option than the traditional computing. But the presenter never mentioned the lowest cost option which was TS. And sure, there are certain cases where VDI is needed and where TS won't work, but the case studies presented in the session were not those kind of cases. TS would have worked fine for them and would have been much cheaper than VDI.

I raised my hand at the end and asked the presenter about TS. She just said that Gartner or Forrester or someone was working on a cost analysis that also included TS. She didn't address the fact that TS could have been used in these cases studies, or why VMware sold the customer on VDI instead of TS.

Misleading Tactic #2 - VMware assumes all apps will work with ThinApp

Another component of the VMware VDI solution is ThinApp. (It's now bundled into the Platinum edition of View 3.) The whole cost analysis from this session is based on replacing your old fat desktops with VDI-based server-based computing.

One of the new features of VMware View 3 is View Composer, a component that uses VMware's linked clone feature to enable many users to share a single master disk image (with each user getting their own delta differential clone file). VMware positions that as a great cost savings, since you don't need 10GB (or whatever) on your SAN for every single user like you did with VDM2. The problem is that in order for this to work, you have to dynamically stream your applications on-demand into your disk image. VMware suggests you can do that with ThinApp. I agree with this 100%.

But here's the problem with ThinApp (and all other application virualization products too, like App-V, InstallFree, etc.). THINAPP CANNOT VIRTUALIZE 100% OF YOUR APPS. Sure, it can do most of them. But it can't do 100%. So what happens when you decide to implement a VMware VDI solution and you build your whole cost analysis model around getting rid of supporting your desktop and app issues and everything, but then you learn that you can't put all of your apps into ThinApp? Now you've got two choices:

    1. Install the apps in the traditional way (manually or via SMS) into the VMs. This would work, but now you break your linked-clone disk savings (since the apps would either (a) be installed for all users in the master image, (b) be installed for each user into the diff clones, or (c) you'd need to have multiple master images. Either way you destroy your cost savings model.
    2. Install the apps onto the local fat desktops. But now you have a MAJOR user experience problem since VMware View only runs in remote desktop mode (i.e. no published apps), so now your users have to switch back and forth between two desktops, and you'd have profile sync issues and all sorts of problems, ON TOP OF THE FACT that you're still supporting local desktops, again completely destroying your cost savings model.

      In other words, the big cost savings model that VMware is pushing for their View 3 VDI solution is ONLY TRUE IF EVERY SINGLE APP YOU HAVE IS THINSTALL COMPATIBLE. Is that the case for you? Maybe. (And if so, woo-hoo!) But if not, you have some serious thinking to do. (And again, this is why I recommend that you only use VDI where you tactically need it. There are too many issues to broadly use it across the board.)

      Before you call me a "VDI hater"...

      "You know I spank you because I love you!" The truth is I love VDI. I WANT VDI to be successful. But if someone tries to go down the path of VDI with just the information they're getting from VMware, they're most likely to end up uncovering a lot of hidden costs or gotchas down the road, potentially leading to them ripping out their solution or just feeling really stupid. Or, they're in a position where they build out a VDI environment that's way more expensive than a comparable Terminal Server solution that could deliver the exact same experience and do the exact same thing.

      I want to be clear on something here. Several people came up to me after the VMware session and asked, "Do you think that cost savings analysis is too much of a topic for a one hour session?" My answer is "no." I am NOT upset because VMware over-simplified it. The over-simplification was done well and the perfect amount for the one-hour session. I am upset because the presentation left out two key elements that could drastically change the cost model. (And I don't think you can leave out these two things under the guise of "over-simplification.")

      This is one spot where Citrix, Microsoft, and Quest have a huge advantage over VMware. Since the other three vendors all offer VDI-based and TS-based solutions, you can at least feel confident that you're getting the lowest-cost architecture solution from them. I don't think that's the case with VMware. (And before you say "but View 3 supports Terminal Server too," let me tell you that the TS support is View 3 is NOT fully baked. There's a lot of stuff you don't get with TS, like the ThinPrint capabilities and the TCX RDP extensions. And in fact the term "Terminal Server" is never mentioned in VMware's cost models.)

      So be careful. Warn your friends.

      Join the conversation


      Send me notifications when other members comment.

      Please create a username to comment.


      I agree 100%, when comparing TS to VDI, TS will always win if the sale is all based around cost; I guess this is exactly why they don’t mention it. I have been to several of these View sessions and although like yourself I agree with much of the content, they do leave out the TS bit, but then again they are there to sell a product, not to be non-biased.

      I continually hear a similar mantra where I am at. "We are going VDI, who cares about Citrix/TS." Sadly that could not farther from the truth.

      VDI has a lot going for it, in some cases price is not one of them, especially if you are deploying individual desktops on a 1 to 1 basis. Even with cheaper NAS solutions, storage is still a major cost and often over looked until the bill comes.




      I just want to point out that Parallels VDI can support a much higher consolidation ratio than View 3 or XenDesktop 3.  In my testing with Parallels PVC 4.5 (beta) integrated with vWorkspace 6, it scales to 20 users per core with 16GB RAM for 'basic' workers and 12-15 per core for 'power' users.  Additionally, I don't need to purchase VECD licenses but MS Server 2003/8 Data Center edition with TS CAL's which also reduces the cost significantly (especially if your company is non-profit!).

      The on-disk space for each VDI container is tiny...maybe 300MB at the upper end and more like 60MB at the lower end.  Lastly, I can use application templates or install applications inside the containers without the compatibility problems of Terminal Services.

      Rodd Ahrenstorff


      Brian, Brian Brian......

      Let's say you can't thinapp 100% but you can 95%, so install the 5% on your gold image and your ROI isn't going to change that much now is it.

      As for your TS vs VMware users per core, I would like to see how TS scales on the kind of box that vmware installs to.  Let's see how many users you can stick on a 24 core server with 128GB of RAM.  You state that you can get 20 to 30 users per core so we should be able to have  600 users on a single server.  I would love to see that, i doubt windows could handle it.

      Let's not also forget that Citrix or TS don't also work well in certain work types such as VDI images for Developers where they need to run Visual Studio and other high end development platforms.

      BTW, your not a hater your a doubter.

      Love your take on things, keep up the good work.


      Matt Lipinski...


      Container based VDI makes sense to some extent.  Yes, you will get higher user density but you lose out on the rich GUI experience.  Try updating to Windows 7 when it comes out.  At this point, it makes sense to look at published Desktops from a TS instead.  The specific uses cases where Container based VDI makes sense is relatively small.


      @Matt Lipinski,

      As for installing the 5% on your gold image.. this might be possible, it just really depends on how big your 5% is. If you have 500 apps.. now you're talking about 25 apps on the gold image and you have to worry about conflicts and regression testing and all sorts of stuff that VDI was supposed to fix. Now I'm not saying you don't have regression testing and stuff without VDI, but, if your cost savings model is based on that kind of stuff going away.. you can only achieve that if you go 100% ThinApp.

      For Terminal Server on 24 cores with 128GB RAM, yes, absolutely you can get 600 users on there! With x64 it would be no prob. And if you have app reasons that prevent you from going x64, then just slice that thing up with a hypervisor into a few smaller TS VMs. I'd be willing to bet that you could get more users than VDI that way too.

      But your last point is a good one.. that yes, of course you get more users with TS, *if* your apps are TS compatible, So sure, with Visual Studio and intense apps, yeah, go with VDI. (Which, BTW, I'm freaking sick of that Visual Studio VDI example. It's like all of the sudden all our users are using Visual Studio?) But my point was sure, use VDI when it makes sense.. I'm not saying that ONLY TS makes sense. But in every example case study VMware had, it seems (from the slides anyway) that TS would have been fine. I didn't hear anything about Visual Studio or crazy apps in the presentation.


      If there was only one instance of Windows on that 24 core/128 GB server, TS with XenApp may or may not scale up to 600 users.

      But why just put one instance of Windows on it? Why not put XenServer on it, and break it up into 12 dual core Windows servers? With that archicture each virtual TS/XenApp server only needs to support 50 users. That's not that hard to do, even when TS is virtualized.

      And even still, even if those 12 VM instances of TS and XenApp only supported 20-30 users each, that would still be quite more than what that same server could support deployed as VDI.


      Brian,  thanks for making me feel like I'm not the only one that doesn't see the VDI advantage over TS for most of the world.  Visual Studio is used by home many people in the business world?!  Everyone seems to forget the end user when comparing the apples to the oranges.  

      btw Lippy, i used to get 30 heavy app users per box, now with a xenapp image streamed via pvs to a xenserver I get 4 times the load on the same Dell 1950 (well I spent $600 for 16GB of RAM). Take your average office and that's easily 200 users on a little 1950....


      @ Joe Shonk,

      Thanks for your reply.  Maybe it's because I work for a small business (200 users) that I don't see how containers for VDI are only good for niche markets.  If web hosting companies use many thousands of Windows/Linux containers, why can't this be extended to VDI?

      And on the Windows 7 front; yea, it won't be supported immediately after release, but how many companies 'need' to immediately deploy Windows 7.  How many enterprises deployed Vista...10%?  I guess I always thought it was the applications that matter, not the underlying OS.  Someone else made a similar argument about using Windows Server as the hosting OS for the containers...and how 'few' application vendors supported it.  Well, we do the exact same thing with TS/Citrix.  You can skin Windows Server 2003/8 to look and behave just like XP/Vista.  My Parallels VDI test users would never know they aren't using a desktop OS.  How does "...look at published Desktops from a TS instead" support your Windows 7 argument?  

      Application compatibility and environment customization are the problems I face with TS/Citrix.  A container solves these problems and offers _nearly_ the same consolidation ratios at TS.  Additionally, you can create any number of 'gold' images customized for your particular environment/users.  Yes, they need to be the same OS type, but they all share the same kernel and this reduces disk and memory usage across all the deployed containers.  

      Lastly, nothing prevents the deployment of Windows Server 2003 on a cluster of physical hosts and Windows Server 2008 or RHEL 5.x on another cluster of physical hosts.  Now you have XP, Vista, and RHEL desktops published as containers in an HA environment with minimal disk usage and templated applications.  And you only pay for the number of concurrent VDI connections, not the number deployed or the number of servers running.  Makes sense to me...

      Rodd Ahrenstorff


      Thanks for pointing this out Brian and we are seeing some customers in field who where early adaptors with VDI reaching out for advise now they have worked out VDI currently does not fulfil all their requirements and  now want to consider all available options.

      Currently bang for buck we will always recommend a SBC solution where possible.

      More recently we have been advising customers that a Hybrid solution is the best fit but some vendors are advising VDI can fulfil all the customer’s requirements which currently no VDI solution can.


      VDI or what ever you want to call it is driven by the need for session isolation, i.e. developers wanting to reboot, users wanting a desktop OS, etc. It does not give you TCO over TS and it's a different use case, so I agree with Brian. ThinNOTInstall is a joke, so many apps it can't virtualize, slow to load, crappy packager, and not easily portable across OS types. Try getting IE to run with this pig and move across OS versions. Then let's get started on the protocol, and all the stuff they don't offer for real world. It's all marketing from VMWare, nobody really uses it for serious use cases. I know of an implementation that was so ppor over the WAN and such an inflexible broker that this customer bought leo stream to enable them to broker connections to XA just to protect their ESX investment!!!! Crazy.... So totally agree don't buy the VMWare BS, or that they believe checking a machine out is a good idea to solve the offline use case HA HA! VDI has it's use cases for session isolation at a cost, but offers improved mgmt over traditional desktops whn done right with the negative to crappy multimedia performance. TS is cheap with crappy multimedia performance. WAN, i.e. protocol matters don't let VMWARE fool you especially if you ever want to move anything to the Cloud. Offline is a big area for opportunity. Also think who owms the OS, MS. Love them of hate them, Softgrid will keep chipping away and I would think twice before picking VMWare thinNOTInstall over MICROSOFT!


      Most companies are going to just sell their products, and who can blame them. Our job (and that of the attendees) is to look a little deeper and make the best choice for ourselves.

      In most cases that means a hybrid solution. So in this case how about VDI for 95% of apps and then delivery through TS for the remaining 5%?

      Right now there's a lot of cross compatibility between broker, hypervisor, storage and application virtualisation. My worry is how long this will continue, and when the "killer" features will lock you in to a single vendor.



      Right on the mark!  TS is a great, mature technology that’s really efficient.  VDI can solve some specific problems and do it in ways that are familiar to users (even those that don’t use Visual Studio…).  

      Both have their place and no one is well served by hiding the real costs involved.  The reality is that it’s a hybrid world out there already.


      Citrix are jumping on the same bandwagon to be fair - I viewed a webinar last week on "What does desktop virtualisation in the real world deliver"

      What bemused me there was the whole raft of reasons *for* VDI was the same as the reasons for Winframe/Metaframe/XenApp/InsertNewMonikerHere - with one slide seeming to state that VMs or BladePC (?!) were the solution for the majority of users.

      Personally - I see VDI offer a good 80% fit for that 20% of users where SBC doesn't cut it and I've yet to see a good argument that proves otherwise.

      But then VMWare can *only* offer a VDI solution - so they're hardly going to tout a solution that doesn't generate them revenue. It'd be interesting to see what they're suggestion would be if they'd not dropped the full propero offering or bought someone like propalms


      Andy, not sure what webinar you saw, but Citrix (at least my team) have been trying to go out of our way to put the same type of realism on the subject that Brian talked about in his session. I can only guess that the topic was intended to just cover the "full" desktop experience options?? and left the subject of XenApp/TS for another session. Anyway, we certainly have nothing to gain by not promoting the overall lower cost structure of TS/XenApp! In fact I did a webinar session right around the launch of XenDesktop emphasizing this point that actually got a nice review here ;-)

      Anyway, I attended the customer-facing version of the TCO session at VMworld a day after Brian - and found some other quirks in the logic... i explain them here:


      I'm not sure if TS will be the cheaper option because terminal server environments tend to have more hidden costs.

      For example application distribution and application management. Since most TS environments aren't 100% terminal server an administrator will have two application packaging paths: one for normal workstations and one for TS. VDI only has one on the exact same use case.

      Also managing a TS environment requires more labor and expertise (training and more expensive labor) then a VDI environment (single image management with more common labor costs)

      Troubleshooting app silo's and frontend desktop servers also requires more and more expensive labor.

      Sure you can solve most with additional software but that will rev up the per CCU price and the overall cost picture.

      In addition to the above, the 1:1 relation between hardware and server role is no longer there, thus allowing you to be more flexible with the resources that are available. I'm not sure how you would put a price on that but it's got to be worth something....


      I'm not sure if TS is 'cheaper' than VDI. I'm pretty confident that VDI would loose on CAPEX but will make up for it in OPEX. Functionallity wise VDI will get a small + because of the added flexibility over TS.

      TS requires more labor to manage on the OS + App layer, in addition the labor is more expensive because of the technical level required. Against single image management.

      TS requires two application management processes; One for normal desktops and another one for TS apps.

      TS in most use cases requires silo's for app isolation or segmentation and thus more hardware that is potentially under uttilised.

      Building a TS solution from greenfield will cost more in development, building, testing and rollout than a VDI build from greenfield.

      my 1 cts



      You say: "I'm not sure if TS will be the cheaper option because terminal server environments tend to have more hidden costs.

      For example application distribution and application management. Since most TS environments aren't 100% terminal server an administrator will have two application packaging paths: one for normal workstations and one for TS. VDI only has one on the exact same use case."

      But then you say... "Also managing a TS environment requires more labor and expertise (training and more expensive labor) then a VDI environment (single image management with more common labor costs)"

      Too me, your second point completely cancels out your first point, and that's exactly what I was trying to address in this article. I agree about not all apps being compatible with TS, but I think the same is true with VDI.. not all apps are compatible. So I think the problem exists for both TS and VDI.

      And then you talk about "only" managing a single image for VDI. But what about those apps that are not compatible with ThinApp? You will have to install them into your VDI disk image natively. But then you break the common image thing? (Unless you want to install every non-ThinApp compatible app into a single disk image, which is just not realistic because then you have to manage all those apps.)

      So to me, I think you like the "promise" of VDI, and what VDI can be in a year or two. But I think your view is not realistic for today.


      First of sorry for the double post and let me make a quick addition I'm not a techguy. So please do correct me if i'm wrong


      I think that the underlying infrastructure of VDI is cheaper to build and manage compared to a TS setup. With VDI it's a matter of virtualization layer, broker and one gold image that is shared between many users (user delta) The gold image holds all the apps and could be virtual(VDI) or physical(desktop). With TS you still need to manage that corporate image for the normal desktops but you get an additional TS app environment to manage. That is two application management processes instead of only one you've got with VDI.

      Also TS management is carried out by expensive personel that is highly qualified and certified. VDI management could be carried out by more inexpensive personel because the single image is just generic windows desktop management and a more common knowledge in the market.

      ps. thank you for your response!


      @Calvin Hsu it was a presentation on 'what does desktop virtualisation in the real world deliver' - and it was really a slide on  'desktop strategy' that needed some re-engineering of though when some customers viewed it, That slide showed 'office workers' as the largest group - and "office workers" 'requiring' a personalised environment.

      I'd agree with what your saying - but that message was lost in from that slide.

      @ n00b - no I can't agree with that at all. VDI is not cheaper to build than a TS environment. Your VDI hosting environment needs to be managed and maintained, your gold image still needs to be managed and maintained - its gold once only its released - what about your app patches, your security fixes, your AV updates - who maintains the application logs, the performance information. When department X needs a new app how is that integrated. Whats the image deployed to - because if its not a thin terminal you've the same "problems" as TS.

      And in terms of the 'specialist personnel - who manages the VDI delivery environment? Who monitors the bootp/dhcp infrastructure? Who feeds and waters the  infrastructure that hosts your VDI desktop? Because thats not desktop PCs - thats server class H/W & OS

      One of the common mistakes of running a TS farm is to expect that the TS server supporting the 50 users is just a big desktop PC and doesn't need to be managed in any way shape or form - I expect the same issues if the the VDI infrastructure is left to its own devices as well.