How VMware is misleading everyone about the cost savings of VDI
Written on Feb 23 2009
3,938 views, 22 comments
by Brian Madden
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.