vTeardown

vSphere over Hyper-V: create 8 vCPU VMs for any of the 55 vSphere supported OSs. Hyper-V supports only up to 4 vCPUs and then only for Windows Server 2008 and Windows 7

vSphere currently supports 55 guest operating systems – maximum flexibility for deploying applications in a virtual environment

On the guest operating system support side, VMware ESX supports far more guest operating systems than any other bare-metal virtualization platform. In fact, VMware supports 55 different OSs ranging from Windows, OS/2, Solaris, and even NetWare (yes, a lot of people still use NetWare!) Visit the online VMware Compatibility Guide and you’ll see that ESX4 supports over 460 versions of those 55 OSs:

vSphere VMs scale up to 8 vCPUs and 255 GB of RAM – maximum scalability to take advantage of today’s hardware

What’s even more exciting is that for each one of those 460 versions of the 55 supported guest operating systems, ESX enables up to 8 virtual CPUs. Be it Windows or Linux, any ESX4 VM can be configured to have 8 vCPUs along with 255GB of RAM—the exception being Windows XP and Vista, which has an OS limitation of 2 vCPUs even when running natively on physical (Hyper-V on the other hand only supports up to 64GB of VM RAM). With this support, maximum throughput achievable from a single VM is much higher in ESX4 than in previous versions.

ESX4 even allows one to configure vCPUs in odd numbers such as 3, 5, or 7 if one chooses. This ability allows application workloads to be configured with the most flexibility:

Hyper-V limits choice, treats Linux VMs as second-class citizens and doesn’t scale to the full potential of today’s hardware

In contrast, Microsoft Hyper-V has a much smaller guest OS support list along with very limited vSMP support. Take a close look at their guest operating system support list and you’ll notice Windows 2008 and Windows 7 VMs are limited to only 1, 2, or 4 vCPUs. In addition, Hyper-V Linux VMs are hindered by only 1vCPU. Don’t even try running SAP on a Linux VM under Hyper-V because it’s NOT supported! SAP does not even plan to evaluate this type of combination for their applications. On the other hand, ESX has supported SAP in both Windows and Linux VMs since 2007.

In addition to Linux, legacy systems, even Windows legacy systems, are also treated as second-class citizens. Where’s the 4 vCPU support for Windows 2003? Or how about 2 vCPU support in Windows 2000? Can’t do it on Hyper-V!  Could Microsoft be limiting support for legacy Windows systems to “encourage” upgrades to newer OSs? Hmm – VMware does not have that type of conflict of interest. ESX4 does a better job at running Windows OSs than Microsoft by supporting practically every Windows version since 3.1 and even MS DOS 6.22! Alright, I know we don’t support Windows ME (Mistake Edition), but then again, who’s willing to admit that they’re running the worst OS of all time?

The Bottom Line

Virtualization should not be used as a vehicle to influence a customer’s choice of guest operating systems or when they should do an operating system upgrade. VMware strives to support guest operating systems as consistently and equally as possible. On the other hand, Microsoft’s preferential treatment of Windows Server 2008 and Windows 7 pressures companies to deploy these OSs in order to get the full benefits of Hyper-V. If a guest OS doesn’t generate any revenue for Microsoft, it most likely won’t show up on their guest support list. Do you think Solaris will ever make the list?

With the introduction of 6 core CPUs and with 8 cores just right around the corner, customers need a virtualization platform that can take advantage of the increased processing power. VMs under ESX4 does just that with support for up to 8 vCPUs and 255GB of RAM. On the other hand, Hyper-V comes up short and is not yet enterprise-ready, as noted pointedly by Burton Group.

Business Continuity is a Highly Valued Virtualization Function

Among the primary reasons why companies virtualize their applications is to improve business continuity – or in other words to make all applications as available as possible, as often as possible. Actually, we are now seeing a lot of customers value this virtualization capability even more than server consolidation. With vSphere, there are several established methods available to improve application availability; it all depends on the type of failure you want to protect against and the amount of downtime one can tolerate. For this post however, we’re going to examine VMware vSphere High Availability and a very helpful, vSphere exclusive, feature that enables an organization to prioritize which VMs restart first in the event of a hardware failure – pretty interesting stuff.

VMware HA Enables Unheard of Levels of Application Availability

As we all probably know by now, VMware HA has been a widely adopted solution to minimize application downtime in case of server failure. Once HA has been enabled on a vSphere cluster (directly from vSphere Client with just a few clicks), vSphere will continuously monitor the status of all VMs running in a specific cluster. Should a host failure occur, vSphere will then automatically restart the affected VMs on a different host, greatly reducing application Recovery Time Objective (RTO). With vSphere 4 we have extended the capabilities of VMware HA to enable automatic VM restart in the case of a guest operating system failure. So now, even if the hardware is fine, but a single virtual machine’s operating system fails, that application will restart. That is pretty good!

vSphere Exclusive Feature – Prioritize which Applications Restart First

That’s a cool advancement, but in terms of HA triggered by a server failure, we still felt that we needed to do better, because all applications on a host aren’t equal are they? The ability to prioritize mission critical apps to recover first, before tier-2 applications, could result in a lot of benefits to an organization. That ability could save a lot of money, could limit revenue loss, and could even protect a company’s reputation. Consequently, a primary objective of HA should be to further minimize the cost of downtime by prioritizing the restart of mission critical applications. Well, vSphere 4 has a solution for that – with vSphere, one can easily configure a failover restart prioritization level of a VM. It only takes a mouse click – or three.

By setting the failover restart priority level of a VM to “High”, vSphere will make sure the VM is restarted before those with a “Medium” or “Low” priority. Even better, the failover restart prioritization is a VM attribute, independent from the host, and will follow the VM even if you migrate it or restart it on a different host in the cluster.

This Feature Does Not Exist in Hyper-V R2

Even with Windows Server 2008 R2, it appears that Hyper-V won’t provide failover restart prioritization capabilities. Yes, with Microsoft Clustering Services, one could make a VM highly available – but when it comes to prioritizing VMs for restart, the user is really left with three insufficient alternatives:

1) Forget about automated VM restart and go back to manual restart – sounds fun…others have already written on this limitation

2) Spend time and effort creating and maintaining scripts for prioritized restart – this option sounds like a management nightmare considering that scripts would have to be updated every time a new VM is created or migrated to a different host

3) Run fewer apps per server so that you reduce the risk of extending the RTO of mission critical apps – but that increases the overall TCO of your virtualization infrastructure as you are then using more physical servers.

Or you could challenge Murphy’s Law and hope for the best. Yes, I am biased, but I think you’d agree that 1) The ability to prioritize VM restart in the event of failure is an important, valuable capability and 2) A single click in the vSphere console to prioritize VM restart beats any of these Hyper-V alternatives.

Protecting your VMs from NIC failure is really easy with vSphere. Any edition of vSphere (even free ESXi for that matter) provides built-in NIC teaming capabilities which can be easily configured in just few clicks directly from vSphere Client.

NIC teaming policies can be set for any of the supported networking cards (over 450 models) and allow users to configure multiple active and standby adapters. Teaming configurations can vary per port groups on the same virtual switch and uplinks.

Microsoft Hyper-V R2 will still not have integrated NIC teaming, instead relying on third-party NIC drivers to provide the functionality. The issues with the third-party approach are: 1) the drivers only work with NICs from that same third-party, 2) it requires a separate installation (and often other crazy stuff as vCritical showed in this blog post), and 3) it is unclear whether Microsoft or the third-party provides support should an issue arise.

Managing NIC teaming Hyper-V servers can quickly become a painful and time consuming activity. Besides having to install third-party drivers on each server, teaming will have to configured and managed locally on each server using the third-party management tool (like the HP Network Configuration Utility in the image below) that is not aware of your virtual switch configurations.

This is if you decide to enable Hyper-V on a full Windows Server 2008 installation, bringing the over 10GB of bloated Windows code base and all its security and patching related pains in your virtualization stack. Should you instead decide to follow Microsoft’s recommendation and enable the Hyper-V role on Windows Server 2008 Server Core deployment or use Hyper-V Server (i.e. Windows Server 2008 Server Core with Hyper-V enabled) in an attempt to reduce that code base to “just” 3-4GB, well, make sure to cancel your dinner plans and allocate few more hours to setup teaming via command line!… but, hey, that’s the “Windows you know”.

Built-in NIC teaming isn’t the only aspect that vSphere does better than Hyper-V when it comes to networking management. Directly from the vSphere Client users can also set up policies for networking load balancing, layer-2 security and networking traffic shaping.