Virtualization is a major part of today’s data centers. The operating efficiencies offered by virtualization allow organizations to dramatically reduce operational effort and power consumption.
Windows Server 2008 R2 provides the following virtualization types:
Client and Server virtualization provided by Hyper-V™. Hyper-V™ virtualizes the system resources of a physical computer. Server virtualization allows you to provide a virtualized environment for operating systems and applications. When used alone, Hyper-V™ is typically used for server computer virtualization. When Hyper-V™ is used in conjunction with Virtual Desktop Infrastructure (VDI), Hyper-V™ is used for client virtualization.
Presentation virtualization. This type of virtualization provided by Remote Desktop Services’ RemoteApp (see below for more information on the Terminal Services’ name change in Windows Server 2008 R2) virtualizes a processing environment and isolates the processing from the graphics and I/O, making it possible to run an application in one location but have it be controlled in another. Presentation virtualization allows end users to run a single application, or a complete desktop offering multiple applications.
Note: There are other types of virtualization that are not discussed in this guide, such as application virtualization provided by Microsoft App-V. For more information on all Microsoft virtualization products and technologies, see the Microsoft Virtualization home page at http://www.microsoft.com/virtualization/default.mspx.
Improved Virtualization with Hyper-V™
Beginning with Windows Server 2008, server virtualization using Hyper-V™ technology has been an integral part of the operating system. Windows Server 2008 R2 introduces a new version of Hyper-V ™.
Hyper-V™ in Windows Server 2008 R2 includes three core areas of improvement for creating dynamic virtual data centers:
A simplified method for physical and virtual computer deployments by using .vhd files
Increased Availability for Virtual Data Centers
One of the most important aspects of any data center is providing the highest possible availability for systems and applications. Virtual data centers are no exception to the need for consolidation, high availability and most of all sophisticated management tools.
Hyper-V™ in Windows Server 2008 R2 includes the much-anticipated Live Migration feature, which allows you to move a virtual machine between two virtualization host servers without any interruption of service.
Live Migration uses the new Cluster Shared Volumes (CSV) feature within Failover Clustering in Windows Server 2008 R2. The CSV volumes enable multiple nodes in the same failover cluster to concurrently access the same logical unit number (LUN). From a VM’s perspective, each VM appears to actually own a LUN; however, the .vhd files for each VM are stored on the same CSV volume, as illustrated in the following figure.
Figure 3: Cluster Shared Volumes
Because CSV provides a consistent file namespace to all nodes in the cluster, any files stored on a CSV have the same name and path from any node in the cluster. CSV volumes are stored as directories and subdirectories beneath the ClusterStorage root folder, as illustrated in the following figure.
Figure 4: Example of single namespace in CSV
As illustrated in the previous figure, the CSV volumes (Volume1, Volume2, and Volume3) are stored in the ClusterStorage folder. If the ClusterStorage folder exists in the root of E:, the fully qualified path to each of the CSV volumes would be as follows:
All cluster nodes would access the shared volumes by using these fully qualified paths.
While CSVs are currently employed mainly for Live Migration, their benefits will extend beyond that single scenario. For one, they’re easy to configure using simple NTFS rather than some other proprietary format. That means administrators won’t have to reformat their SANs to take advantage of CSVs. It also means administrators will have an easier time showing users only a single data repository rather than a small forest of silos—no more drive letter metaphors for end-users just convenient networked storage. And last, CSVs don’t require config and management tools of their own. Windows Server administrators used to the tools in Windows Server 2008 can continue using those same consoles and they’ll simply work with CSVs in R2.
Because of the architecture of CSV, there is improved cluster node connectivity fault tolerance that directly affects VMs running on the cluster. The CSV architecture implements a mechanism, known as dynamic I/O redirection, where I/O can be rerouted within the failover cluster based on connection availability, as illustrated in the following figure.
Figure 5: Dynamic IO redirection for Cluster Shared Volumes
The first type of failure that can be redirected is the failure of a cluster node connection to the shared storage between cluster nodes, typically on a Storage Area Network (SAN). As shown in the following figure, if the SAN connection on Node 2 fails, the I/O operations are redirected over the network to Node 1. Node 1 then performs the I/O operation to the SAN. This allows you do a Live Migration of the VM running on Node 2 to Node 1.
Figure 6: IO connectivity fault tolerance for CSV
The next type of failure that can be redirected is the failure of network connectivity for a cluster node. As shown in the following figure, the primary network connection between Node 1 and Node 2 fails. Node 2 automatically reroutes network traffic over a redundant network connection and Node 1 performs the network I/O.
Figure 7: Network fault tolerance for CSV
The next type of failure that can be redirected is the failure of an entire cluster node. As shown in the following figure, Node 1 has ownership of a volume that is used by the VM running on Node 2. In the event of a complete failure of Node 1, ownership of the volume is changed to Node 2 without any interruption of service to the VM running on Node 2.
Figure 8: Node fault tolerance for CSV
Enhanced Cluster Validation Tool
Windows Server 2008 R2 includes a Best Practices Analyzer (BPA) for all major server roles, including Failover Clustering. This analyzer examines the best practices configuration settings for a cluster and cluster nodes. The test runs only on computers that are currently cluster nodes.
Improved Migration of Cluster Workloads
Administrators can migrate cluster workloads currently running on Windows Server 2003 and Windows Server 2008 to Windows Server 2008 R2. The migration process:
Supports every workload currently supported on Windows Server 2003 and Windows Server 2008, including DFS-N, DHCP, DTC, File Server, Generic Application, Generic Script, Generic Service, iSNS, MSMS, NFS, Other Server, TSSB, and WINS.
Supports most common network configurations.
Does not support rolling upgrades of clusters. (Cluster workloads must be migrated to a new cluster running Windows Server 2008 R2.)
Integration of Live Migration and Failover Clustering
Live Migration requires failover clustering in Windows Server 2008 R2. Specifically, Live Migration can make use of the new Cluster Shared Volumes (CSV) feature contained in Windows Server 2008 R2.
The following are the requirements for performing Live Migration with a failover cluster:
Live Migration can only be performed between cluster nodes within the same failover cluster. (Virtual machines can only be moved between cluster nodes.)
Hyper-V™ must be running on the cluster nodes in the failover cluster and have access to the same shared storage.
The .vhd files for the virtual machines to be moved by Live Migration must be stored on the same shared storage.
The following figure illustrates a typical Hyper-V™ and failover cluster configuration for supporting Live Migration.
Clients connected to the source virtual machine continue to run on the source virtual machine and create mirrored memory pages as illustrated in the following figure.
The mirrored memory pages are tracked and continue an iterative copy of the dirty memory pages until all memory pages are copied to the target virtual machine, as illustrated in the following figure.
Figure 11: Iterative copy of mirrored memory from source to target virtual machine
When all memory pages are copied to the target virtual machine, clients are automatically redirected to the target virtual machine and the source virtual machine is deleted, as illustrated in the following figure.
Figure 12: Final configuration after Live Migration completes
Even with all the efficiency gained from virtualization, virtual machines still need to be managed. The number of virtual machines tends to proliferate much faster than physical computers because machines typically do not require a hardware acquisition. Therefore, management of virtual data centers is even more imperative than ever before.
Windows Server 2008 R2 includes the following improvements that will help you manage your virtual data center:
Reduced effort for performing day-to-day Hyper-V™ administrative tasks by using the Hyper-V™ Management Console. The Hyper-V™ Management Console has been updated to reduce the amount of effort required to perform common day-to-day administrative tasks.
Enhanced command-line interface and automated management of Hyper-V™ administrative tasks by using PowerShell cmdlets.
Improved management of multiple Hyper-V™ servers in a virtual data center environment by using System Center Virtual Machine Manager 2008. For more information on System Center Virtual Machine Manager 2008, see “Microsoft System Center Virtual Machine Manager” at http://www.microsoft.com/systemcenter/virtualmachinemanager/en/us/default.aspx.
Historically, different methods have been used to deploy operating systems and applications to physical and virtual computers. For virtual computers, the .vhd file format has become a de facto standard for deploying and interchanging preconfigured operating systems and applications. Hyper-V™ in Windows Server 2008 R2 supports two important updates concerning .vhd files.
First, administrators can now add and remove vhd files, as well as pass-through disks attached to a virtual SCSI controller on a running VM, without requiring a reboot. This offers more flexibility when it comes to handling storage growth needs without requiring additional downtime. It also provides more flexibility in data center backup scenarios as well as new scenarios in complex Exchange and SQL Server deployments.
Windows Server 2008 R2 also supports the ability to boot a computer from a .vhd file stored on a local hard disk. This allows you to use preconfigured .vhd files for deploying virtual and physical computers. This helps reduce the number of images you need to manage and provides an easier method for test deployment prior to deployment in your production environment.
Windows Server 2008 R2 Hyper-V also introduces a new feature named Processor Compatibility Mode for live migration. This feature was implemented to expand customers’ options when it comes to live migrating VMs across different CPU versions from the same processor manufacture (e.g. Intel-to-Intel and AMD-to-AMD). Previously, any Live or Quick Migration operation had to be conducted across hosts with identical CPUs.
Processor compatibility is disabled by default, but can be activated either via the Hyper-V Manager or System Center Virtual machine Manager 2008 R2. It is most applicable to Hyper-V’s Live Migration (new with R2), but Quick Migration or standard Save/Restore operations can also benefit from it. Lastly, processor compatibility is supported by any Hyper-V-enabled CPU which supports hardware assisted virtualization; however, it is important to note that it supports migration only across CPUs versions in the same product family (ie, Intel-to-Intel or AMD-to-AMD). Cross-vendor CPU migration is not supported mainly due to differing instruction sets implemented by different CPU vendors.
Increased Performance and Hardware Support for Hyper-V™ Virtual Machines
Hyper-V™ in Windows Server 2008 R2 now supports up to 64 logical processors in the host processor pool. This is a significant upgrade from previous versions and allows not only greater VM density per host, but also gives IT administrators more flexibility in assigning CPU resources to VMs. The new Hyper-V also adds performance enhancements that increase virtual machine performance and power consumption. First, Hyper-V™ now supports Second Level Address Translation (SLAT), which uses new features on today’s CPUs to improve VM performance while reducing processing load on the Windows Hypervisor.
New Hyper-V™ VMs will also consume less power by virtue of the new Core Parking feature implemented into Windows Server 2008 R2. For detailed information on core parking, please see the “Reduced Multicore Power Consumption” section further down in this guide.
Improved Virtual Networking Performance
The new Hyper-V™ leverages several new networking technologies contained in Windows Server 2008 R2 to improve overall VM networking performance. Three key examples are the new VM Chimney (also called TCP Offload), support for Jumbo Frames and new support for the Virtual Machine Queue (VMQ).
VM Chimney allows a VM to dump its network processing load onto the NIC of the host computer. This works the same as in a physical TCP Offload scenario, Hyper-V™ now simply extends this functionality into the virtual world. This benefits both CPU and overall network throughput performance, and it’s fully supported by Live Migration.
VM Chimney is disabled by default in Windows Server 2008 R2, Combined with compatible hardware, currently including vendors like Intel, VM Chimney significantly reduces the host server’s CPU burden when dealing with VM network traffic. This translates into better host system performance and a simultaneous boost to VM network throughput.
Like TCP Offloading, support for Jumbo Frames was also introduced with Windows Server 2008. Hyper-V™ in Windows Server 2008 R2 simply extends this capability to VMs. So just like in physical network scenarios, Jumbo Frames add the same basic performance enhancements to virtual networking. That includes up to 6 times larger payloads per packet, which improves not only overall throughput but also reduces CPU utilization for large file transfers.
VMQ essentially allows the host’s single NIC card to appear as multiple NICs to the VMs by allowing the host’s network interface card (NIC) to DMA packets directly into individual VM memory stacks. Each VM device buffer is assigned a VMQ, which avoids needless packet copies and route lookups in the virtual switch. The result is less data in the host’s buffers and an overall performance improvement to I/O operations.