Hello Hyper-V : Meet Reality (part deux)

Well my blog post yesterday drew way more attention that I thought it would. Part of the attention was a comment from the esteemed Ben Armstrong (twitter & blog).

He provided wonderful feedback and I have decided to highlight it here with my response. Not sure if I am breaking a blogosphere rule but, I shall claim etiquette ignorance and proceed.

Here are Ben’s comments:

Ben Armstrong
January 22nd, 2010 at 12:27 am

Hi Nick,

Just thought I would drop in to clarify some of the issues you raise around the issue of operating system support.

What we often talk about on the Hyper-V team is “Support versus support”. Hyper-V can run Windows NT 4.0 – and I would love it if we said that we support it, but we cannot say that – because Microsoft as a whole does not support Windows NT 4.0. And it really changes the story when you are the OS maker.

For example – let’s imagine that we did state that we supported Windows NT 4.0 on Hyper-V, and we compared the support experience between Microsoft and VMware:

VMware:

Customer encounters a problem with Windows NT 4.0 on ESX. They contact VMware – who after investigating the issue declares that “sorry – this is a bug in Windows NT 4.0, you should contact Microsoft”. When the customer contacts Microsoft they are told that Windows NT 4.0 is not supported. The customer still has a problem, but they do not feel lied to.

Microsoft:

Customer encounters a problem with Windows NT 4.0 on Hyper-V. They contact Microsoft – who after investigating the issue declares that “sorry – this is a bug in Windows NT 4.0, and even though we said we supported Windows NT 4.0 on Hyper-V we did mean that we supported Windows NT 4.0″.

Can you see why we (Microsoft) do not feel that we can make such statements? Meanwhile VMware currently states that they support every Microsoft OS from MS-DOS 6.22 onwards.

In regards to Linux support – when we state that we support a Linux distribution on Hyper-V, it means that we have signed formal support agreements with the owner of that Linux distribution. For example – if you have an issue running SuSE on Hyper-V, you can contact Microsoft product support. They will then work with Novel support engineers directly to solve the issue – without requiring you to bounce back and forth between the two companies.

As an aside – the problem with this approach is that it makes it hard to support versions of Linux like CentOS, where there is not a corporate entity who can sign a support agreement. That was one of the motivating points releasing our integration components under GPL – so that community supported distributions could provide the same level of support for Hyper-V as they provide for other platforms.

Cheers,
Ben

First off, thanks for the comments Ben. I appreciate your providing clarity and participating in a discussion

I completely understand the predicament around legacy Windows versions. Because of the dual ownership, Microsoft does have to maintain standards around support.

But, I disagree that at a higher-level this is a problem. I see this as the difference between strategic and tactical viewpoints with hypervisors (great post on this from Steve Kaplan here).
Here is an example:

Let’s say we have a customer that has 20 legacy servers running Windows NT 4.0.
They don’t have the budget to purchase replacement software, the original application creator is gone (and they didn’t have the source in escrow), and it is completely incompatible with new OS server versions.

With Hyper-V not only will they not be able to P2V (physical to virtual migration) these servers. They also would get zero support from Microsoft for Hyper-V hosts that encounter issues with these VM‘s. There is a built-in out for the support person on the other end of the phone. This translates into an implementation impossibility and extreme operational risk.

With VMware vSphere, not only is the P2V actually supported (allowing abstraction of the OS) but the VM’s themselves are supported on the hypervisor. That means if there is a specific issue with hypervisor configuration VMware will support, fix, and help with making this successful. I know people that have not only successfully virtualized legacy operating systems but, have also done it with extremely proprietary configurations (@tscalzott).

The hypervisor is a layer and a toolkit meaning the intent is to provide abstraction as well as options for business needs. Hyper-V is missing these options which, because of the tactical approach MS has, make it more limited in application. My points is the missing options and not an effort to downplay the features it does possess.

Microsoft’s (and your focus) on integrated support is because of the tactical approach to the hypervisor. Hyper-V it is built on the same platform as the server product and blends layers rather than abstracts. Support can be integrated but, in an abstraction model that is done successfully (empirically proven with VI3 & vSphere) this is not a critical need. When layers are abstracted you break the dependencies that exist in blended/tactical models. Integrated support is a core marketable value in tightly coupled dependency situations like hypervisor to storage, networking, and server components. In fact, that is one of the primary reasons VMware tightly maintains and accelerates their hardware compatibility list (HCL). Where abstraction does not exist this is essential and with vSphere is assumed by the ESX host. With Hyper-V the HCL is much broader because it is based on the underlying server operating system. But that is because Microsoft has abstracted hardware using the operating system (Windows Server). Problem is, that means all you have done is create another dependency upon a relocated layer. In fact if you think about it, the operating system with Hyper-V is now a layer above and below the hypervsior. This is a completely different approach to virtualization.

I am not saying Hyper-V has taken the wrong approach, I am just trying to clarify the real value of each product and the completely different approach. Microsoft has invested interest in businesses moving operating systems to newer Server version from a revenue perspective. Their motivation is inherit in their approach and marketing as evidenced by both the blog & your comments. Why would Microsoft invest major effort in reducing their ability to consume operation system market share?

On the other hand VMware’s interest in providing a extremely stable hypervisor with a robust feature-set that will work for as many possible deployment models as possible. They are successful despite the operating system choices of their customers. Being a customer I can testify that VMware support is extremely helpful in supporting guest OS’s on their platforms. While they won’t make changes application configurations (not stated at least), they do posses a massive knowledge base of how to successfully virtualize their long list of possible options.

However, in forward looking design scenarios Hyper-V does stand differently against newer Windows Server versions. With an apples to apples design using Windows Server 2008 and beyond, the battle is more over the cost, operational capability, and long-term value than support or compatibility choices.
Hyper-V does not have options that compete against VMware in heterogeneous operating system space and once you cross that line and make statements against operating system approaches, you have broadened the argument beyond an apples to apples comparison.

I really do appreciate the feedback and feel free to hit me back.

.nick