VMware: Virtual Reality

Even taking off my VMware hat – or actually my VMware Army uniform- I doubt that many were really considering running Linux workloads on Windows Server Hyper-V in the first place. But if they were, these statements today by Bob Muglia, President of Microsoft’s Server and Tools Business, which includes Hyper-V, probably stopped them in their tracks.

 Microsoft States the Obvious – Linux is a Top Competitive Priority

Network World editor John Fontana, in an article titled, “Top Microsoft Execs Outline 2010 Challenges” wrote of asking Bob Muglia to identify his top three threats (Bob, like any good executive, of course re-categorized them as “opportunities”). Winning the Bronze Medal for third place --- Linux!

Concerning Microsoft competition with Linux, Bob says:

“We've gained share, almost two points of share against Linux last year, but we still see a great opportunity for us to serve our customers better than the open source Linux world. And here we're focusing on doing it with workloads where we have relative weakness like Web and high-performance computing, and we see great opportunities to continue to grow in those spaces," he said. "So, we're making the right investments there."

So only a month or so after contributing code to the Linux kernel, seemingly embracing Linux as a viable alternative to Windows and validating the open source software development model, Microsoft is now stating that taking share from Linux is a top competitive priority for 2010 and that Windows can serve customers “better than the open source Linux world.”

 The Big Question – How Credible are Microsoft Statements that Windows Hyper-V will Support Linux?

So given Microsoft’s statement of the obvious, let me ask, how believable is Microsoft when it claims that Linux workloads will be first class guests on the Hyper-V component of Windows Server 2008? How can a company, Microsoft, claim to fully support a guest operating system, Linux, that it would really like to see disappear?

 But Again, There’s More!  There are Also Many Technical Reasons Why One Wouldn’t Want to Run Linux on Hyper-V

Microsoft’s lack of interest in encouraging anyone to run applications on Linux is reflected in the limitations it puts on Linux guests run on Windows Server 2008 Hyper-V

1) Hyper-V Supports only a small number of Linux guest operating systems

According to Microsoft documentation, Hyper-V R2 supports only these Linux guest operating systems:

• SUSE Linux Enterprise Server 10 with Service Pack 1 (x86 or x64 Edition
• SUSE Linux Enterprise Server 10 with Service Pack 2 (x86 Edition or x64 Edition)
• SUSE Linux Enterprise Server 11 (x86 Edition or x64 Edition)
• Red Hat Enterprise Linux (RHEL) 5.2 and 5.3 (x86 Edition or x64 Edition) (Emulated devices only)

The "Emulated devices only" limitation for RHEL guests is there because no guest additions (similar to VMware Tools) have been released by Microsoft for RHEL.  That means that RHEL guests will suffer from performance limitations because they lack paravirtualized guest network and storage drivers.  VMware vSphere provides high performance paravirtualized network (vmxnet3) and storage drivers (PVSCSI) with the VMware Tools available for all vSphere-supported guests.

2) Microsoft Hyper-V lacks Linux SMP support for those small number of Linux guest operating systems

Hyper-V R2 supports only single virtual processor configurations for any Linux guests.

3) Microsoft Hyper-V lacks core features to support those Linux guests.

Additional features not supported in MSFT Linux guests -the following features are not supported:

• Integration Services: Operating System Shutdown, Time Synchronization, Data Exchange, Heartbeat, Volume Snapshot
• Backup Networking: Jumbo Frames and TCP Offload
• Storage: Hot Add/Remove (VHD’s and Pass-through Disks)

VMware solutions will always treat Linux as a tier one guest operating system

VMware vSphere can and does support the most demanding workloads in Linux guests with its high-performance paravirtualized in-guest drivers, up to 8-way virtual SMP, and 255GB maximum guest memory for all supported Linux guests.  With VMware vSphere, Linux is considered a full peer to Windows guests. We fully enable Linux deployments in your virtualized infrastructure.

If you haven't already done so, now might be a good time to surf over to the Project Virtual Reality Check site (registration required).  No, it's not a web page dedicated to proofreading this blog.  It's run by a team of virtualization consultants that have been publishing comparisons of VDI and Terminal Services performance in various hypervisors.  They made a big splash back in January with their first set of reports comparing ESX 3.5, XenServer 5.0 and Hyper-V R1.  Our exclusive ability to overcommit memory made ESX the clear winner in the VDI tests with support for more than twice as many VMs as the others.  On the Terminal Services tests, it was XenServer that came out ahead in the number of user sessions it could handle.  It wasn't good news for VMware, but the story doesn't end there.

Nothing gets us more worked up than finishing second in a product comparison, so our performance team started digging into the Project VRC benchmark to see what might be going on.  Right off the bat, we saw that ESX wasn't configured to use the hardware assist for memory management (AMD RVI) that was present on Project VRC's servers.  ESX 3.5 was the first hypervisor to support hardware assist for memory management and we certainly wanted ESX to look its best.  The Project VRC guys updated their ESX test report in March and the findings showed that ESX narrowed the XenServer lead in Terminal Services user sessions by half once RVI was enabled.  It was an improvement, but we still weren't ready to accept second place.

The Project VRC results prompted us to do some rigorous testing of ESX performance with XenApp -- a workload based closely on Terminal Services -- and our findings convinced us that we could support more user sessions, so what was going on with the Project VRC tests?

It turns out that the Project VRC team was also taking a second look at their benchmark.  Our performance team (and also the experts at Citrix) collaborated with Project VRC's test architects and all groups came to the conclusion that timing issues were skewing the results.  Use of in-guest timers, one of the classic demons in virtualization benchmarking, was identified as a problem area.  You can see our take on it here.

The Project VRC team dug in and developed a completely new Terminal Services benchmark that reduced use of in-guest timing, when compared to the first version.  The new workload created by Project VRC still depends on in-guest timing, but is a big improvement over the first version and we're grateful for Project VRC's efforts and flexibility.  VMware was also hard at work since the first Project VRC tests improving performance in vSphere.  Our own testing demonstrated a 30% improvement in XenApp throughput between ESX 3.5 and 4.0, so we expected a strong showing in new test runs.

When the first Project VRC comparisons came out, we saw Citrix promote them heavily, especially with customers that were deciding on a virtualization platform for their XenApp servers.  XenApp and Presentation Server customers have been rapidly moving those servers into VMware virtual machines and it's understandable that Citrix wanted some independent test results that might slow down what they saw as defections and keep those XenApp servers on their hypervisor platform.

If you're a XenApp user making a virtualization platform choice you need to read the new Project VRC paper that came out last week NOW.  The paper is titled, "VRC, VSI and Clocks Reviewed".  The results have shifted dramatically since the January findings.  Instead of trailing, ESX 4.0 now has a 4% advantage over XenServer 5.5 in the number of Terminal Services users it can support on a server. 

We attribute the turnaround for vSphere in the latest tests to the Terminal Services/XenApp performance enhancements we made in ESX 4.0 and improvements made by Project VRC to their benchmark.  These new results will come as big relief to XenApp users that felt pressured to virtualize on XenServer after seeing the old Project VRC numbers.  When presented with test findings that seemed to show XenServer could support more users per host, it was harder to choose the proven reliability and richer feature set provided by VMware vSphere.  We certainly hope no customers were lured into making the wrong choice based on test results now known to be flawed and outdated, but those of you yet to make that decision will be happy to know that the latest Project VRC comparisons make the selection of vSphere a no-brainer.

Despite the fact that Hyper-V R2 addresses some of the issues of R1, Microsoft Hyper-V still cannot compete with VMware vSphere on a value-added capabilities and functionality. Just look at how Burton Group (“Microsoft Hyper-V Still a Work in Progress”) still deems Hyper-V R2 as not enterprise-ready. Therefore, Microsoft resorts to competing with VMware on cost. As such, Microsoft execs have been going around touting how Hyper-V is an order of magnitude cheaper than vSphere. Actually it is funny to see how the fraction they cite keeps changing -- the claim started at 1/3^rd the cost of VMware (“…We [i.e. Microsoft Hyper-V] are one-third the price of VMware's”), then became 1/5^th (“…the cost of vSphere Enterprise is five times that of buying the Microsoft solution”), and now Microsoft execs are saying 1/6^th the cost (“…Hyper-V, which ships with Windows Server 2008, costs one sixth that of VMware's virtualization solutions”). I guess 1/3^rd didn’t work or something so they keep marking it down – 25% off, 50% off, no wait if you buy now 75% off!

Given all this noise, imagine my surprise when I see a Microsoft blog that basically debunks Microsoft’s own “1/6^th the cost” claim. In “Investigating the VMware Cost-Per-Application Calculator”, a Microsoft employee publishes a lengthy dissertation on our updated VMware Cost Per Application Calculator with which we demonstrate how thanks to its superior technology vSphere is actually a less expensive solution than Hyper-V. It appears that the author’s intent was to point out our model’s supposed flaws. But, one would have expected that after he “fixed” all of our “flawed” assumptions, his calculations would definitively show Hyper-V as truly 1/6^th the cost of vSphere. However that’s not the case at all. In, fact, the only clear takeaway from Microsoft’s blog, after all the twists, turns, objections and re-calculations, is that Hyper-V is nowhere close to being 1/6^th the cost of vSphere. Even in the author’s best case scenario for Hyper-V, in which Hyper-V hosts run more VMs than vSphere ones thanks to more physical RAM on the Hyper-V hosts, Hyper-V is only 31% less than vSphere’s highest-end edition. Last time I checked, 31% less is nowhere near 1/6^th the cost. If he had compared Hyper-V to lower-end editions of vSphere, those that more closely match what Hyper-V R2 delivers, there would have been practically no cost advantage for Hyper-V R2.

The bottom line is that Microsoft’s blog doesn’t uncover anything new about the VMware Cost Per Application Calculator. Quite the opposite, it confirms it. Try our calculator for yourself and create a customized report. You will find that it includes a sensitivity analysis showing vSphere’s cost per application at different consolidation ratios. The analysis clearly demonstrates that even at equal consolidation ratios (worst case scenario for vSphere), Hyper-V’s total acquisition cost is, at best, only marginally lower. Once you factor in vSphere’s tremendous consolidation ratio advantage over Hyper-V and vSphere’s ability to scale up to 2X more VMs than Hyper-V (check-out the “Evaluating the ESX 4 Hypervisor and VM Density Advantage” report), vSphere delivers the lowest cost per application by up to 20-30%. In fact, often vSphere becomes a less expensive solution than Hyper-V with just 1-2 more VM’s per ESX host – in addition to being a much more functional, more scalable, more proven product.

So you can either believe us when we say that Microsoft Hyper-V is actually about the same cost as VMware products or you can believe Microsoft when they say that VMware solutions cost about as much as Hyper-V – take your pick!

OK, now let’s get back to talking about how virtualization technologies solve business needs. Oh, and thanks Microsoft for busting your own myth.

This is the Last Post on The VMware Safe Passage Program for Virtual Iron

Everyone - just a quick reminder that we are still planning to end the VMware Safe Passage Program for Virtual Iron on September 30, 2009.  That means stranded Virtual Iron customers have only two weeks left to take advantage of the substantial discounts offered on VMware solutions - a 40% discount on license list price!

All you need is proof of a Virtual Iron support contract and you are qualified.  We've even provided technical documentation to enable you to easily convert your Virtual Iron instance into a VMware infrastructure, so you’ll be enjoying the stability and performance of the award-winning, enterprise proven vSphere platform in no time. 

Here’s How to Order

Full program details are available at the Virtual Iron Safe Passage Promotion website. Contact safepassage@vmware.com or your VMware reseller for more information.

 But Wait There’s More?

If you call now, we might even throw in some Mighty Putty!  --- Actually…you could give the Mighty Putty to your friends who are trying Hyper-V.  Maybe it could help them patch all the vulnerabilities in Hyper-V’s large Windows Server 2008 parent partition!!  …wait did I write that out loud?

Thanks again to all the new VMware customers who have taken advantage of this promotion.  Based on its success, we’ll be rolling out a number of these types of offers in the near future, so stay tuned – it’s just a shame that Billy Mays isn’t around anymore.  And yes, the Mighty Putty comment was an attempt at a joke…in reality, it would never be able to fully patch Hyper-V + Windows Server 2008 :)