In-Depth

Microsoft, Citrix and VMware in Brewing Battle

The three companies are getting ready to rumble over ownership of the hypervisor cloud.

• By Danielle Ruest and Nelson Ruest
• 01/01/2009

Microsoft made its major virtualization announcement for the year, namely Hyper-V, on Sept. 8, just one week before virtualization's main event, VMware's VMworld. Citrix chose to release version 5 of its flagship hypervisor, XenServer, the day VMworld opened. Microsoft set up a Web site called www.vmwarecostswaytoomuch.com, printed the address on cards, attached $1 casino chips and handed them out at VMworld. Beleaguered VMware made considerable announcements at VMworld in Las Vegas in October.

What's the grand prize going to the winner of these wars? It's ownership of the "cloud," the name now given to the pool of host servers from where you can run virtual machines (VMs) in production environments. The cloud can be internal, based on the collection of host server resources, or external, where it relies on physical host server resources housed within virtualization service providers' (VSPs) data centers.

At VMworld, VMware CEO Paul Maritz even demonstrated how users could rely on their infrastructure to run VMs based on internal resources. Users could then, by launching additional VMs at a VSP site, automatically reach out to the external cloud when existing resources failed to meet service-level agreements.

Maritz, a former high-ranking Microsoft employee, reminded attendees that VMware pioneered x86 virtualization and still claims leadership in what continues to be a very profitable marketplace. But Citrix and Microsoft are hardly ready to call it quits. On top of that, other estimable players are gearing up for battle, including Virtual Iron Software Inc., Oracle Corp., Sun Microsystems Inc., Red Hat Inc. and Novell. Despite the market presence of these industry heavyweights, the market will hinge around three manufacturers:

• VMware, as it has a 10-year lead over all competitors
• Citrix, because it's well established in many organizations through its server-based computing products
• Microsoft, because it's the best established of the three due to the fact that most organizations run some form of Windows infrastructure.

So how do the "Big Three" stack up? Is VMware really too expensive, as Microsoft claims? Is Citrix the best 64-bit hypervisor available today? Will Microsoft convince a significant number of its existing customers to move with it into the realm of the dynamic data center? The only way to know is to look beyond initial costs and examine exactly what each hypervisor can do.

How the Hypervisors Stack Up
Each hypervisor has its own distinct feature set. VMware's ESX Server is at the core of its virtualization offerings. This 32-bit hypervisor comes in two formats: the actual ESX Server, which includes both the hypervisor and its management partition, or the trimmed-down, embeddable ESXi Server, which is as small as 32MB and can reside on an internal USB stick to be delivered with new hardware.

Citrix' XenServer is among the first 64-bit hypervisors and is based on the Xen extensions of popular Linux distributions. XenServer is also available in an OEM version.

Microsoft's Hyper-V is also a 64-bit hypervisor and is baked into the Windows Server operating system.

Hyper-V was the major reason Microsoft developed the Server Core version of Windows Server-a bare-bones version of Windows that doesn't include a graphical interface. Server Core is a must for Hyper-V because you want the hypervisor to draw a minimal amount of resources from the host hardware in order to provide as many resources as possible to VMs.

The smartest way to determine which hypervisor best suits your needs is to compare hypervisor features. Table 1 outlines the metrics that make each of the Big Three's hypervisors tick. All of the values have been drawn from public information produced by each vendor. As is obvious from the table, cost is not the only factor you need to consider when selecting a hypervisor. Use this table to determine how many VMs to run per host and how to configure hosts. Rely on these values to make an informed decision on how each hypervisor stacks up and which one you should use in your own network.

Table 1 Requires Some Caveats

• Because VMware uses an integrated hypervisor, ESXi, which has a very small footprint, its overhead is negligible. Both Hyper-V and XenServer require one Central Processing Unit (CPU) core to operate because they also include a parentpartition with the hypervisor.
  
  
• Of the three, Hyper-V supports the most host memory because it's based on Windows Server code. However, no physical host with 2TB of RAM currently exists.
• Each host requires some RAM for the hypervisor as well as some overhead RAM for each VM. In the case of VMware, VM overhead is 30MB plus 15 percent of the RAM allocated to a VM for each VM. Microsoft requires 32MB of RAM for each VM. Citrix calculates overhead as a percentage of RAM. And, in order to limit the host server RAM overhead in Hyper-V, you want to make sure you're running it on Server Core only.
  
  
• The maximum number of CPU sockets supported in host servers is calculated in the number of logical cores, normally a physical core, and addresses the maximum number of cores in certain server configurations. Note that Microsoft updated Hyper-V on Oct. 24, 2008, to support up to 24 cores in support of Intel Corp.'s new six-core processors. And, while XenServer states that it supports "unlimited" cores, this is only a factor of the enterprise license for the product. The actual number is limited to physical box configurations.
  
  
• The maximum number of virtual CPU cores per guest is often a factor of the guest operating system. In VMware, most guest OSes that support multiprocessing will support up to four virtual cores. The same applies to XenServer, but its guest OSes can run with up to eight virtual cores. In Hyper-V, the only multiprocessing OS that will run with four virtual cores is Windows Server 2008. Other supported versions of Windows Server will only access two virtual cores.
  
  
• Each hypervisor requires at least one management Network Interface Card.
  
  
• Pool or cluster numbers are limited by the functionality of the hypervisor. VMware supports pools through its High Availability and Virtual Machine File System features. Citrix has a built-in resource pool feature. Redmond relies on the Failover Clustering feature of Windows Server 2008, which is limited to 16 nodes in a cluster.
  
  
• Each hypervisor supports a maximum amount of RAM for guests; however, it's rare that organizations allocate the maximum to a guest OS because this doesn't leave a lot of memory for the host. Plus, allocating the maximum often creates what's called a "single-VM" host, or a host that runs only one VM. This is often cost prohibitive.
  
  
• The number of virtual processor cores per logical -- aka physical -- processor core usually equates to the number of single virtual processor core VMs you can run on a host. This number is often linked to the following value: Simultaneous Active Guests/Hosts. However, other factors such as available RAM limit the possible number of VMs you can run. Citrix XenServer has been configured with 32 cores and 50 VMs in the past. Microsoft and VMware have not announced hard limits for the number of VMs they can run, but VMware has an edge over both Hyper-V and XenServer because of its memory-management features. Because of these features, it's possible to over-commit resources to VMs on an ESX host server, assigning more resources to the VMs than are actually available on the host. Because of this, VMware supports Variable Resource VMs while the other two support only Fixed Resource VMs. In the Fixed Resource VM model, the hard limit for the number of VMs is memory, not CPU cores.

Each hypervisor has similar features as far as the numbers are concerned. But in real life, organizations will have a tendency to run more VMs in VMware than in the other two on similarly configured hardware. This is because of the resource over-commitment features it supports. After all, the main reason why organizations move to virtualization in the first place is because their physical server resources are underused most of the time.

So, creating a VM with a minimum and maximum resource setting makes a lot of sense. That way it runs with minimal resources at low loads and uses maximum resources during peak loads. However, for this to work, you must run a pool of servers with room to spare. This will let you move a VM to another host server when it requires more resources than are available on the current host. You would need an additional host in your resource pool, anyway, to support high availability for all of your VMs.

Also, host support for different OSes within guest machines is not the same among the different hypervisors. Table 2 lists the guest OS support for each hypervisor.

Note that Table 2 lists the supported guest operating systems. You can run unsupported guest OSes in hypervisors, but they won't perform as well as a supported guest. XenServer and Hyper-V support "enlightened" guests, or guests that know they're running on a VM and not on physical hardware. These guests will perform best on these hypervisors because they'll be able to directly address the VM bus provided by the hypervisors. VMware uses additions to make the guest OS work well with the hypervisor. Which works best? Enlightened guests or guests with additions? According to the manufacturers, each has the best model for guest OSes, but the proof is in the pudding. Running your own tests will help you make sure you know which works best.

VMware supports many more guest OSes than either of the two 64-bit hypervisors. It also supports more x64 guest OSes than the other two. But most importantly, VMware will do so on hardware that doesn't include hardware-assisted, virtualization-enabled processors. Try that with either XenServer or Hyper-V, and the hypervisors simply won't load. While this may not be important to you, you must be aware of these facts before you can make a decision on which hypervisor to implement.

Positioning the Products
Given the feature set of each hypervisor, it's obvious that each vendor has something to offer. All three are positioned to gain some level of market share.

Microsoft offers virtualization democratization; by integrating its hypervisor directly into its OS, Microsoft gives each of its customers access to server virtualization. Many shops will opt for this tool simply because it's easy to access and because they're already familiar with Windows Server. This will be very attractive to small or midsize shops.

Citrix, on the other hand, focuses on enterprise-virtualization scenarios and has access to a large customer base through its presentation virtualization, or server-based computing, toolset. In addition, organizations moving to desktop virtualization will find an interesting offering in Citrix's XenDesktop, which may further the adoption of XenServer. Shops using Citrix will often have to rely on third-party tools to create a completely dynamic data center, as it's currently trailing behind the other two in management tools.

VMware is still the market leader by far. Its offerings may seem to be the most expensive to purchase, but its hypervisor offers more physical server density because of resource over-commitment. If greening the data center is foremost on your mind, then VMware is the only choice to make because it offers higher numbers in terms of physical server consolidation. It also provides much more dynamic VM management through its support for variable resource VMs.

Don't get fooled by stories that outline just how expensive one hypervisor is compared to another. What counts is experience, stability and guest operating system density. When you begin to build your own internal cloud, you'll quickly discover that the best hypervisor is the one you can master in the shortest possible time frame. All vendors offer free virtualization technologies. Try them out in your lab, and see for yourself which one will run the most VMs and offer the best performance on a given set of hardware resources.