Home > Blogs > Virtual Reality > Author Archives: VMware View

Author Archives: VMware View

Response to Brian Madden’s Blog Entry about Cost Savings of VDI

Background
At last month’s VMworld Europe conference, one of the sessions in the desktop track was focused on the topic of TCO for VMware View. (Click here to view the content: http://www.vmworld.com/docs/DOC-2782). Brian Madden, a blogger, attended the Partner Day version of this training session and subsequently issued a blog entry claiming that VMware was misleading customers by positioning VMware View (VDI) against traditional desktops, not against TS (Terminal Services).  (URL for full blog entry: http://www.brianmadden.com/blogs/brianmadden/archive/2009/02/23/how-vmware-is-misleading-everyone-about-the-cost-savings-of-vdi.aspx).  The following is VMware’s response to the claims made in Brian Madden’s blog entry.

Summary

  1. VMware does not message TCO for VMware View (VDI) compared to TS because customers select View solutions specifically to address use cases they have not been able to fully meet with traditional desktops and/or TS, e.g. delivering a full desktop replacement to users, not just access to point applications like email.
  2. TS can often provide greater user density on a server, but those applications must be validated to work well in a multi-user environment.  Without the benefits of isolation, HA, DRS, etc. that VDI brings with the VI3 platform, all users in a TS environment on a given server will be affected when a single user experiences an application issue, resulting in a higher TCO over time.
  3. When applications are not compatible with ThinApp, they can still be used in a VMware View Composer environment by being installed into the Master Image, making minor impact to the total storage consumed and in the TCO calculations.

After criticizing VMware for comparing View with traditional desktops, but not including TS in the discussion, Brian Madden proceeded to post another blog entry, taking an about-face on his stance, by saying “So positioning VDI against Terminal Server is somewhat of a losing battle that trivializes its larger potential. Why not let Terminal Server “win” against VDI today, because when VDI is ready, it will not be about “VDI versus Terminal Server”—it will be about ‘VDI versus traditional desktops

What was claimed in Brian Madden’s blog and what is VMware’s response?

Excerpted from Brian Madden’s blog:
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 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.

VMware Response:
True, the OPEX savings presented at VMworld Europe, and that are used in VMware’s online TCO/ROI calculator are based on 3rd party analyst (Gartner and Forrester) reports on comparisons between traditional desktops and server-based computing.

The real bottom line is that customers don’t consider a VDI solution because they think it will be cheaper than TS, but rather, they consider VDI when TS does not meet their needs.  The footprint of TS is wide across enterprise organizations (though rarely deep), and even the customer who presented at VMworld Europe during the “Understanding TCO for View” session acknowledged he had hundreds of TS servers that he would keep around, and was considering VDI because TS didn’t enable him to replace the thick desktop he still needed to provide to users.  As he details in his slide from VMworld, similar to many customers, TS is used in his organization to provide
access to a bare set of applications, coexisting with thick clients to
meet the full use case. Slide20

In considering a VDI architecture, a true desktop replacement is possible, potentially at a higher cost than TS, but with the ability to deliver a full desktop to a user without compromise on applications compatibility, user environment and stability due to lack of workload isolation. 
Another point to add is, if Citrix felt TS was sufficient to meet all their customers’ requirements, they wouldn’t have bought a virtualization platform and launched their own VDI solution.

Excerpted from Brian Madden’s blog:
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.

VMware Response:
Yes, TS is a great way to get high density on a small number of key applications – when those applications work well in a multi-user environment.    Customers move to VDI because because Citrix/TS doesn’t work for all situations, and when it doesn’t, you still need a solution like VDI for the exceptions.  Many VDI customers fall into this category.

Excerpted from Brian Madden’s blog:
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…)

VMware Response:
Really? You want to share one copy of Windows Server 2003 with a bunch of other folks running a crash-prone application, even if the consolidation ratio is the same?  TS does not have the workload isolation benefits of virtualization, so sharing resources for intense applications can result in instability and availability issues that result in more support calls and a higher TCO.  In contrast, virtual desktops are completely isolated as well as disaster recovery-enabled through the HA and DRS capabilities on the VI platform.

Excerpted from Brian Madden’s blog:
Misleading Tactic #2 – VMware assumes all apps will work with ThinApp
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?
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 Parent Image, (b) be installed for each user into the diff clones, or (c) you'd need to have multiple Parent 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.

VMware Response:
To reap the storage savings benefits and one-to-many image management architecture of View Composer, you do need to think about your applications a different way.  If the application is not compatible with ThinApp, then there are several options that can be utilized to yield the end result of working with View Composer and enabling a single point of management. 

  • Category A:  A single Parent Image with View Composer and Thinapp.  To minimize storage utilization, applications should be validated for ThinApp, keeping applications installed directly on the Parent Image to a minimum. We typically see that about 80% of applications can be ThinApped without issue.  These ThinApp’ed applications are installed on a server and streamed to users on demand, making application management faster and simpler.
  • Category B:  Multiple Parent Images for different User Groups – For applications that are not compatible with ThinApp, you will need to install the application directly onto a separate Parent Image.  While you are now managing more than one linked clone Parent for different user populations, you are still gaining considerable storage and management benefits with the one-to-many View Composer architecture.  Even with multiple Parents, the storage reduction numbers are compelling.  Since only 20% of applications are not compatible with ThinApp, typically those with specialized hardware requirements, the total number of Parent Images required in a View environment should be minimal.  The ability to have centralized distribution of these virtual applications coupled with a few Parent Images can easily yield storage reductions by greater than 75% compared to traditional VDI or desktop requirements.  Using small pools with each of these Parent Images delivers cost savings through reduction of overall storage and management overhead.
  • Category C: If all else fails, for the particularly troublesome applications, a full independent VM may be needed, but the application management used would still leverage traditional tools like SMS/Altiris.  The impact to the cost model would be additional storage for this population of full desktop VMs, but it should constitute the smallest population of desktops in the overall deployment.