In-Depth

Hyper-V Sneak Peek: Windows Server vNext Edition

The Microsoft hypervisor gets a major makeover. See what's on the way.

• By Paul Schnackenburg
• 02/06/2015

The preview version of Windows Server vNext is out, giving us an indication of some of what's coming in Hyper-V. I'll cover the following features in this article:

• A new configuration file format/version
• A new type of checkpoint
• Mixed-mode clusters that can be upgraded on a rolling basis
• Integration services updated through Windows Update
• Secure Boot for Linux
• Hot-adding NICs and memory

Configuration Files and Version Upgrades
It turns out that Hyper-V has had a versioning for virtual machine (VM) configuration files, with the original release in Windows Server 2008 being version 1, all the way up to Windows Server 2012 R2 (5.0). This was handled by Hyper-V under the covers, and configuration files for VMs were upgraded automatically when the VM moved to a new host, with no administrator input necessary. The next version of Windows Server (hereafter called vNext) will bring version 6, but it also understands version 4 and 5.

This means you can cross-version live migrate (LM) a VM from a 2012 cluster to a vNext cluster (but not vice versa), similar to how you can LM from 2012 to 2012 R2 today.

The new version also introduces a new VM file format: .VMCX for configuration data, and .VMRS for runtime state data. These new file types should be more resilient to storage issues, compared to the current XML-based files. Converting a VM from version 5 to 6 is easy, but the VM does have to be turned off. Here's the command:

Update-VmConfigurationVersion nameofVM 

Note that this is a one-way trip; you can't downgrade the configuration files. Once upgraded (as shown in Figure 1), the VM will only run in vNext. The upgrade only takes a few seconds. If the VM has online checkpoints, they'll be converted to offline checkpoints as part of the upgrade process.

Cluster Rolling Upgrades
Upgrading to take advantage of new functionality is painful, and Microsoft felt your pain. Between the Windows Server 2012 and 2012 R2 versions of Hyper-V, Microsoft attempted to help by offering cross-version live migration. It allowed you to stand a 2012 R2 cluster next to your 2012 cluster and migrate VMs from the old to the new.

This has problems, though. One is that it's one way; if there are issues with the VM after the upgrade, you can't move it back easily. There's also a high availability (HA) gap, as the VM has to be turned into a non-HA VM before the migration. Finally, the need to have a new cluster next to the old one might necessitate the procurement of new hardware, potentially slowing down the upgrade process.

Going from 2012 R2 to vNext is going to be a much easier process, due to mixed-mode clusters. Active Directory administrators are familiar with this process of gradually introducing new version nodes that pretend to be the old version until all nodes have been upgraded and the functional level updated.

For this to work, all VMs will run with the old version 5 format (and you're blocked from creating version 6 VMs by the cluster) until you've upgraded all cluster nodes and then run this Windows PowerShell cmdlet (functional level 8 is 2012 R2, 9 is vNext):

Update-ClusterFunctionalLevel

Note that nodes here refers to both Hyper-V hosts and Scale out File Server (SOFS) cluster members. The upgrade requires draining the node of load, evicting it from the cluster, reformatting and clean installing the new OS, then adding the host back into the cluster. There's no way to upgrade the OS in place.

If you're upgrading an SOFS cluster, you'll definitely want to back up your data first. Be aware that some operations, such as provisioning new storage or changing the size of existing storage, aren't recommended while the cluster is in mixed mode. The assumption is that you're only going to be in this in-between stage for a short period of time. Note that only 2012 R2 to vNext is supported for mixed-mode clusters; Microsoft didn't have time to include the code in 2012, but it did prepare the plumbing for this to work in 2012 R2 before it shipped.

You'll still need to shut down each VM to upgrade the configuration files, but as they'll run fine with the old version, this can be scheduled into a change management window. While the cluster is in mixed mode it should be managed from vNext hosts.

Speaking of clusters, there are other improvements such as leaving VMs on a node (if they're still running and have network connectivity) if there's a short network outage, which would cause a failover in a Windows Server 2012 R2 Hyper-V cluster. If there are intermittent issues with a host, it will be quarantined and VMs prevented from migrating there. These types of changes are designed to make clusters “smarter” and less likely to cause issues simply because of clustering itself.

Integration Services Updating
There's a trend in enterprises to separate infrastructure administrators and application/VM administrators. With this separation, the former has no rights to the VMs running on top of their hosts, while the application admins don't even know the details of the underlying fabric. This presents a problem, as each release of Hyper-V mandates an update to the integration services inside each VM.

This issue has been addressed with a change to integration services updating through Windows Update. So whether you're using Configuration Manager, Windows Server Update Services (WSUS) or Windows Update, you'll receive any needed updates the same way any other patches reach your VMs. Having the integration services version matching the host Hyper-V version is also no longer a requirement for Microsoft support; you'll just need the latest version for your VM OS.

Production Checkpoints
Anyone with Hyper-V experience knows the convenience of being able to snapshot a VM state before implementing a potentially disruptive change. But you also know the dangers of snapshotting for workloads such as domain controllers (DCs), Exchange Servers and SQL Servers: If you apply a checkpoint to a VM that's replicating with others, it's effectively sent back in time. That can cause AD corruption, password mismatches, missing group memberships and other data loss.

The issue with DCs was fixed in 2012 with virtualization safeguards, but other workloads are still in danger.

vNext brings new types of snapshots, called Production Checkpoints (Figure 2). It uses the Volume Snapshot Service (VSS) from within the VM (or flushes the file system buffers in Linux VMs);  because the VM is aware that it happened (it's more like a backup operation), applying a checkpoint won't disrupt workloads. Production Checkpoints will be the new default, although you can go back to the traditional type of snapshots on a per-VM basis if needed, as Figure 3 illustrates.

Linux SecureBoot
It turns out that while Microsoft heard a lot of criticism in the early days of Windows 8 for trying to lock Linux out from even being installed on new computers, it was just biding its time before spreading the security love to the penguin. Generation 2 VMs have virtual UEFI firmware instead of a legacy BIOS; in vNext this can be used to extend Secure Boot to Linux, mitigating the risk of rootkits and other low-level malware. Today this works for Ubuntu 14.04+ and SUSE Linux Enterprise Server 12; you have to enable it before you start the VM the first time using Windows PowerShell:

Set-VMFirmware vmname -SecureBootTemplate MicrosoftUEFICertificateAuthority.

Other Improvements
Generation 2 VMs were introduced in 2012 R2, doing away with all legacy-emulated hardware; but they were more a pointer to the future, as they weren't supported in System Center Virtual Machine Manager 2012 R2 service templates. In vNext, you can add and remove NICs in a Windows/Linux Generation 2 VM while it's running. You can also change the amount of memory assigned to a VM while it stays online. Second Level Address Translation (SLAT) processors are now a requirement to run Hyper-V; in earlier versions it was recommended, but only required for VDI deployments.

If you add a virtual HDD to a VM that's using Hyper-V Replica, replication will fail in 2012 R2. In vNext, the drive will be added to the VM, but put in a non-replicating set. If you need the drive to be protected, you can manually add it to the replication set. You can replicate a VM from 2012 R2 to vNext and vice versa (unless you upgrade the VM configuration version). This will be a good way to test your upgrade path if you have two sites with VMs being replicated between them; upgrade your secondary site first, do some test failovers and ensure that your VMs run fine on vNext before upgrading your primary site.

An irritating issue is when you add several NICs to a VM and then go into the VM to configure them, only to find that you have no way of telling which NIC is which. vNext exposes the name you've given to the virtual switch inside of the VM, making it much easier to pick the right one.

Hyper-V Manager (Figure 4) now connects via WinRM to remote servers, making it more resilient to network issues; you can connect to servers via just their IP address. You can also start the Manager with alternate credentials, as shown in Figure 5. VMs with statically assigned memory will still be tracked by the engine that manages Dynamic Memory, so you can see in the UI how much memory your VMs are asking for, and make adjustments to your memory settings accordingly.

Speaking of Hyper-V Manager, there's a bug in the Technical Preview that might make some of your VMs disappear from the list (although they're still there and running). This is fixed by running the following:

get-vm |  ?{$_.heartbeat -eq "OKApplicationsUnknown"} |  Disable-VMIntegrationService "Heartbeat" 

A very cool approach to managing Hyper-V clusters is viewing a whole cluster as a really big, single, Hyper-V host; this is enabled through WMI, and it's not in the Technology Preview.

Coming Soon: Backup and Storage
Windows 8.1 devices such as Surface Pro lose the advantage of Connected Standby if Hyper-V is enabled; in the Hyper-V client in Windows 10, Connected Standby will work.

The other side of the Hyper-V coin is backup and storage; there are some really big changes coming in vNext in these areas, which I'll cover in a future article. The improvements in Hyper-V are clearly aimed at making life easier for virtualization administrators, as well as challenging VMware with innovative features.