If Hyper-V's easy availability and comfortable Windows-based management makes it a good fit for your business network, read on. Now in R2 with the release of Windows Server 2008 R2, Hyper-V includes the features and capabilities that a business needs to ensure high-availability of virtual machines (VMs). Clustering Hyper-V servers together atop Windows Failover Clustering enables Live Migration features that keep virtual machines running during planned outages. With the right architecture, that same clustering solution automatically rehosts and restarts VMs after a host failure. The result is the highest levels of virtual workload availability using hardware you likely have in-house.
In this guide on Hyper-V in Windows Server 2008 R2, we cover implementing Windows Server 2008 and Hyper-V as well as Windows Server 2008 best practices. Starting with a look at Microsoft Hyper-V installation, this guide helps you understand Microsoft Hyper-V requirements, smart solutions for Hyper-V implementation, and the features that make Hyper-V virtualization a compelling fit for IT environments of all sizes.
The Hyper-V Role in Windows Server 2008 R2
You've probably spent some time researching what's new in Microsoft's newest server operating system (
http://www.microsoft.com/windowsserver2008/en/us/whats-new.aspx). This new release includes several new features that enhance Windows Server 2008 R2's security and configuration, such as DirectAccess, BranchCache, BitLocker improvements, among others.
Of all these Windows Server 2008 R2 features, those for the Hyper-V role go far in bringing enterprise-worthiness to Microsoft's virtualization platform. But before digging too deep into the features that improve Hyper-V's high-availability, let's take a step back and consider some of the product's fundamentals.
If you've gone through the process of installing Windows Server 2008 R2, you already know that the Hyper-V installation is a post-installation activity. Unlike other virtualization solutions that install an operating system and a virtualization platform simultaneously, Hyper-V is an optional "role" that is added to an existing OS instance. (For more on how Windows Server 2008 roles provide compartmentalized functionality and aid in server provisioning, check out this summary (
http://windowsitpro.com/article/articleid/99274/q-what-are-the-server-roles-in-windows-server-2008.html.)
To install the Hyper-V role, start within the Server Manager console. This console loads by default for administrators as they log into the server console. It can also be launched from the command line with the command ServerManager.msc. Once launched, your first step is to install the Hyper-V role. Do so by right-clicking Roles in the left pane and selecting Add Roles. In the resulting wizard, click through to the screen titled Select Server Roles. Then check the box to install the Hyper-V role and click Next.
In the following screen, titled Create Virtual Networks, you'll be asked to select one or more network adapters for virtual machines. This selection attaches the network adapter to a virtual network switch, which is a software-based switch for connecting the virtual network adapters in your VMs to your physical network. Click Next followed by Install to install the role. The installation may require one or more reboots to complete.
Note that there are certain hardware prerequisites for Hyper-V to function correctly. First, Hyper-V can be installed only on 64-bit versions of the Windows OS. This requirement was an important consideration with Windows Server 2008 release to manufacturing version and was released in 32- and 64-bit versions. Today's Windows Server 2008 R2 reduces this consideration somewhat because the OS is available only in a 64-bit version.The second and third hardware prerequisites of Hyper-V are the support of the Data Execution Prevention security feature as well as processor-based virtualization extensions. These virtualization extensions for Intel processors (
http://www.intel.com/technology/itj/2006/v10i3/1-hardware/8-virtualization-future.htm) are commonly referred to as VT or EPT. For AMD processors, they can be AMD-V, AMD-NPT or AMD-RVI. Consult your server's documentation prior to installing the Hyper-V role to verify that your hardware will support Hyper-V's requirements.
Installing Hyper-V R2 and Hyper-V Server R2
Every Hyper-V installation requires a hard look at available hardware resources. You'll find that maintaining virtual machine performance is a constant task in a virtual environment. To that end, multiple solutions exist for creating Hyper-V hosts from Windows Server machines.
Windows Server 2008 R2 can be installed in one of two very different ways. Its "full" version installs the entire user interface as well as all the necessary code to run common Windows applications. R2's Server Core version (
http://technet.microsoft.com/en-us/library/cc753802%28WS.10%29.aspx) differs in that it installs only a bare minimum installation of the operating system. That minimum installation relies on a command shell rather than a fully-featured graphical user interface for its configuration and management activities.
Organizations can benefit from this dramatically smaller instance for many reasons: Smaller means less code, which means more security. Smaller also means that the OS uses fewer resources, leaving more resources for installed applications. This slimmed-down operating mode fits perfectly with Hyper-V's often heavy resource needs.
The Hyper-V role can be installed to either the "core" or the "full" version of Windows Server 2008 R2 (
http://www.microsoft.com/windowsserver2008/en/us/r2-compare-core-installation.aspx), with each installation being somewhat different in the steps that are required. Installing Hyper-V to a "core" instance of Windows Server 2008 R2 requires some skill with the command prompt. But, once installed, implementing and managing Windows Server 2008 Hyper-V becomes easy. If you want to squeeze as many Hyper-V VMs out of your existing hardware, here's a set of Hyper-V tips for "core" that'll help you get started:
•Install an instance of Windows Server Core to available hardware. Note the use of the command prompt to complete the installation and initial configuration of the OS.
•Windows Server 2008 R2 now includes a command-line Server Configuration tool that will assist with this initial configuration. Launch it with the
SConfig.cmd command. Once launched, common configuration activities such as configuring networking, naming, adding the computer to a domain, and setting Windows Update settings can be accomplished through its textual menu.
•Once the initial configuration of the server is complete, install the Hyper-V role using the command dism /online /enable-feature / featurename:Microsoft-Hyper-V.
•This installation installs Hyper-V's server components. Managing that installation is done with the graphical Hyper-V management tools on your desktop. Those tools are a part of the Windows Vista and Windows 7 Remote Server Administration Tools, which can be downloaded from Microsoft's website.
This use of Windows Server Core as the foundation for Hyper-V is useful for licensing reasons as well. Among the new Hyper-V R2 features, Microsoft has enhanced the completely-separate-but-similarly-named product called Hyper-V Server. Hyper-V Server arrives as a preconfigured installation of Windows Server Core that is limited to running just the Hyper-V role. This special edition of Hyper-V is important because Microsoft makes it available as a free download with no requirements for licensing. This means that using it costs you absolutely nothing.
With its R2 version, Microsoft has also changed the capabilities available in Hyper-V server. This new version now includes full support for Windows Failover Clustering, as well as all the other major features available in the "regular" version of Hyper-V atop Windows Server 2008 R2 Enterprise Edition including the all-important Live Migration feature.
System Center Virtual Machine Manager 2008 R2
An installation of Hyper-V alone can be managed using the Hyper-V Manager console. This console enables administrators to work with individual instances of Hyper-V, creating virtual machines and virtual networks, interacting with those virtual machines, and doing the central tasks of VM management.
But the native Hyper-V Manager console suffers from a limitation: It works with only one Hyper-V server at a time. When your number of Hyper-V servers goes much beyond a single server, you may quickly find the Hyper-V Manager console to be limited in the features it provides.
System Center Virtual Machine Manager (VMM) is Microsoft's solution to this management limitation. This System Center product arrives as a solution that layers on top of your entire Hyper-V infrastructure. Sitting logically on top of every Hyper-V server at once, VMM can manage each virtual machine in a group. Using this solution, you can define configurations on multiple machines, work with virtual machines no matter where they are hosted, and quickly build and deploy virtual machine templates from VMM's built-in library.
System Center Virtual Machine Manager also offers features such as physical-to-virtual server (or P2V) migration and virtual-to-virtual (or V2V) server migration capabilities. These tools provide for the conversion of physical machines to Hyper-V VMs. They can also convert VMs that are hosted atop VMware ESX hypervisor to Hyper-V's .Virtual Hard Disk format. VMM also operates as a multiple-hypervisor solution, managing Hyper-V hosts alongside ESX hosts through the same console.
When connected with an instance of System Center Operations Manager, VMM gains can monitor and react to virtual machine behavior. Performance and Resource Optimization (PRO) tips are a feature of this integration. These tips alert administrators with actionable intelligence on when virtual machines should be migrated, turned off, or other activities should be taken based on VMs' real-time behavior.
Adding VMM also brings a set of important System Center security features. While it is possible to configure roles and permissions in Hyper-V alone, the process using the Windows Authorization Manager (or AZMan) is complex and scoped to only a single host at a time. Conversely, roles and permissions in VMM are configured through an easy-to-use graphical interface that can manage multiple machines at once, ensuring that security settings are cohesively set across your entire infrastructure.
Using VMM requires an additional purchase on top of the licenses used for Hyper-V; however, its widespread management reach makes it a must-have for environments who desire to use Hyper-V in anything but the smallest of environments.
Hyper-V Live Migration
Running virtual machines atop a Hyper-V host is great for optimizing your physical resources. Without virtualization, many Windows servers use only a mere portion of the hardware resources they're assigned. This means it is very likely that you're buying hardware that never gets used. Hyper-V changes all that by enabling many virtual machines to share a single host.
But while that sharing of resources means better optimization, it also presents the potential for greater loss when those hosts go down. If you've got 10 virtual machines running atop a Hyper-V host, losing that host means losing 10 of your business's critical services.
That's one of the reasons why Live Migration exists. Its process of migrating virtual machines allows an administrator to relocate VMs before having to take down a host for maintenance, patching, updates, or other work. Correctly configured, those same server migration tools can automatically reboot virtual machines onto surviving equipment after an unexpected Hyper-V host failure.
For the new virtual administrator, the under-the-covers actions during this live virtual machines migration process are not well understood. When you click to migrate a virtual machine, what actually gets transferred from one host to another?
First, using Live Migration requires the installation of the Windows Failover Clustering feature to each participating Hyper-V host. This service creates a multinode cluster between each host and installs the components that watch for failure, arbitrate for VM ownership between nodes, and generally ensure that Live Migration can occur.
The other piece that must generally be in place is an area of shared storage that can be accessed by each Hyper-V host in the cluster. This shared storage can be connected via Fibre Channel host bus adapters or through iSCSI connections using traditional network interface cards. In either case, it is most often created as an exposed LUN from a locally-available storage area network (SAN).Live Migration transfers the memory and running state of the virtual machine, but not its disk files. These files remain on the central shared storage and do not move during the Live Migration process. Using this process, the ownership of a virtual machine can be transferred in a small number of seconds and without impacting the operation of the virtual machine.
Once created and properly connected, the Windows Failover Clustering feature on each Hyper-V host then works with the others to monitor running virtual machines. At any point, an administrator can click within either the Failover Cluster Manager console or via the System Center Virtual Machine Manager (VMM) console to migrate running virtual machines from one host to another.
Cluster Shared Volumes
Cluster Shared Volumes is a feature that is newly available in Hyper-V R2 that improves the operational management of Hyper-V VMs. While not intended to improve server cluster performance, this new feature makes it possible to fail over individual virtual machines from one host to another when their disk files are colocated on the same storage volume.
It is easiest to explain this important feature by first discussing how cluster resources work within Windows Failover Clustering. A Windows Failover Cluster itself exists as two or more cluster "nodes" on which the Windows Failover Cluster service has been installed and configured to operate as a cluster.
Once created, a cluster can then host any of a set of cluster resources. Those resources can be services and applications such as a DHCP server, a file server, or a Hyper-V virtual machine. Within each service or application are additional resources that enable the service or application to do its job: For example, a file server resource might include "network name", "IP address", and "physical disk" resources. Among those resources, dependencies are created to identify which resources depend on which other resources. In this example, the network name might have a dependency on the IP address. As such, if the IP address fails, so will the network name, and ultimately the file server resource itself.
Within this architecture lies the problem with Hyper-V R1: This original version was only capable of failing over a physical disk resource all at once. This means that when a virtual machine needed to be failed over from one node to another, any other virtual machines which shared its physical disk would be failed over at the same time.
The net result was that this configuration made it operationally difficult to install multiple virtual machines to a single attached disk. As a workaround, Microsoft's recommendation with Hyper-V R1 was to create one physical disk per virtual machine and manage them as individual units. This practice created additional work for storage administrators, required the creation of large numbers of small-sized SAN disks, and ultimately complicated the use of Hyper-V in a clustered environment.
Cluster Shared Volumes eliminates this problem by making the cluster aware of the individual files within a physical disk resource. By enabling Cluster Shared Volumes, the cluster gains the ability to fail over individual virtual machine .VHD files rather than the entire physical disk at once. This change now enables administrators to create smaller numbers of very large physical disks with the goal of storing multiple virtual machines on each disk.
Cluster Shared Volumes is not enabled by default, and must be specifically enabled for this feature to work. It can be done by right-clicking the Cluster Shared Volumes node in the Failover Cluster Manager and selecting Add Storage. In the resulting wizard, select the storage you wish to enable. Be aware that Cluster Shared Volumes is currently only supported for use by Hyper-V virtual machines.
