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 :)

I just came back from a few days vacation to find multiple emails in my inbox from VMware customers and partners looking for a response to a series of bizarrely rambling posts (here, here, here and here) on Microsoft's virtualization team blog.  Normally, we'd avoid a tit for tat exchange, but the Microsoft postings contained some confusing and erroneous depictions of VMware technology that I hope to address and correct here.

Hypervisor Disk Footprints

We've consistently taken the position that a smaller hypervisor is inherently better and we've found that most people agree with us, including Microsoft's Technical Fellow, Mark Russinovich (see his presentation from Burton Group's Catalyst Conference in July.)  The reasoning is that every line of code unavoidably adds reliability and security risks.  Microsoft has cited those same benefits of "smaller attack surface" from code size reduction as the motivation for their slimmed down Server Core and Hyper-V Server alternatives.  We don't know how many lines of code are in a Hyper-V system, so we use the installed disk footprint -- the size of the installed files needed to support virtual machines -- as a reasonable proxy for lines of code.  In calculating hypervisor disk footprints we need to follow a few rules to ensure consistency:

• The installation must be sufficient to run VMs and support all advertised features.
• Any operating systems in management partitions, Dom0s or service consoles needed by the hypervisor should be included.
• Management of the hypervisor can be from a remote client, so local management clients can be excluded.
• Pagefiles, swap partitions, scratch/temp partitions and core dump partitions can be excluded.

In the case of ESXi, here's the sequence we followed to calculate its disk footprint:

• Start by installing ESXi 4 on a bare server.
• Use the vSphere Tech Support Mode to display the contents of the ESXi boot images in the /bootbank directory.
• A df -h command will then show you that the total size of those compressed ESXi boot images in the directory corresponding to /bootbank is 59.3MB -- somewhat less than the 70MB figure we've publicly stated.  The other partitions in the listing are either loaded only in memory (/), or they are excluded per the rules above.  Note that this is not just a stripped down ESXi installation, it is a fully capable ESXi host supporting all licensed vSphere features.

For comparison, here's a look at the disk footprint of ESX 4.0 "Classic", which measures about 1.7GB.  Most of the additional footprint is due to the Linux-based service console.

The disk footprints we measured for Hyper-V R2 RTM are far larger.  Windows 2008 R2 Server Core with the Hyper-V role enabled, was 3.6GB.  For those Hyper-V users that want to preserve the "Windows they know," a full Windows Server 2008 R2 installation is pushing 10GB.  (The Hyper-V Server R2 RTM is not available to us yet, but we expect that its footprint will fall between that of Server Core R2 and full Windows Server 2008 R2, as it did for R1.)  For the graphically inclined, here's a comparison that shows just how much less "surface area" ESXi presents to bugs and attacks.

Yes, ESX "Classic" does use a Linux-based service console and therefore has a larger disk footprint, but VMware has publicly stated that the OS-free ESXi architecture is our future direction and ESXi has all the capabilities of ESX "Classic".  Microsoft has made no such commitments to eliminate Hyper-V's dependency on Windows.  In fact, Microsoft CEO Steven Ballmer has stated that, "Our view is that virtualization is something that should be built into the operating system."  Not very encouraging for those hoping to see Hyper-V decoupled from the Windows monolith.

Microsoft's explanation in their blog that, "our entire footprint which is made up mostly of stuff that isn't exposed to VM traffic at all or only exposed indirectly," isn't something I'd want to boast about and it's exactly the thinking we wanted to get away from with the ESXi architecture.  We made ESXi exclusively dedicated to VM support and it doesn't bring along the baggage of a general purpose OS.  Why would you want your hypervisor to be dependent on the proper functioning and security of tens of millions of lines of code that have nothing to do with supporting your VMs?

Hypervisor Patching

Microsoft's blog then moves on to argue that patching is somehow less of a burden with Hyper-V because the aggregate size of its patches are less than for ESXi.  I'll give them credit for creativity in coming up with that argument, but it's really meaningless.  Because ESXi is installed and patched like an appliance -- the entire image is replaced as a whole -- our patches are naturally the size of the full ESXi installer package.  Our customers prefer that appliance approach because it ensures consistency in the their installations and avoids "patch drift" away from a validated configuration.  With the Windows Update-based patching used for Hyper-V, patches can be smaller, but customers can skip or miss patches, resulting in insecure, partially patched configurations.

What really matters in patching is the number and disruptiveness of the patches.  With ESXi, we've dramatically cut down on the number of patches customers need to download and apply.  The biggest reason for the reduction is the elimination of the Linux-based service console.  The more frequent rate of ESX "Classic" patches is mainly due to our approach of playing it safe for customers by distributing patches for any issues affecting the Linux-based service console, even though most of those patches aren't needed by customers because the Linux services addressed by the patches are normally disabled in an ESX installation.  Also, we do patch ESX "Classic" incrementally using the "surgical fix" approach with smaller patches that Microsoft seems to advocate.

With both ESX and ESXi, a host reboot following patching has always been non-issue because VMotion and Maintenance Mode make it trivial to shift VMs to alternate hosts during the reboots.  Microsoft's customers must certainly be looking forward to using those same features in the long-awaited release of Hyper-V R2.

However, what must really be frustrating to Hyper-V users is the need to constantly patch and reboot Hyper-V hosts with miscellaneous Windows Server 2008 patches that have nothing to do with virtualization.  Even if you use the stripped-down "Server Core" version of Windows Server 2008 that Microsoft recommends for production Hyper-V system, you're almost guaranteed to need a host reboot every "Patch Tuesday."  We've kept track of the "Patch Tuesday" patches required on a Server Core Hyper-V system since Hyper-V first shipped in June 2008 and there have been multiple "Important" or "Critical" patches to apply almost every month.  Most of those patches don't apply to Hyper-V, but users must still install them and then reboot their hosts.  And, as users are painfully aware, Hyper-V R1's missing live migration support has meant downtime for their VMs with each reboot.  The downtime may lessen with Hyper-V R2, but the patches won't.

The Hyper-V patching situation really points out the need to keep the hypervisor free of dependencies on a general-purpose OS.  Microsoft tried to reduce the OS dependencies with the stripped down Server Core concept, but the numbers above clearly show they didn't improve life for their customers.  For VMware customers, the truly thin ESXi architecture means no such extraneous patching and rebooting is needed.  If Microsoft has discarded their familiar GUI with Hyper-V Server and Windows Server Core, why do they persist in making Hyper-V dependent on Windows, especially after VMware ESXi has demonstrated that a hypervisor has no technical need for a general-purpose OS?  We can only surmise that Microsoft is trying to extend their Windows franchise with an edict to their business units that all servers must be built on top of Windows.  It's just too bad their Hyper-V users have to suffer the inconveniences and risks of that OS dependency.

Bugs and Vulnerabilities

Microsoft's blog then gleefully brings up last year's ESX 3.5 Update 2 timebomb issue in an effort to find fault in our patching process.  The timebomb bug was a major goof in our release process, we were mortified and we rightly took our lumps, but it had nothing to do with our standard patching process.  Microsoft's description of the bug as causing two days of downtime for our users is just plain wrong.  Powered on VMs kept right on running when the timebomb activated and we had a patch out in less than 24 hours that, when used together with VMotion and Maintenance Mode, meant few production users suffered any downtime.  Despite the facts, I'm sure Microsoft will remind us of that episode many more times to come.

The residents at Microsoft's glass house had some other stones to toss our way.  Microsoft pointed to CVE-2009-1244 as an example of a guest breakout vulnerability in ESX and ESXi.  A guest breakout exploit is serious business, but, once again, Microsoft is misrepresenting the facts.  VMware responded quickly to patch that vulnerability in our products, and ESX was much less affected than Microsoft would lead you to believe:

• The exploit was purely theoretical for generally available versions of ESX and ESXi.
• No working exploit was ever provided for any version of ESX and ESXi.  The reporters only showed an example of the exploit on VMware Workstation.  They claimed a pre-release version of ESX 4.0 to be vulnerable, but no exploit was demonstrated.
• The exploit reporters have since acknowledged that released versions of ESX 4.0 and ESXi 4.0 are not vulnerable.

The truth is, vulnerabilities and exploits will never completely go away for any enterprise software, but ESX has been remarkably resistant to such issues.  If it happens again, we'll find the problem and fix it quickly, as we did for CVE-2009-1244.  I'll also point out that a guest breakout is a much more serious issue when it drops you into a familiar general-purpose management OS like the Windows Server 2008 parent OS used by Hyper-V than it is with a design like ESXi where an escape grants access to just a thin, hardened hypervisor like our vmkernel.  A hypervisor that relies on an OS like Win2008 with a history of regular and recurring remote vulnerabilities will always make an easier target for attackers and should not inspire false confidence.

In response to Microsoft's discussion of their own security practices, I should also point out that VMware has a Secure Software Development Lifecycle (SSDL) as well as a Product Security Policy (PSP) in place.  We invite our customers (and Microsoft bloggers) to learn all about it later this month at VMworld 2009 session TA2543 that we've dedicated to the topic.  There's really no need for the petty sniping by Microsoft on this topic.  Both VMware and Microsoft have rigorous security development processes and both ESX and Hyper-V have achieved the demanding Common Criteria EAL 4 level of certification (actually level 4+ for ESX.)

Performance Benchmarking

The last potshot from Microsoft's blog was directed at VMware's policy of requiring review of performance benchmarks of VMware products prior to publication.  Microsoft claims we're trying to control and distort the truth.  I've explained the rationale behind our benchmark policy previously in this blog.   VMware is in no way trying to restrict publication of valid performance data.  In fact, we have approved plenty of benchmarks that show other products leading in tests.  Our friends at Citrix have submitted multiple test results that we have approved.  We'd be happy to do the same for Microsoft, but they have yet to make a request.  I wonder why?

OK, that's enough attention paid to the Microsoft blog.  I hope to see you all at VMworld shortly where we can all discuss where VMware is going -- with SpringSource and our Cloud initiatives, it's getting pretty exciting around here!

 First of all, Thanks! and Welcome!

I want to first say thank-you and welcome to all the new VMware customers who have taken advantage of the VMware Safe Passage offer for stranded Virtual Iron customers.  The response has been very overwhelming!  I hope you are all having a good experience with your transition to VMware – technically it is a pretty straightforward process – we’ve even created this nifty KB article to help, located here:  Using VMware Converter to convert Virtual Iron Machines to VMware virtual machines

Use Virtual Iron as Long as You Need to Before Migrating to VMware vSphere

But the main motivation for this post was to answer a question that we’ve gotten from a number of organizations that are interested in pursuing the Safe Passage program - "What happens to my Virtual Iron licenses when I buy VMware?"  Well, the short answer is "Nothing".   I guess people were thinking that they’d have to immediately stop using Virtual Iron, but that’s not the case.  We're not requiring that anyone complete a Certificate of Destruction for the Virtual Iron software or accept any other terms necessitating that you discontinue use of that product.  Every organization that purchases VMware solutions through the Safe Passage program can continue to use the Virtual Iron software for as long as required, enabling them to migrate to VMware vSphere on their own time table, when it best meets their requirements.  No pressure whatsoever, just an excellent discount on an excellent product - if I don't say so myself.  Hope that helps.

But Our Time is Running Out

For those of you still considering the offer, get virtually moving! You’ve got until the end of September. Please feel free to email any other questions to the VMware Safe Passage team at safepassage@vmware.com .  You can also find more information on the promotion at the following link: http://www.vmware.com/landing_pages/safe-passage-promotion.html

Stay Classy San Diego,

-Tim

UPDATE May 20, 2009 – Oracle again revised its support policy for virtualization of its software on a non-Oracle hypervisor.  Please refer to Chris Wolf’s follow up post on the topic for the complete details, but in sum Oracle slightly altered the text in its Metalink Note 794016.1 to remove mention of specific hypervisors that are “not explicitly certified, but supported” as a platform for Oracle products. 

The bottom line however is that VMware ESX is still a supported Oracle platform.  Oracle Metalink document 294212.1 still reigns supreme – it is still in effect, it has not been modified, and it still explicitly defines Oracle’s support policies for VMware virtualized environments.  It is on the basis of this document that VMware customers continue to deploy Oracle on VMware with confidence.

May 8, 2009

I had to post a short pointer to a blog post by esteemed Burton Group analyst, Chris Wolf ,because it might contain information that could make life a lot easier for our the thousands of VMware customers that run Oracle applications in a VMware virtual environment. 

Chris recently wrote on his on his personal blog, that with Oracle Metalink Note 794016.1, (which can be viewed with an Oracle Support account), “Oracle now offers best effort support for all of its E-Business Suite applications on any x86 hypervisor.”

…and of course VMware ESX is included in that group “any x86 hypervisor”

Chris then provides some quotes from the Metalink note, which I have pilfered recreated below:

This Metalink Note appears to say that 1) Hypervisors from VMware are officially  supported platforms for Oracle E-Business Applications and 2) Organizations running Oracle applications in those environments are entitled to best effort support from Oracle.

So VMware customers, this sounds like great news!  Oracle really DOES offer “best effort support” for VMware solutions!  Virtualize On!

Read the news straight from Oracle on its E-Business Suite Technology Blog.

Just a quick note to everyone to let you know that along with the launch of vSphere last week, we were also able to update the VMware Cost Per Application Calculator to fully reflect vSphere pricing and packaging.  You will all now be able to model a vSphere environment and estimate the additional cost savings that vSphere can enable over Hyper-V – or to put it another way, how much more expensive Microsoft’s “free” Hyper-V offering really is.

And those vSphere cost savings apply to large enterprises and smaller environments alike.

Smaller IT Environment Using vSphere Standard

Just going through a quick calculation myself, I see that if I wanted to virtualize 50 applications using the vSphere Standard edition, I could expect a 21% savings over Microsoft Windows Server 2008 Hyper-V plus Systems Center.

And, I would actually break even with Microsoft offering – at the same consolidation ratio!

Large Enterprise Deploying vSphere Enterprise Plus

But even our top of the line vSphere Enterprise Plus solution is less expensive than Hyper-V. When creating 1,000 virtual machines on vSphere Enterprise Plus, an organization can expect to save 8% over Microsoft’s so-called cheaper offering – and the VMware offering is a production proven Cloud OS that can aggregate all aspects of your datacenter into a seamless pool of resources, whereas Hyper-V is just a hypervisor. vSphere: It’s the best solution, but you have to be willing to pay less for it!

And again the VMware customer would break even with Hyper-V at only an additional three VMs per ESX host – even with Enterprise Plus…

But Wait, There’s More!

The current version of the calculator assumes that vSphere will enable the same level of application consolidation as VI3. That is not really accurate. What we’re finding in our initial testing is that when 1) factoring only software improvements and 2) running on the same hardware on which we tested VI3, vSphere can enable 30% greater density than VI3. We’ll be validating this testing with a third party and will update the model soon. What this means of course is that vSphere can enable even greater savings over Hyper-V than what is represented here. (Especially when even Microsoft is seeing a whole 6:1 VM density on its Hyper-V servers)

And, when we account for the advances in hardware and utilize servers that incorporate the new Intel Nehalem microarchitecture, it just gets even better! Again, we’ll incorporate all that into the model soon.

Also Thanks for All Your Continued Feedback

We are working on some additions to the calculator – yes we’ll get a .pdf version of the report ready, so you can email the results to your boss. We might even add a Citrix comparison to the calculator as well – the results are very similar.

After catching Microsoft in the act of removing a layer of the Hyper-V architecture to back up their claims that VMware vSphere somehow “taxes” users with extra layers, it now appears that their partners are making unfounded derogatory statements about VMware while posing as VMware partners. If you haven’t seen it, ChannelWeb published an article this week titled, “Microsoft Continues To Rain On VMware's Parade”. In the article, after a repetition of “the additional layer theory” by David “substrate” Greschler, director of Microsoft virtualization and management, you will find a quote by Rand Morimoto, president of Convergent Computing, who is quoted as saying:

“More and more of our customers are switching over from VMware to Hyper-V because Hyper-V uses a familiar interface, works out of the box and is included in the organization's existing licensing agreement."

The original version of the article identified Convergent Computing as a, “solution provider that partners with both Microsoft and VMware.” (CMP has since revised their article. It now says the company is a, “solution provider that has a staff of consultants with expertise in Hyper-V and VMware.”) Our partner team at VMware saw the article and immediately told us that Convergent Computing is NOT a VMware partner at all. That set off some alarms, so we followed Rand Morimoto on Twitter to see what else he had to say that might clear up the mystery. When we found him, we discovered he is essentially a Microsoft spokesperson who has even a Microsoft badge…check it out:

If Rand is close enough to Microsoft to be issued a badge, we don’t think his comments about VMware users should be accepted as truth, especially when he provides no examples of customers who have supposedly made the switch to Hyper-V. The subterfuge didn’t fool us and it also didn’t fool the CMP readers, one of whom left this comment to the article:

“I have had the pleasure of knowing Rand Morimoto, president of Convergent Computing who is quoted in this article, for around 18 years (we both served on the Microsoft Partner Advisory Council and were Microsoft MVPs, and ran neighboring Novell Platinum shops before that).  While Rand is a brilliant and accomplished technologist as well as concert pianist, former gymnast, really nice guy and all around Renaissance man, one thing his organization is not is VMware certified.  This article makes it seem as if CCO is an unbiased partner of both Microsoft and VMware, but CCO credentials are 100% on the Microsoft side.“

Now that we’ve seen that the reference partners Microsoft trots out for the press can’t be trusted, let’s go back to talking about real technology instead.

Did you catch the latest video from Microsoft’s virtualization team?  In this one, the Microsoft guys are making the argument that VMware somehow imposes a “virtualization tax” by inserting an additional layer in your datacenter architecture that Microsoft doesn’t need.  I’m familiar with Microsoft’s Hyper-V architecture and knew that as far as the count of layers, it’s no different than VMware.  So what has changed?  Did Microsoft achieve the impossible and remove a complete layer from their virtualization architecture without so much as a service pack?

Here’s how the VMware architecture looks:

From bottom to top, I count four layers: 1) the x86/x64 hardware; 2) the hypervisor (VMware ESXi); 3) the guest OS in the VM; and 4) the application in the VM.  It’s nothing surprising and the same diagram we’ve used for years to explain how our products work.

Now, let’s take a look at the latest Microsoft architecture using a diagram from their video:

Wow, maybe they’re right!  I only count three layers.  How did they do it?  They got rid of an entire layer.  Is virtualization now part of the guest OS?  Maybe they figured out how to make their apps run directly on Hyper-V with no guest OS at all?  It’s especially amazing when all the Hyper-V product presentations I’ve ever seen and even Microsoft’s own virtualization white paper on their web site use a diagram like this:

This picture clearly shows the same four layers as the VMware architecture with Hyper-V operating as a type 1 or “bare-metal” hypervisor running directly on the hardware.  In fact, compared to the OS-free ESXi architecture, Hyper-V even adds in that extra copy of Windows Server 2008 you see on the left side.  Should we count that as a fifth layer?

So, has Microsoft achieved a software miracle by fully eliminating one or two layers from the Hyper-V architecture?  Are VMware users really stuck paying a “tax” due to an excess layer in our design?  Or could it be that Microsoft has simply redrawn their pictures and changed their story on how Hyper-V really works?  I’ll leave it to sharper minds than mine to uncover the answer to this mystery.

As to the Microsoft claims of costing one-third as much as VMware repeated yet again in their video, we ask that you not be fooled.  Microsoft may give away Hyper-V with Windows Server 2008, but they are charging big bucks for System Center management and all the servers, databases and agents you need to compare with our combination of VMware ESX and vCenter.  It’s not easy to figure out all the Hyper-V and System Center pieces required to run a given number of VMs, but we’ve done the hard work for you in our Cost-per-Application Calculator.  Give it a try and you’ll see that, even without the VM density advantage you get with our exclusive memory overcommit capability, VMware costs about the same as Microsoft.  You’ll also see that running just a few extra VMs per host with ESX operating at a very conservative level of memory overcommit quickly yields a 20-30% cost advantage for VMware.

Anyway, nice try with the sequel guys – do you have plans to make it a trilogy?