In-Depth

First Look: Hyper-V Server Technical Preview

Here are some inital thoughts at the first test build of the upgraded Microsoft hypervisor server shows improved migration, upgraded Hyper-V Manager and new VM versions.

• By Brien Posey
• 03/06/2015

Microsoft last month delayed the release of the next major Windows Server upgrade until next year. Having last upgraded Windows Server in late 2013, Microsoft had originally suggested the next version would arrive this year. What little we've seen of the next Windows Server version, often referred to as vNext, were some major new features slated for its hypervisor, Hyper-V.

Indeed, Hyper-V is a key component of the Microsoft Cloud OS, the company'snext-generation datacenter platform enabling hybrid cloud architectures. The company said it will release a second preview of Hyper-V this year. Having spent several months with the first Hyper-V Server Technical Preview, there are a number of key new features that will benefit systems administrators. So far Microsoft has disclosed roughly a dozen new features as part of the technical preview, which include:

• Rolling Hyper-V Cluster Upgrade
• Storage Quality of Service (QoS)
• Virtual Machine Configuration Version
• New Virtual Machine Configuration File Format
• Production Checkpoints
• Hyper-V Manager Improvements
• Integration Services Delivered Through Windows Update
• Hot Add and Remove Network Adapters and Memory
• Linux Secure Boot
• Compatible with Connected Standby

At first glance, it's easy to scoff at the list of new features. After all, the last two Hyper-V releases each boasted hundreds of new features, while this list of new features in the Hyper-V Server Technical Preview is comparatively quite modest. However, there are a couple of things to consider.

First, this is a preview release -- Microsoft could announce additional features. Also, many of the new features are geared toward eliminating downtime that would otherwise occur as a result of maintenance and migration processes. This is extremely important because so many organizations now run mission-critical workloads on Hyper-V (see the June 2014 feature, "Hyper-V Moves into the Fast Lane"). Such an organization would presumably like to avoid taking a mission-critical workload offline as part of the migration to the next version of Hyper-V.

Rolling Cluster Upgrade
One way Microsoft is helping to eliminate the down time commonly associated with the migration process is through the Rolling Cluster Upgrade feature. Perhaps a better name for it would be Mixed Clusters, because the feature allows a clustered Hyper-V deployment to include a mixture of legacy cluster nodes and new cluster nodes.

An example is the Failover Cluster Manager (see Figure 1) as it appears in Windows Server 2012 R2. Prior to the release of the Windows Server Preview, I had created a Hyper-V cluster that was based solely on Windows Server 2012 R2 servers. Once Microsoft released the new Windows Server Technical Preview, I was able to join it to my existing Windows Server 2012 R2-based cluster. As you can see in Figure 1, servers Lab1, Lab2, and Lab3 are all running Windows Server 2012 R2, whereas server Lab5 is running the Windows Server Technical Preview. Note: I didn't have to do anything special in order to join the cluster.

This is what Microsoft means when it refers to rolling cluster upgrades. You don't have to upgrade your cluster nodes all at once, nor do you have to create a brand-new cluster in order to migrate to the next version of Windows Server. You can gradually update the servers in your cluster (or bring new nodes into the cluster) as you see fit. The cluster can run a mixture of Windows Server versions for an indefinite period of time.

Virtual Machine Migrations
Mixing Windows Server versions within a cluster is nice, but you might have concerns about how doing so impacts your virtual machines (VMs). A VM running on Windows Server 2012 R2 Hyper-V can be live migrated to a Hyper-V Server Technical Preview using exactly the same method that would be used if that VM were being migrated to another Windows Server 2012 R2 Hyper-V (see Figure 2). This holds true whether or not you're using failover clustering.

It's worth noting live migrations to Hyper-V Server Technical Preview aren't necessarily permanent actions. You can live migrate back to a legacy Hyper-V server without any problems.

As great as it is to be able to mix server versions within a failover cluster and to live migrate a running VM between different versions of Hyper-V, it would be irresponsible of me not to point out that your ability to live migrate a VM from a Hyper-V Server Technical Preview to a legacy Hyper-V server hinges on the version of the VM.

Virtual machines created on a server running Windows Server 2012 R2 Hyper-V have a version number of 5. As long as the version number remains unchanged, the VM can be live migrated across different versions of Hyper-V servers to your heart's content. However, if you want to use any of the new VM-specific features (such as production checkpoints), then you'll have to upgrade the VM version to 6. Once the VM version has been updated, it can no longer be hosted on a legacy Hyper-V server.

This brings up an important point. If a failover cluster is running a mixture of new and legacy Hyper-V servers, then you won't be able to upgrade the VM version number until all of the failover cluster nodes are running the new version of Hyper-V and the cluster functional level is also upgraded. At that point, it's impossible to add any legacy nodes to the cluster.

Incidentally, if you have a cluster containing multiple Hyper-V versions, then it's important to use the Hyper-V Server Technical Preview to manage the cluster. The Failover Cluster Manager that's included with Windows Server 2012 R2 might not always work properly with the Windows Server Technical Preview.

Hyper-V Manager Improvements
Microsoft has added three noteworthy improvements to Hyper-V Manager. The first is support for alternate credentials. This makes it a lot easier to connect to remote Hyper-V servers that use a different set of administrative credentials.

Second, the console now communicates with Hyper-V using the WS-MAN protocol. This allows for CredSSP, Kerberos, or NTLM Authentication. The third improvement is related to backward compatibility. The Hyper-V Manager console included with the Technical Preview supports the management of legacy Hyper-V servers. Take an implementation where the console is connected to five different Hyper-V servers. Lab1, Lab2, Lab3, and Lab4 all run Windows Server 2012 R2 Hyper-V, while Lab5 is running the Hyper-V Technical Preview (see Figure 3). Hence, multiple versions of Hyper-V can be managed through a common console.

Virtual Machine Versions
As noted, legacy VMs are based on version 5 and new VMs use version 6. But what does this really mean in a practical sense?

You'll notice in Figure 3 that there are two VMs on the server Lab5. One of these VMs (Windows Server 10 Test VM 1) was live migrated from a legacy Hyper-V server. The other VM (Windows Server 10 Test VM 3) was created directly on the Hyper-V Server Technical Preview server. With that said, take a look at the summary information for the currently selected VM. As you can see in the figure, the VM version is 6.0.

If you need to check VM versions in bulk, you can easily do so through Windows PowerShell by entering the following command:

Get-VM * | Select-Object Name, Version

Virtual Machine Structure
It isn't just the versions of the VMs that are dissimilar, but also the VM structures. That's because there's more to a VM than its virtual hard disks. Hyper-V uses several different file types. Some of the more important file types used by Windows Server 2012 R2 Hyper-V (at least for the purposes of this discussion) include:

• VHD and .VHDX: virtual hard disk files
• XML: VM configuration data
• VSV: VM save state file
• BIN: VM runtime state data (memory contents)

Every version 5 VM has a configuration data file and there is also usually at least one virtual hard disk, The .VSV and .BIN files may or may not exist, depending on the VM's current state.

Microsoft has changed some of the file types that are used for version 6 VMs. This was done as a way of improving efficiency and of reducing the chances of data corruption in the event of a storage failure.

Version 6 VMs still use .VHD or .VHDX based virtual hard disks. The folder structure used by the VM is still the same as well. Virtual hard disks and the other VM components are stored in subfolders beneath the VM name. For example, I created a version 6 VM named Windows Server 10 Test VM 3 and I stored it at F:\VMs. As such, the main paths used by the VM are:

• F:\VMs\Windows Server 10 Test VM 3\Virtual Hard Disks
• F:\VMs\Windows Server 10 Test VM 3\Virtual Machines

These are the same paths that are used by Windows Server 2012 R2 Hyper-V. You really don't begin to see the differences until you dig into the Virtual Machines folder.

If you open the Virtual Machines folder for a version 5 VM, you'll see a folder whose name matches the VM GUID. There's also an .XML file that uses the VM GUID as its file name (see Figure 4). If a .VSV and a .BIN file exist for the VM, they'll be in the <GUID> folder.

With the Virtual Machines folder for a version 6 VM, the GUID is still used, but the .XML-based configuration file has been replaced by a .VMCX and a .VMRS file (see Figure 5). The .VMCX file is a binary file used to store the VM configuration data. The .VMRS file contains runtime state data.

Upgrading a Virtual Machine
While you can upgrade a VM from version 5 to version 6 in order to unlock the new features for the VM, keep in mind once you upgrade the VM you can't host it on a legacy Hyper-V server. With that caveat, you can convert a virtual machine to version 6 by entering the following command into Windows PowerShell:

Update-VmConfigurationVersion <virtual machine name>

Microsoft has designed the first Hyper-V Server Technical Preview in a way that allows it to fit seamlessly into your existing Hyper-V infrastructure. This allows Hyper-V admins to transition to the new version in a way that makes sense for their own organization.