New in Windows Server 10 Hyper-V

There’s a new version of Hyper-V on the block in the form of the recently released Windows Server “10” Technical Preview (TP). And there’s no doubt that Microsoft is serious about innovating and improving the hypervisor to beat VMware in the technical boxing ring.
Profile gravatar of Paul Schnackenburg

Paul Schnackenburg

Paul Schnackenburg works part time as an IT teacher as well as running his own business in Australia. He has MCSE, MCT, MCTS and MCITP certifications. Follow his blog TellITasITis.
Profile gravatar of Paul Schnackenburg

So far (I’m expecting more features and scale figures to be revealed before the final release), this preview brings us a new VM configuration file format and version, new production checkpoints, rolling upgrade of clusters, integration service updates through Windows Update, hot-added NICs and memory, and Linux Secure Boot. Best of all, connected standby now works on client Hyper-V.

Note that this article is written based on fairly early code in the Technical Preview. A lot can change between now and the final version.

VM configuration file format and version ^

VM information is now stored in the (not directly editable) file format VMCX, whereas the running state of each VM is stored in the new VMRS format. The point of these new file types is that they are more resilient to storage failures; how that will actually play out in real-life production scenarios remains to be seen. Microsoft does have some experience; one of the main “selling points” of the VHDX virtual hard drive format (apart from the capacity increase) that was introduced in Windows Server 2012 R2 was the exact same resiliency.

VMs created in Windows Server 2012 R2 have configuration files that are in version 5 format and are stored in an XML file. These VMs can run on both 2012 R2 and the Technical Preview. Once a VM has been moved to a Technical Preview Hyper-V server (and has been shut down), its configuration can be upgraded to version 6 using PowerShell, like this:

This is a one-way trip. You can’t downgrade a VM configuration and, once complete, this VM won’t run on Windows Server 2012 R2 Hyper-V. In my testing, the upgrade process only took a few seconds.

Upgrade a VMs configuration version

Upgrade a VM’s configuration version

Mixed versions in a cluster ^

Microsoft’s move from 2012 to 2012 R2 offered an interesting upgrade story in that you could have a 2012 cluster and a new 2012 R2 cluster, and VMs could be live migrated across versions from the old environment to the new one with no downtime. This does, however, require that you add new nodes or take one or two hosts out of the source cluster to upgrade to 2012 R2; the upgrade story in the Technical Preview is even better.

Taking a leaf from the Active Directory upgrade process, it’s possible to mix the old with the new in the same cluster. When you’ve upgraded all your DCs or, in this case, Hyper-V hosts, you can upgrade the functional version of the entire cluster. So, migrate all VMs off one host, upgrade or do a clean installation to Technical Preview, add it to the cluster again, and migrate VMs back onto the host. Rinse and repeat, at your own pace, until all nodes have been upgraded. All the VMs will operate with version 5 configuration versions. None of the new Hyper-V features will be available until you run Update-ClusterFunctionalLevel in PowerShell, just like you manually have to update the functional level of an AD domain to access the new features.

Once the cluster has been upgraded, you can’t add 2012 R2 nodes; however, the Update-VMConfigurationVersion cmdlet becomes available. You’ll still have to shut down each VM to upgrade the configuration, but you can schedule this for a convenient time since they’ll run fine with the old configuration files. While your cluster has both old and new hosts, the recommendation is to manage the cluster from Technical Preview servers.

Safer snapshotting – production checkpoints ^

Hyper-V has always had the ability to create a snapshot of the state of a running VM, but that snapshot has come with a dire warning: don’t use it in production unless you REALLY know what you’re doing. While these snapshots are fine in lab and learning situations, they can wreak havoc on production VMs. Examples include Domain Controllers, clustered SQL servers, and Exchange mailbox servers in a DAG; if any of these are snapshotted and, at some later point in time, the snapshot is applied, you have effectively transported the VM “back in time.” If it then replicates with other VMs, those other VMs won’t realize that this has happened and therefore won’t send changed data to bring the VM up to date. This can lead to data loss or other intermittent problems.

Production Checkpoint using VSS

Production checkpoint using VSS

The Technical Preview brings an interesting twist to this scenario by using VSS technology inside a Windows VM and flushing the file system buffers inside a Linux VM to create production checkpoints, which will be the new default. This will be completely supported for all production workloads because it’s like a backup and, unlike traditional checkpoints, the VM is aware of it. You can optionally go back to the legacy type of checkpoints.

Production Checkpoint Settings for a VM

Production checkpoint settings for a VM

Keeping up to date ^

Once the Technical Preview is released (Windows Server 2015, anyone?) the integration services inside the VM will be kept up to date using normal Windows update channels such as WSUS, Configuration Manager, or Microsoft Update. This will be a welcome addition as it’ll eliminate a separate process for keeping this particular software up to date.

For Generation 2 VMs (introduced in 2012 R2 and lacking legacy emulated hardware), you can now add or remove network adapters while the VM is running (works for both Windows and Linux VMs), as well as change the amount of memory assigned to the VM even if that VM is not configured for dynamic memory. Both of these changes will contribute to better up time for VMs as more alterations can be done without having to shut down the VM first.

Secure Boot for Linux ^

Anyone remember the uproar in the Linux community about Secure Boot in the days of the Windows 8 betas? This was meant to be evil Microsoft, locking poor Linux out from even being able to be installed on new PCs. Of course, it didn’t work out that way; you can disable Secure Boot in the BIOS on any modern PC and install an OS of your choice. You just won’t be as protected against rootkits and other low-level malware infections.

With the introduction of Generation 2 VMs in 2012 R2, Microsoft went with a virtual UEFI firmware instead of a legacy BIOS, which enabled Secure Boot for VMs. This support has now been extended to Linux with Ubuntu 14.04 and later, and SUSE Linux Enterprise Server 12 can also take advantage of it. You do have to enable Secure Boot before first boot using the following:

Conclusion ^

Something that I haven’t tested yet is that Connected Standby now works in client Hyper-V in Windows 10. In Windows 8.1, you lose the convenience of your Surface Pro or other similar device being always connected and “sleeping lightly” if you enable Hyper-V.

The improvements that have been revealed in Hyper-V again show that Microsoft is very serious about innovating in this space, and several of these enhancements are clear winners from a technical and business perspective. I can’t wait to upgrade my cluster to the new version to really take it through its paces. However, that will have to be done in conjunction with the improvements to storage, which we’ll cover in the next article.

Next in this series are the new storage features in Windows Server 10.

Take part in our competition and win $100!


Leave a reply

Your email address will not be published. Required fields are marked *



Please ask IT administration questions in the forum. Any other messages are welcome.

© 4sysops 2006 - 2017
Do NOT follow this link or you will be banned from the site!

Log in with your credentials


Forgot your details?

Create Account