Microsoft Windows Server 2008 R2 SP1 Hyper-V
Microsoft has been playing catch-up with VMware and Citrix, with the current version of Hyper-V certainly stepping up to the mark as a strong contender. It is, however, a big installation; almost 3GB (or up to 10GB for the full server installation), whereas the other two use a Linux underpinning and happily reside on a CD (at least for the basic hypervisor).
Microsoft's approach is to install Windows Server 2008 R2, and then install Hyper-V as a Role, which is really quite a simple process. The Hyper-V Manager is easy to drive, and it has a simple and logical layout. Creating and configuring the VMs is also easy, and pretty much any operation you would want to carry out can be achieved via the manager. However, in a large cluster, Hyper-V Manager is simply not sufficient; you cannot automate or run tasks in a batch mode, so be prepared for lots of pointing and clicking.
To take the pain out of managing a large infrastructure, the Microsoft System Center Virtual Machine Manager (MSCVMM) is the way to go. It removes the need for repetitive tasks. The MSCVMM is, incidentally, also able to manage VMware's ESX Server.
Hyper-V is big on features, although in some instances it does lag behind the latest version of ESXi. For example, each host can have a maximum of 64 physical CPUs and 512 vCPUs, whereas ESXi supports a maximum of 160 logical CPUs and 2048 vCPUs per host.
VM virtual processor support is naturally dependent on the OS, but is limited to a maximum of four per VM.
Processor compatibility mode allows VMs to migrate across hardware, where the physical hosts can have different CPU architectures. This feature is new to Hyper-V; in the previous version, hosts had to contain identical CPU architectures, which meant that you could migrate across Intel to Intel or AMD to AMD hosts, but not Intel to AMD.
Physical memory per host is a healthy 1TB, but the maximum per VM is just 64GB. However, Hyper-V does feature dynamic memory, where the maximum and minimum RAM can be specified, and allocated memory can grow or shrink depending on the VM's needs. VMs can be assigned priority levels, so that when the host begins to exhaust physical memory, the RAM allotment to the VMs will be reduced based on their priority.
The size of a Hyper-V cluster is limited to 16 nodes in a failover cluster, with a maximum of 1000 VMs and a limit of 384 virtual nodes per physical machine. The maximum number of VMs allowable per node does not change, regardless of physical cluster size.
Guest OSes include Windows and flavours of SUSE, Red Hat and CentOS; other versions of Linux are unsupported, but many are reported to run without any issues.
High availability requires confirmation of the "Certified for Windows" test during implementation — largely requiring identical specifications for hardware nodes in both operating system varieties, CPU families and interfaces, such as networking and host adapters. Servers must also be members of the AD domain, necessitating a domain controller somewhere in the schema.
The "Live Migration" feature, enabled by the (new to Win2K8R2) Cluster Shared Volumes (CSV), recommends use of a private network for migration traffic. This is in addition to the private network requirement for internal cluster communication, separate virtual networking provision and separate storage network.
Virtual Networking follows the standard virtual switching approach, with the decoupling of the OS network stack to allow better throughput, although I/O performance will depend on the number of VMs attempting to communicate with the outside world.
For load-balancing services, the standard Microsoft Network Load Balancing (NLB) component is required, and is configured in the same manner as for physical nodes.
The inclusion of "snap shotting" via the Hyper-V Manager makes some inroads on the immaturity of the Microsoft product, which sports all of the features expected for taking, managing and redeploying snapshots to live VMs. While the possibility exists for automation via scripting in the snap-shotting feature, it is principally for use in test and development environments, and not ideal for a transactional production infrastructure — it certainly should not be considered as being the only disaster-recovery (DR) solution in a production environment.