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.

Scalability Stats
One thing that hasn't changed in Windows Server 2012 R2 is the scalability of Hyper-V. That's because Hyper-V scalability increased so much in Windows Server 2012 that there was no need to boost it further. These are the scalability numbers for Hyper-V in both Windows Server 2012 and Windows Server 2012 R2:

  • 64 virtual CPUs (vCPUs) per virtual machine (VM) with full Non-Uniform Memory Access (NUMA) support
  • 1TB of memory per VM
  • 320 logical processors and up to 4TB of memory supported by the Hyper-V host
  • 64TB VHDX format
  • 64-node clusters
  • 1,024 VMs per host

These numbers allow more than 99 percent of the world's SQL Server workloads to run virtualized

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:

  • Customizable resolution
  • Clipboard access
  • Audio, drive, and printer redirection
  • Smart card and USB device access

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%\Roaming\Microsoft\Windows\Hyper-V\Client\1.0 with the name format vmconnect.rdp.<GUID of VM>.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:

  • The server policy Enhanced Session Mode Policy in the Hyper-V Manager server settings must be enabled and set to Allow enhanced session mode. This policy is disabled by default.
  • The Remote Desktop Services service must be running in the guest OS, although the Allow remote connections to this computer setting in the system configuration does not need to be enabled.
  • The user who is logging on must be a member of the local administrators or remote desktop users in the guest OS.
  • Out-of-box experience (OOBE) must be completed in the guest OS.

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:

  • Use a Multiple Activation Key (MAK).
  • Use a Key Management Service (KMS).
  • Use Active Directory-Based Activation (ADBA) for Windows Server 2012 and later domain-joined machines.

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":

  • Windows Server 2012 R2 Datacenter—Y4TGP-NPTV9-HTC2H-7MGQ3-DV4TW
  • Windows Server 2012 R2 Standard—DBGBW-NPF86-BJVTX-K3WKJ-MTB6V
  • Windows Server 2012 R2 Essentials—K2XGM-NMBT3-2R6Q8-WF2FK-P36R2

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:

  • Compression—This option is the new default and compresses the live migration data. Although this option consumes additional processor cycles on both the source and target Hyper-V hosts, it provides greatly improved live migration times.
  • SMB—This option leverages SMB Direct, a feature that takes advantage of Remote Direct Memory Access (RDMA)-capable network adapters. RDMA allows large amounts of data to be sent over the network with minimal resource usage by the host. Essentially, the network adapter is pointed to a block of memory and takes care of sending that block over the network; the host OS does not even consider network packets. This option provides the fastest live migration and uses the least amount of host resources but requires RDMA-capable network adapters.

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.")

Hyper-V Recovery Manager

Although not a feature of Windows Server 2012 R2, Hyper-V Recovery Manager provides a cloud-based orchestration service that can provide complete, automated failover services. These services include ordered failover of Hyper-V Replica replicated VMs but also run custom scripts and other actions. Hyper-V Recovery Manager works by connecting to System Center Virtual Machine Manager (VMM) installations at your data centers, to initially configure Hyper-V Replica between hosts and then to perform the failovers. No replication occurs via Hyper-V Recovery Manager, which is hosted in Windows Azure; the replication still occurs directly between the Hyper-V servers. Hyper-V Recovery Manager only provides the orchestration of failover processes. In addition, at the time of this writing, Windows Azure doesn't support Hyper-V Replica, so you can't replicate on-premise VMs to Windows Azure Infrastructure as a Service (IaaS). Hopefully, this feature will come soon; I hear many customers asking for it.

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.