When I talk to customers about their initial experiences with virtual desktop deployments (VDI for VMware users), they have three key concerns:
- Complexity of the solution
- Cost per desktop
- User experience
At the most fundamental level, the ROI of a VDI deployment will be negative if users reject the solution because of poor performance. Most VMware VDI end users that I talk to, tell me that their user experience is “nowhere near that of a PC”. We think we deliver a compelling desktop experience with Citrix XenDesktop, which you can download here. Of course XenDesktop (which includes XenServer) is also optimized for Microsoft Hyper-V and fully supports VMware – so you get the best possible user experience independent of your virtual infrastructure.
But at the virtual infrastructure layer the heat is on, and VMware has made another clumsy attempt to inject FUD into the market in the form of a blog posting by Eric Horschmann of VMware who attacks the ROI of XenServer or Hyper-V based deployments of virtual desktops because, using ESX’s memory overcommitment feature, he managed to boot many more VMs on ESX than on XenServer / Hyper-V.
Roger Klorese (XenServer product marketing, and one-time product manager at VMware) corectly identifies the fallacy underlying the VMware claims:
“What do you think happens when those pages start to un-share or users start to load up different applications, as people start doing real work? How big do you need to expand those balloons, and how much do you have to starve those guests, to keep your 5:1 memory allocation? And if you can’t balloon 5:1, how much do you further degrade it when you start using the hypervisor swap file?”
There’s no such thing as a free lunch, and in VMware’s case there isn’t a free hypervisor either. When you overbook memory excessively, guest performance takes a hit. Not only will the hypervisor have to start swapping (so much for the claims that ESX is a lightweight hypervisor – it still contains swapping, which is an OS feature), but the guests will also start to swap. We have observed many occasions where ESX performance hits the floor because the hypervisor has to swap in memory pages just so that Windows can swap them out!
Several independent users have chimed in - a welcome addition to the debate. In a follow up to a CRN article on the topic, Stan Kasper writes:
“My experience has been that the memory sharing features in ESX place a heavy burden on performance. In fact, to optimize performance I disable the PSHARE option and do a fixed allocation of memory for each VMWare guest. PS My initialze test on the beta Hyper-V vs ESX for disk performance is that they are about equal, and maybe Hyper-V is a bit faster. But do not read to much into this as benchmarks are rather a finicky science.”
Though overbooking and common code page sharing are different things, even overbooking impacts performance, and causes major headaches and additional complexity and latency in suspend/resume and live relocation operations. But assuming for a moment that VMware’s memory overbooking and PSHARE are flawless and impose no performance overhead, then you can get a good idea of the performance per guest by taking the CPU speed of the server and dividing it by the number of guests. Though the CPU speed is not offered in the VMware “analysis”, let’s assume it’s a dual core 2GHz server with 4GB RAM. So each of Eric’s Windows Desktops gets about 50 MHz of CPU. Even with double the CPU, that’s only a 100 MHz PC. No wonder users are underwhelmed by their performance!
I conclude that VMware’s flawed focus on defending the price point of its hypervisor, and thereby maximizing dollar take per server, is in direct conflict with the customer’s goal in any Desktop Delivery project – a great user experience with terrific ROI.
Getting back to ROI, it appears that VMware also fails to understand that ROI is a solution-based analysis (not a hypervisor based one). The right way to calculate ROI for desktop virtualization is to compare the overall cost per desktop of a complete solution that delivers great user experience. One key piece of the architecture that is missing from VMware’s “pseudo ROI claims” is the storage cost. Citrix XenDesktop, with XenServer Platinum, can boot up to 1000 VMs from a single Windows golden image. That’s a factor 1000 less storage than the VMware “VM Sprawl” approach, and a factor 1000 less effort to patch and manage desktop workloads. And it doesn’t have to be stored on a SAN – VMware’s typical storage deployment. A thousand SAN based VMs will cost an awful lot of money. With XenServer / XenDesktop you can use any storage repository. For example - in XenServer 4.1 (download the beta here), we have direct integration with NetApp’s ONTAP API to leverage array-based snapshots and cloning, and to use their thin provisioning and block dedup technologies. So the real cost of the SOLUTION is what counts. My friends at VMware, heavily addicted to their SAN based storage architecture, drive customer acquisition costs for virtual desktops through the roof. Bottom line: Until you look at an overall solution cost per delivered desktop, you don’t have an ROI case.
The bottom line: VMware’s “ROI analysis” offers neither an ROI comparison nor any analysis. But it does offer valuable insight into the mindset of a company that will fight tooth and nail to maintain VI3 sales at the expense of a properly thought through solution that meets end user requirements. The very fact that the VMware EULA still forbids Citrix or Microsoft or anyone in the Xen community from publishing performance comparisons against ESX is further testimony to VMware’s deepest fear, that customers will become smarter about their choices, and begin to really question ROI.