In-Depth
First Look: Microsoft Hyper-V Gets a Major Overhaul
The Windows Server 2012 R2 Preview includes major improvements to the Microsoft hypervisor.
When Microsoft created Windows Server 2012, the company provided a much-needed overhaul to its Hyper-V hypervisor. The improvements made in that version of Windows finally made Hyper-V a viable choice for the enterprise.
Not content to rest on its laurels, Microsoft is making even more dramatic improvements to Hyper-V in the forthcoming Windows Server 2012 R2, which Microsoft released to beta last month. Having looked at the new Preview, I'll discuss some of the more noteworthy improvements to Hyper-V in Windows Server 2012 R2.
Generation 2 VMs
One of the biggest new features in Hyper-V is the introduction of Generation 2 VMs. Generation 2 VMs add capabilities that were previously unavailable on Hyper-V VMs, such as support for SCSI boot and Pre-Boot eXecution Environment (PXE) boot. Also, because Generation 2 VMs use Unified Extensible Firmware Interface (UEFI) instead of BIOS, they're able to perform secure boots from GUID Partition Table (GPT) disks.
The New Virtual Machine Wizard now contains an option that lets you choose between creating a first- or second-generation VM. You must specify a VM's generation when it's created. A VM can't be upgraded to a Generation 2 VM later on.
Published reviews of Generation 2 VMs have been almost entirely positive so far. In my opinion, however, Generation 2 VMs are something of a double-edged sword.
On the one hand, they provide plenty of benefits: They do away with hardware emulation, and the guest OS is consciously aware that it's running on virtual hardware. In fact, a quick peek at the Device Manager reveals that most hardware is seen as "Microsoft Hyper-V" or "Microsoft Virtual" hardware (see Figure 1). The removal of hardware emulation allows VMs to run more efficiently, so there's a noticeable decrease in the amount of time it takes to install and boot VMs.
[Click on image for larger view.]
Figure 1. The guest OS is aware that it's running on virtual hardware.
On the other hand, one of the nice things about server virtualization has always been that it eliminates inconsistencies in underlying hardware. For example, I have several consulting clients who are running mission-critical software on extremely outdated OSes such as Windows 2000 or even Windows NT Server. One of the biggest problems with doing so is that these ancient OSes have trouble coping with modern hardware. As such, I know of at least two organizations that, until relatively recently, were running Windows NT Server on extremely old hardware that had become increasingly unreliable.
Virtualization gave these servers a new lease on life. Virtualization made it possible to run an ancient OS on modern hardware. Just as importantly, these VMs were able to run alongside other VMs that were running modern OSes. All of the VMs could be collectively managed regardless of the OSes they were running.
Generation 2 VMs do away with this flexibility. A Generation 2 VM can only run 64-bit editions of Windows Server 2012, Windows Server 2012 R2, Windows 8 or Windows 8.1. For the first time, Microsoft has placed limits on the OSes that can run within a VM.
Keep in mind that these limits only exist for Generation 2 VMs. It's still possible to create a Generation 1 VM and run anything you want in it. However, there are two issues that could eventually come about as part of Microsoft's decision to generationalize VMs.
First, VM management could eventually get complicated. There may come a day when virtualization administrators have to be able to tell the difference between a Generation 4 and a Generation 6 VM, and need to keep track of the capabilities and limitations of each version.
Second, and more important, I can't help but wonder how long before Generation 1 VMs are eventually deprecated and ultimately removed completely from Hyper-V. If and when that day comes, it will become impossible to run older OSes within a VM.
For right now, though, those issues are nothing but speculation on my part. I think Generation 2 VMs should be treated as what they are -- a way to run modern OSes more efficiently while providing capabilities that aren't available to older OSes.
VHDX Resizing
In Windows Server 2012, Microsoft introduced the new VHDX virtual hard disk (VHD) format. This new format provides the ability to create much larger VHDs than were previously possible, among other benefits.
The VHDX format is alive and well in Windows Server 2012 R2, and Microsoft has added to its capabilities. It's now possible to extend or compact a VHDX-based VHD while it's running. You can even make changes to the size of a VM's boot disk.
It's worth noting that this feature is only available for Generation 2 VMs. In Figure 2, you can see the Settings screens for two separate VMs. The Edit button is grayed out for VM2, which is a first-generation VM. However, the Edit button is available for VM1. Both VMs are running.
[Click on image for larger view.]
Figure 2. You can extend or compact a VHDX-based virtual hard disk on a Generation 2 VM while it's running.
Replication Improvements
Without a doubt, my favorite feature in Windows Server 2012 Hyper-V is VM replication. This allows a VM to be replicated to an alternate host server on an ongoing basis. Replication doesn't provide the automatic failover capabilities of failover clustering, but it does provide a redundant VM copy that can be used in the event that something happens to your primary host server. Hence, replication is more of a recovery solution than a fault-tolerant solution.
Microsoft did a great job on the replication feature. It works extremely well and is easy to set up, and it's a solution that can be put into place with minimal costs (which makes it attractive to small and midsize businesses that may lack the budget or expertise to deploy a failover cluster). The original replication feature was so good, in fact, that I didn't expect Microsoft to make any enhancements to it in this release. But there are at least two noteworthy improvements to Hyper-V replication.
First, you can now control the replication frequency. In the previous release, replication occurred every five minutes. This threshold is now adjustable. Replication can occur as quickly as every 30 seconds, or Hyper-V can wait for as long as 15 minutes between replication cycles.
Another notable improvement Windows Server 2012 R2 brings to Hyper-V is it's now possible to replicate a VM to two replica servers. This means organizations can have an on-premises replica and an off-premises (possibly even cloud-based) replica.
Storage QoS
When you create a Hyper-V VM, you allocate specific hardware resources to it. These allocations work as a cap to prevent the VM from consuming more hardware resources than have been provisioned.
Although Hyper-V has always allowed administrators to carefully control resource allocation, there's one area in which resource control has been severely lacking. Up until now there was no direct way to cap the amount of disk I/O that a VM could produce. Administrators who wanted to limit a VM's I/O usually either placed the VM into isolated storage where it couldn't interfere with other virtualized workloads, or they used external solutions to limit disk I/O.
Windows Server 2012 R2 Hyper-V finally makes it possible to limit a VM's disk I/O through a new feature called Storage QoS. If the acronym QoS sounds familiar, it's because it typically refers to a networking standard called Quality of Service. In networking, QoS is used to either limit or reserve bandwidth for a specific application.
Storage QoS can be used to either ensure a VM receives the IOPS it needs, or to limit the total IOPS the VM can produce. Best of all, this feature is set on a per-VHD basis. This gives administrators flexibility to place limits or reservations where they're most needed.
You can access Storage QoS settings by opening a VM Settings page, expanding the listing for a VHD and clicking on Advanced Features. You can set a minimum and maximum threshold value for IOPS (see Figure 3).
[Click on image for larger view.]
Figure 3. You can limit a virtual hard disk's IOPS through Storage QoS.
VHD Sharing
Prior to the release of Windows Server 2012, if you wanted to build a Windows-based failover cluster, you had to use shared storage. Doing so meant connecting each cluster node to physical storage by means of Fibre Channel or iSCSI connectivity. Microsoft did away with the requirement for shared storage in Windows Server 2012, but continues to recommend its use whenever possible.
Virtual hard disk sharing (grayed out in Figure 3) lets you treat a VHD as shared storage. VMs operating as guest cluster nodes can connect to the shared hard disk using SCSI persistent reservations. By doing so, it becomes possible to build a guest cluster that's based on shared storage without actually having to build a dedicated cluster shared volume on the underlying SAN. Shared VHDX files do have to reside on shared storage, so they don't eliminate the need for physical shared storage. However, they do make it possible for someone to build a guest cluster without needing low-level storage provisioning capabilities. As such, shared VHDX will prove useful in multi-tenant environments.
Guest cluster nodes that rely on virtual hard disk sharing can be live migrated to alternate Hyper-V hosts without losing storage connectivity. However, storage migrations are rumored to be unsupported for virtual hard disk sharing.
Live Migration Compression
Microsoft has taken steps to make live migration faster. This is especially useful for cluster-aware patching, which requires VMs to be live migrated to an alternate Hyper-V host to facilitate patching.
Microsoft offers two options for speeding up live migration. One option is to enable live migration over Server Message Block (SMB). This option is only appropriate for organizations that have high-end networking hardware. Features such as SMB Multichannel allow live migrations to use multiple NICs simultaneously, thereby increasing the speed of the migration process. SMB can only be used if both the source and the destination server have Remote Direct Memory Access (RDMA) capabilities enabled.
The other feature that can help speed up live migrations is compression. Compression uses excess CPU capacity to compress data prior to sending it across the wire. This process works similarly to source-side deduplication. If at any time extra CPU resources are needed by the VMs, then VM demands take priority over the compression process.
Compression is enabled by default (see Figure 4). Note that compression and SMB are mutually exclusive features that can't be used together.
[Click on image for larger view.]
Figure 4. The Hyper-V settings menu lets you select compression and other options.
As you can see, Microsoft has made some really great improvements to Hyper-V. In addition to the improvements outlined here, Windows Server 2012 R2 Hyper-V also contains mechanisms for automatically activating VMs, exporting or cloning VMs while they're running, and support for dynamic memory on VMs that are running Linux.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.