Latest posts by Paul Schnackenburg (see all)
- Project Honolulu - A new way to manage Windows Server - Wed, Nov 22 2017
- Use Azure Managed Service Identity (MSI) to store passwords in your code securely - Thu, Nov 9 2017
- Azure Data Lake overview - Fri, Sep 22 2017
For features such as the new VM configuration file format, rolling OS cluster upgrades, production checkpoints, integration services updating through Microsoft Update, and secure boot for Linux, please see the earlier article as they haven’t changed substantially since then.
In this article, we’ll cover the new things that are available in Technical Preview 2 (TP2) to test in a lab.
Security - it’s all about trust ^
Hand in hand with the ability to protect the kernel and boot files/process, not only for Windows but now for Linux virtual machines through Secure Boot, comes Virtual TPM.
This makes it possible to use BitLocker from within a VM to protect it from prying eyes. And, of course, this is all tied to cloud computing. It’s possible through third-party add-on services to encrypt VMs running in Azure today, but it’s a clunky process. With Virtual TPM, I suspect encrypting your VMs running in public or third-party hosted clouds will become the default and the protection may even become desirable in private datacenters.
The Virtual TPM chip is part of a larger story called Shielded Virtual Machines where you can designate particular fabrics where a VM can run. The encryption keys are used when a VM is powered on or Live Migrated and the keys are only available to the VMs; management of the keys is provided by System Center Virtual Machine Manager 2016 or the new version of Azure Pack.
There’s so much more technical background to Shielded VMs that I’ll cover the feature in a separate article.
There’s also the new Host Resource Protection, which is born out of Microsoft operating Azure with attackers running code inside VMs and trying to break out. When they do this, their code sometimes starves the host of resources, which Azure identifies and protects against by limiting the resources of a misbehaving VM; this same code is in TP2.
A more resilient fabric ^
Clearly building on real-world feedback, two new features will improve reliability: VM Storage Resiliency and VM Cluster Resiliency. The first one builds on a feature already present in Windows Server 2012 called resilient file handles, where a short outage (up to 60 seconds) for a VM to its backend VHD/VHDX files will be managed. If the connection comes back in time, the VM will simply keep running; if it doesn’t, the VM is informed of the loss of connectivity and will most likely crash. In TP2, however, the VMs on the host will pause (after that initial 60 seconds), waiting for the connection to resume and flagging the state so an administrator can take action.
VM Cluster Resiliency deals with non-storage networking outages. If a host loses connectivity today in a cluster (even if it’s for a very short time), a failover will occur with the potential of data loss. In TP2, a host that’s disconnected for up to four minutes (default setting) will be isolated; its VMs will be put into an “unmonitored” state, but no failover action will be taken. If a host continues to have intermittent network “flapping,” as soon as it comes back online the VMs on it will be Live Migrated to another host and no VMs will be migrated back to it.
To prevent a hungry VM from starving other workloads on the same host (or other hosts in a cluster), Microsoft now offers Storage QoS with a centralized controller. I covered this in detail in this article, but it’s worth mentioning again because I suspect this new feature will be one that many fabric administrators will come to love more than any other.
I think most sysadmins don’t yet trust their production workloads to Resilient File System (ReFS), which arrived in Windows Server 2012 but has some limitations. This is likely to change in Server 2016 with both Scale-Out File Server and Hyper-V taking advantage of some very cool improvements. In TP2, you can create a fixed-size virtual hard drive in seconds, compared to the hours you may have to wait for NTFS today. And the merging of virtual disks, which happens behind the scenes when you apply a classic checkpoint as well as after the initial replica in Hyper-V Replica has completed, also takes only seconds on ReFS.
More online actions ^
In the quest for VM uptime, we like as many actions as possible to be done while our VMs keep running— a trend we’ve seen Microsoft oblige since Hyper-V in Windows 2012. TP2 doesn’t disappoint. Shared VHDX for guest clusters now offers the ability to resize the VHDS (new format for the shared disk) while the VMs in the guest cluster keep running. You can now also back up a shared VHDS from the host; in 2012 R2, this requires a backup agent inside the VMs.
Memory statically assigned to a VM can now be resized with the VM online, and network adapters can be added and removed to a running VM. Also new is that, even if you’re using statically assigned memory for VMs, Dynamic Memory will still report the demand from the VM, making it a lot easier to identify the actual memory need of the workload.
Adding disks to a workload that Hyper-V replica protects is tricky in 2012 R2 and can trigger a complete resync of all disks—something that’s highly undesirable. In TP2, you can add a disk to a VM that’s being protected to another host. The new disk will not be in the “replicated set” initially, which allows normal replication to proceed. If you do need this new disk to be replicated, you can add it to the set without disturbing the ongoing replication of changes to the existing disks.
PowerShell everywhere ^
PowerShell Direct is a very interesting new feature that offers the ability to run PowerShell from the host directly into a VM. This does not require any firewall configuration, nor do you need to enable remote management; you do, of course, need credentials for the VM.
You’ll need to run PowerShell as an administrator. You can use either Enter-PSSession –VMName or Invoke-Command –VMName to execute cmdlets. Note that not all cmdlets work yet (remember, it’s a technical preview).
PowerShell Direct Remote Command
Other improvements ^
The ability to connect Hyper-V Manager to hosts using alternate credentials, as well as being able to specify those hosts with IP address instead of host name, will be welcome.
Hyper-V Manager connection with alternate credentials
Also worth mentioning is the ability to treat an entire cluster like a single, huge Hyper-V host. This capability is most useful through PowerShell. It is by no means complete yet; at the moment, the most you can do is list all VMs by pointing your cmdlet at a cluster name instead of a single host. But capability such as this brings great promise for the future.
Overall, I find that the additions that are coming to Hyper-V, revealed in TP1 and TP2, are genuinely useful and will bring a lot of very useful improvements to the platform. I can’t wait for TP3.