9 Reasons Enterprises Shouldn't Switch To Hyper-V

In my job I'm privileged to help companies navigate virtualization challenges. Lately, more and more enterprise IT groups are asking about migrating to Hyper-V because of perceived significant cost savings, from a licensing perspective. I always expected that at some point I would have to address this question, but I thought that time would be two or three years from now.I am always amazed when a marketing machine is so fine-tuned, so elegant and effective that it can almost package and sell air. Microsoft's marketing machine is unsurpassed in the industry, and I mean that in the best of ways. Let's face it: Microsoft historically has been the underdog many, many times, but through smart marketing, aggressive pricing, and slow but steady improvement of its products, it emerges with the lion's share of the market. Remember the Apple "cold war" back in the day, the Netscape "browser war," the Novell directory and file server "incident," and the Lotus Notes "struggle"? Well, welcome to the virtualization "coup attempt."

Microsoft has a history of crushing its competitors in every space it decides to extend into, and virtualization seems to be a market it's adamant about dominating. But will it succeed? As an adviser to my clients, one of my obligations is to recommend software that is enterprise ready and can meet their requirements, and while Microsoft advertises Hyper-V R2 as having many enterprise features at a lower cost than VMware, the reality begs to differ. While Hyper-V R2 has closed the gap significantly with VMware vSphere, I don't think it's enterprise ready just yet, and I don't think that the advertised cost savings will materialize today given the migration costs, the loss of third-party support, and the loss of functionality. Here are nine points to consider before taking the bait of lower licensing costs.

1. Breadth of OS support Before we get into the nitty gritty, let's start with the most basic of features and simplest of tasks. Say you are an IT shop that supports more than just Windows servers; you have a mixed environment with different flavors of Linux and Unix. Hyper-V, however, supports only Windows and SuSE Linux. That's it. If I am to recommend an enterprise virtualization infrastructure, it would need to support a bit more than one flavor of Linux.

2. Memory management This one is always downplayed by the Microsoft folks, but to me, poor memory management is a show stopper, as it would significantly limit the density of VMs per host, even as the whole idea behind virtualization is to have a large number of VMs consolidated on a small number of physical hosts.

The Microsoft argument here is flat-out ridiculous. For starters, it recommends having a host in standby mode, which means, "Have a host that is not serving VMs running so that in the event of a host failure, the standby host can be used to cover for its martyred cousin." Really? One of the main driving factors behind virtualization is the efficient use of hardware, yet Microsoft expects us to put one or more hosts in standby mode?

As for memory oversubscription, Microsoft says we should just buy more memory; it's cheap, right? While we're at it, buy more hosts too, and you can attain the same level of VM density as you could with ESX. So, I get more hosts to manage, patch, cool, rack, and more memory? Why would I do that again? Thanks, but no thanks. I want to make my life easier, not harder.

But say you can accept the idea of buying more hosts and more memory. If you don't have memory oversubscription, how exactly do you expect to power-on VMs when a host experiences hardware failure? More physical hosts in standby mode?

Another scenario where memory management plays a significant role is in desktop virtualization; without memory oversubscription, the desktop virtualization model is unattractive.

3. Security Hyper-V's reliance on a general-purpose operating system, in this case Windows Server 2008, makes it a security vulnerability unto itself. In the past, if a security vulnerability was discovered for Windows, you had to patch all your machines, which were physically separated from one another. You had some time to patch before the exploit hit all your servers. If a Windows vulnerability exploited Windows Server 2008, however, that would jeopardize all the VMs that are running on it in one shot.

We see it as a security best practice to never use a general-purpose operating system to load your enterprise production VMs, for just this reason. Of course, this holds true for other virtualization vendors, not just Microsoft, but since Microsoft owns the lion's share of the OS market, it would be a continuous threat and just a matter of time before an exploit is found. Using a hypervisor that is different from the operating system leader isolates and stabilizes the hypervisor significantly. Moreover, the installation of Hyper-V, even in just the Windows 2008 core model, still consumes about 2.6 GB of disk, and while local disk is cheap, the larger the installation footprint, the bigger the attack surface becomes. ESXi is about 100 MB in size.

Hyper-V also supports and loads all drivers in the primary partition, and loads all memory in the primary partition. This is traditionally a cause for concern for Microsoft OSes.

I am by no means implying that Windows Server 2008 is not a secure operating system. It is definitely the most stable, most secure OS that Microsoft has ever released. But bear in mind that it comes with a healthy fan base of hackers all trying on a daily basis to show they are smarter than Microsoft. In my analysis, using vSphere as the hypervisor provides a layer of security and peace of mind. This is kind of the same method we used in security-conscious enterprises where two different antivirus software suites were deployed to provide a layered approach. If one suite did not catch malware, the other should.

4. Live Migration Contrary to popular belief, even geeks and technologists want to complete tasks in a timely manner so they can get home to their families, maybe even on time. Why would I want to deploy an infrastructure that would cause me to spend more time in front of my management console waiting for live migration to migrate 40 VMs from one host to another, ONE AT A TIME. That's right, Hyper-V R2 introduces Live Migration so you can move your VMs with no interruption, but the limitation is one VM at a time. Considering Microsoft's frequent weekly updates for Windows Server 2008, that would take an administrator double or triple the time it would an ESX admin just to move VMs from host to host in order to apply security patches and properly secure his deployment. Think about that in light of the security concerns mentioned earlier. When discussing the cost model, there has to be a way to attach a dollar amount to tasks completed faster. Live migration has to be able to do multiple simultaneous VM migrations; today it does not. Tomorrow? I am sure it will.

5. VM priority restart In a virtual world, I expect automation levels that far surpass what I had in my physical infrastructure. If you intend on running all virtual-and you should-the ability to prioritize your VMs by importance is crucial, and the ability to recover from host failures based on VM importance is even more crucial. In the event a host that is running 60 VMs fails, for example, I want to make very sure that my virtual infrastructure can restart my failed VMs on another host in a certain order. I don't want Exchange, SQL, and IIS to come up before my domain controllers, DNS server, or DHCP servers, for example. I don't want to do it manually, I like the flexibility of automation, and I expect it in a virtualized infrastructure. Sadly, Hyper-V R2 does not have that feature today, though again, I'm sure Redmond is working on it.

6. Fault tolerance This feature takes system availability to highs that are truly unheard of, and to no one's surprise, it is available only with vSphere. The ability to run a single VM in lockstep with a shadow VM simultaneously, executing on both primary and secondary VMs at the same time, provides for continuous high availability that we never had in the physical world with this much ease.

If the host supporting the primary VM fails, the secondary VM automatically and with no interruption in service will take over where the first one left off in a seamless manner. It will then create a new secondary for itself on another host.

These are features that enterprises cannot afford to ignore; these are features that are worth money. Of course vSphere will cost more, but how much more is a different story.

7. Hot adds In the physical days, we were always promised hot adds, but if most of you are like me, you probably never tried to add or remove physical memory more than once on a physical powered-on machine before you said, this is not worth it and way too risky. In a virtual environment, however, there should be no reason why we cannot add more memory, disk, and peripherals on the fly to any powered-on VM. Except if you're using Hyper-V.

8. Third-party vendor support It goes without saying that any enterprise-class infrastructure will always need third- party tools to extend its capabilities. However, when we examine the third-party tools that support Hyper-V and those that support vSphere, the gap is significant and swings heavily in VMware's favor. Will this also change at some point? I am sure it will.

9. Maturity The last thing I want to talk about is maturity of the product. When choosing a virtualization infrastructure, you are making a strategic decision about the basis upon which your organization's critical systems are going to run. It is a decision that will have far-reaching consequences; this is not some piece of software that you can just decide to change half way through the project. You want to make sure the platform has been field tested over time and that performance metrics exist that can show how the different enterprise applications function on it and whether these metrics will suffice for your environment.

I could go on for a while with enterprise features that are missing from Hyper-V, such as vShield Zones and others, but I think you get the point.

But Hyper-V Is So Much Cheaper! That is true, and no matter how much VMware tries to even it out with calculators and what have you, Hyper-V with its management server is less expensive. But Hyper-V also lacks many features vSphere has that save money, save time, and may well save business critical applications. When you weigh all this, the cost picture isn't nearly as straightforward. Now, we're not saying enterprise IT shouldn't bring Hyper-V into the lab and start testing. And, some smaller organizations will be able to get away with using Hyper-V in production, though everyone needs to be aware of security considerations. I have no doubt in my mind that Microsoft will eventually close the gap with VMware to the point that selecting a virtualization platform will be difficult. We're just not there today. Is your organizations prepared to make a strategic choice to deploy Hyper-V, accept the limitations, and wait for Microsoft to address these issues? Let us know what went into your decision.

Elias Khnaser is the practice manager for virtualization and cloud computing at Artemis Technology, a solutions integrator focused on aligning business and IT.