Windows Server 2012 R2 Hyper-V

With only a 1-year gap—which equates, realistically, to about 9 months of engineering time—between Windows Server 2012 and Windows Server 2012 R2, Microsoft had to make a decision. Should it make small changes across the entire spectrum of Windows Server features? Or should it focus on key scenarios and make meaningful changes to the technologies that are associated with those scenarios? Thankfully, Microsoft went in the second direction. One of these focus areas is the cloud. As a result, Hyper-V in Windows Server 2012 R2 boasts some significant enhancements and new features.

Although the scalability of Hyper-V did not warrant any changes for the Windows Server 2012 R2 release (see the sidebar "Scalability Stats"), several other areas benefited from enhancements. These areas include the core Hyper-V virtual machine (VM) format, activation and connectivity, virtual storage and networking, mobility and replication, and some nice new functionality that relates to Linux. This article focuses on the core enhancements and the mobility and replication changes; I'll cover the remaining features in a second article.

Generation 2 Virtual Machine Format

The Hyper-V VM base architecture had not changed significantly since its inception in Windows Server 2008. This architecture was based on the principle that the OSs running in the VM were not enlightened: They did not understand virtualization or virtualized hardware. Therefore, a certain set of emulated hardware needed to be present to enable the OSs to function.

Hyper-V integration services could be installed in guest OSs running in VMs, to enable the OS to understand native virtual hardware (e.g., the synthetic network adapter and SCSI controller) and to enhance performance. Those integration services eventually made their way into the core OS, and not just for Windows. The Hyper-V integration services are now a core part of the Linux distribution as well. Considering the native virtualization awareness of modern OSs, the initial principal that guided the VM format no longer applies; most emulated hardware is no longer required. Enter the Generation 2 VM.

The new Generation 2 VM format is for modern OSs. This format removes all the emulated hardware that was required for non-enlightened OSs. Gone is the PS/2-style emulated keyboard and mouse, the entire IDE controller, the legacy Intel emulated network adapter, the floppy disk drives and LPT ports, and many system devices, such as the PCI-to-ISE bridge and Pentium II Processor-to-PCI bridge. Instead, you are left with a lean VM that supports booting from the SCSI controller and Preboot Execution Environment (PXE) via the synthetic (standard) network adapter. Furthermore, the Generation 2 VM lets you dynamically resize the boot volume. Figure 1 shows the significant difference in Device Manager between the Generation 1 and a Generation 2 VMs. (For more information about the differences, see my video "Generation 1 vs. Generation 2 VMs.")

Figure 1: Generation 1 vs. Generation 2 Virtual Machine Hardware View

There is another major difference. Whereas a Generation 1 VM is BIOS-based, the Generation 2 VM is based on Unified Extensible Firmware Interface (UEFI) and enables features such as Secure Boot. However this change also introduces a potential issue, at least for those who want to upgrade a Generation 1 VM to a Generation 2 VM.

A BIOS-based installation has an NTFS-formatted system partition, whereas a UEFI-based installation has a FAT32-formatted Extensible Firmware Interface (EFI) system partition. Therefore, you can't just take the Virtual Hard Disks (VHDs) from a Generation 1 VM and attach them to a Generation 2 VM, which uses the VHDX format. (You can find out more in my video "Dynamic VHDX.") The only way to upgrade is to use a backup approach to capture the OS from the Generation 1 VM and then restore it to a new Generation 2 VM. Complications can still arise because of the changes in hardware and because the boot device is now a SCSI controller instead of an IDE controller.

Still, there is no major reason to worry about upgrading the VM format and no performance difference between the two. A Generation 2 VM installs and boots the OS faster than a Generation 1 VM does. But after the VM is booted and running, there is no real performance difference.

At the time of writing, the only supported OSs for a Generation 2 VM are 64-bit versions of Windows 8 and later and Windows Server 2012 and later. The Generation 2 VM has no Compatibility Support Module (CSM), which in a physical machine enables a BIOS emulation so that non-UEFI OSs can work. Therefore, non-UEFI OSs do not work with the Generation 2 VM.

Choosing which generation to use is fairly simple. If you need backwards compatibility with earlier versions of Hyper-V or Windows Azure, use the Generation 1 VM. If you do not need backwards compatibility and are using a supported OS, then go ahead and use the Generation 2 VM. Just be aware that you will need different VM templates for the Generation 1 and Generation 2 VMs because of the BIOS versus UEFI architecture.

Virtual Machine Live Cloning

Windows Server 2012 R2 includes a nomenclature change. What were previously called snapshots—point-in-time, saved states of a VM—are now called checkpoints. This change unifies Hyper-V and System Center Virtual Machine Manager (VMM).

Previously, there was no way to export a running VM or even a checkpoint (snapshot) of a running VM. This has changed in Windows Server 2012 R2 Hyper-V, which now allows you to export a running VM and a checkpoint of a running VM. This change is useful in several situations. For example, suppose that you are experiencing a problem with a VM and want to save the state of the problem environment just prior to rebooting or fixing the VM, to enable investigation later. Or suppose that you want to create a lab environment that is based on production but don't want to shut down production to do it. There is no change in process; you simply have the option to export a running VM or its checkpoints. In addition, you can export by using the Windows PowerShell Export-VM and Export-VMSnapshot cmdlets.

Enhanced Session Mode

To interact with a VM, you typically connect by RDP to the OS. This approach affords all the features that are available with the RDP protocol, such as clipboard, printer redirection, audio, display configurations, and more. However, sometimes you can't connect via RDP to a VM. Instead, you need to use the VMConnect option, which is available when you select the Connect action in Hyper-V Manager for a VM. This connection historically has been highly limited in its capabilities, with a set resolution and no device redirection or clipboard access.

Windows Server 2012 R2 Hyper-V introduces Enhance Session Mode for Windows 8.1 and Windows Server 2012 R2 VMs. This mode is possible because a re-architecture of the OS has moved parts of RDP into the VMBus architecture. With Enhanced Session Mode enabled, many RDP features are now available when using VMConnect to connect to a VM:

This mode provides a far richer VMConnect experience. I find the ability to paste from a shared clipboard invaluable.

Figure 2 shows the new connection window for VMConnect. You can configure the resolution and which local resources to make available. Note the Save my settings for future connections to this virtual machine option. If you select this check box, any saved configurations are written to %APPDATA%RoamingMicrosoftWindowsHyper-VClient1.0 with the name format vmconnect.rdp..config.

Figure 2: Enhanced Session Mode VMConnect Option Window

Even though many RDP features are made available, the connection is still considered an administrative connection and so a Remote Data Services (RDS) CAL is not required. In addition to requiring the installation of Windows 8.1 or Windows Server 2012 R2 in the VM, Enhanced Session Mode has these requirements:

Although not technically a feature of Enhanced Session Mode, the new Guest integration service, which is disabled by default, is part of the enhanced experience and worth a mention. When this new integration service is enabled, you can use the Copy-VMFile PowerShell cmdlet to copy files to a VM, without a network connection. This service is available only to Hyper-V administrators.

Automatic Virtual Machine Activation

VM activation has long been a pain point for many organizations. Complex problems can arise when a VM moves from your environment to another. Windows Server Datacenter allows an unlimited number of VMs to run the Windows Server OS, but you still need a way to activate them:

Windows Server 2012 R2 introduces Automatic Virtual Machine Activation (AVMA). As the name suggests, AVMA automatically activates any version of Windows Server 2012 R2 when running on an activated Windows Server 2012 R2 Datacenter Hyper-V server. The only necessary step is to use the AVMA key in the guest OS to tell the OS to use AVMA. These keys are listed in the Microsoft article "Automatic Virtual Machine Activation":

If you look at a Windows Server 2012 R2 VM in Device Manager, you will notice a Microsoft Hyper-V Activation component under System devices. Use this component to enable the activation communication.

Live Migration Enhancements

Windows Server 2012 introduced the ability to perform simultaneous live migrations between a pair of hosts. These migrations dynamically tuned themselves, based on the available bandwidth. All live migration traffic was sent uncompressed over the network, so depending on the size of the VM, a live migration could take a significant amount of time. However, the VM was available during the live migration, so time wasn't of the essence, unless you were waiting for the VM to be migrated from a host before shutting it down for maintenance or some other purpose.

Windows Server 2012 R2 introduces two new live migration configuration options:

If you have RDMA network adapters, then definitely select the SMB configuration option for live migration. Otherwise, use the default Compression option.

Windows Server 2012 R2 introduced another important live migration feature, considering the faster release cadence for Windows Server: cross-version live migration. Cross-version live migration enables a live migration from a Windows Serve 2012 Hyper-V host to a Windows Server 2012 R2 Hyper-V host. This capability means that there is no downtime for the VM during the migration process. This feature was a major request of Hyper-V users who didn't want any downtime, even during upgrades to Hyper-V.

Hyper-V Replica Enhancements

Hyper-V Replica enables an asynchronous replication of VMs from one standalone or clustered Hyper-V host to another. This feature is useful for disaster recovery. (For information about another useful Hyper-V failover feature that isn't specific to Windows Server 2012 R2, see the sidebar "Hyper-V Recovery Manager.")

Because of the asynchronous manner of the replication, a VM can be replicated between data centers, without any performance impact on the source VM. Hyper-V Replica replicates the VHDs of a VM and features several types of failover, including planned, unplanned, and test. There is also an option to inject an alternate IP address in the VM during failovers, as disaster-recovery locations typically use a different IP scheme from the primary data center. In Windows Server 2012, the frequency of replication is fixed at 5 minutes.

The original goal of Hyper-V Replica was replication between data centers. But several organizations used Hyper-V Replica within a data center; for example, to replicate VMs between Hyper-V clusters or between standalone Hyper-V hosts, where clustering could not be used. These customers wanted to be able to replicate more frequently than 5 minutes and to send another replica of the VM to a data center, which was not possible because a VM can have only one replica.

Hyper-V Replica in Windows Server 2012 R2 introduces two new features that help answer these demands. First, there is greater granularity for the frequency of replication, allowing replication to be configured to 30 seconds, 5 minutes, or 15 minutes. Second, you can extend replication.

Hyper-V Extended Replica enables the creation of a replica of a replica, as Figure 3 shows. Note that the extended replica has its own replication frequency. You still can't have more than one replica of a single VM; for example, a VM on server A can't directly send a replica to both server B and server C. But as Figure 3 shows, a replica can be sent from one server to another server, and then that replica VM can send its own replica to a third host.

Figure 3: Hyper-V Extended Replica in Action

This new extended functionality enables many additional scenarios. For example, you can now use replication within a data center, at a frequency of 30 seconds, and then send an extended replica to another data center at 30 seconds, 5 minutes, or 15 minutes. One important point: The extended replica cannot replicate more frequently than the primary replica. For example, if the primary replica replicates every 5 minutes, then the extended replica can replicate at an interval of 5 or 15 minutes but not 30 seconds.

That's Only the Half of It           

In this article, I focused on some core Hyper-V changes, but these make up only half of the new features. In the next article, I will continue this dive into what's new and great in Windows Server 2012 R2 Hyper-V. Many enhancements to other areas of Windows Server and System Center bring benefits to virtual environments and other scenarios, so take time to look at all aspects of Windows Server, System Center, and Windows Azure.