In-Depth

First Look: Hyper-V 2016 Second Preview

The second technical preview of Microsoft Hyper-V 2016 might not look much different than the first but it has some important new features.

• By Brien Posey
• 08/03/2015

Microsoft released the second technical preview of its Hyper-V upgrade nearly eight months after the first one, yet on the surface it doesn't appear much has changed. To be quite candid, it looks as though Microsoft barely altered the new Hyper-V Manager in Windows Server 2016 Technical Preview 2.

However, even though everything looks the same on the surface, appearances can be deceiving. The next version of Hyper-V will contain plenty of new features such as rolling cluster upgrades, storage quality of service (QoS) upgrades and host resource protection, containers and an improved form of handling snapshots. In this article, I'll examine these new features.

Rolling Cluster Upgrades
One of the really nice things Microsoft is developing for Windows Server 2016 is a more simplified way of migrating to the new OS. Support for rolling cluster upgrades is one way Microsoft is doing this. Rolling cluster upgrades are somewhat similar to Active Directory upgrades. Consider what happens to an Active Directory forest each time a new Windows OS is released. Microsoft doesn't expect you to upgrade all of your domain controllers at the same time. Instead, you can mix and match Windows Server versions until all of your DCs are eventually running the new OS. Microsoft makes this possible by using the concept of functional levels.

Functional levels define the feature set that's available in Active Directory domains and forests. Suppose you have an Active Directory domain made up entirely of Windows Server 2008 machines. Odds are the domain is running at the Windows Server 2008 functional level. If you decide to upgrade to Windows Server 2012, then you can begin migrating to the new OS as you have time. During this transition process the domain will continue to operate at the Windows Server 2008 functional level. This means although Windows Server 2012 servers exist in the domain, you won't be able to use Group Policy features that are unique to Windows Server 2012 until you've migrated completely away from Windows Server 2008 and instructed Windows to raise the domain functional level.

Rolling cluster upgrades are designed to make it much easier to upgrade a Windows Server 2012 R2 cluster to Windows Server 2016. The process begins by draining the virtual machines (VMs) from one of the cluster nodes and then upgrading that cluster node to Windows Server 2016. Once the upgrade is complete, VMs can be moved back to the recently upgraded cluster node.

At this point, the cluster is operating in mixed-mode and will continue to behave as though all of the nodes are still running Windows Server 2012 R2. You can then move forward with upgrading the next node in the cluster to Windows Server 2016. This process is repeated one node at a time until the entire cluster has eventually been upgraded to Windows Server 2016. Only then can the cluster behave as a Windows Server 2016 cluster.

Storage QoS Policies
Microsoft has also made some welcome improvements to the Hyper-V storage QoS capabilities. The storage QoS feature in the existing version of Hyper-V allows administrators to enforce limits for IOPS consumption. An administrator can specify a minimum number of IOPS, thereby guaranteeing the VM always has a certain level of storage IOPS available to it. Conversely, it's possible to set a maximum level of IOPS consumption. That way, VMs running IOPS-intensive workloads can be constrained so as to not consume so many IOPS that other VMs running on the host begin to suffer performance problems because they can't get the IOPS they need.

While that storage QoS feature has worked as it was supposed to, it never scaled very well. The storage QoS feature had to be configured on a per-VM basis. This wasn't usually a big deal for organizations with relatively small Hyper-V deployments, but it simply wasn't practical for larger organizations to configure storage QoS on a per-VM basis. As such, the feature often went unused or under used.

Hyper-V in Windows Server 2016 will let customers use policies to configure storage QoS. These policies can be created and managed using either System Center Virtual Machine Manager or Windows PowerShell. These policies will allow an administrator to have a much more granular level of control over storage QoS.

Imagine for instance you have a multi-tier application and you want to ensure each of the individual servers in that multi-tier application received an equal amount of storage IOPS. You'll be able to easily accomplish your goal by using policies. The Quality of Service Settings screen within the Hyper-V Manager (see Figure 1) has been retrofitted to display the ID of the policy that applies to the VM. In this case, there is no policy, so the Policy ID field is grayed out.

As Microsoft has emphasized, Windows Server 2016 is designed to be a cloud-first OS. If your organization wants to build a private cloud architecture, it's common to classify storage as gold, silver, and bronze based on the characteristics of each type of storage (other naming conventions have also been used).

Using gold, silver and bronze classifications makes sense if you actually have three different types of storage. But what happens if you only have one type of storage? You could use storage QoS policies to create different levels of performance within a single storage array. Bronze storage might, for exam­ple, be the storage tier that receives the fewest IOPS, while the Gold tier receives a much higher level of IOPS.

Host Resource Protection
Like storage QoS, the host resource protection feature is designed to help prevent a VM from consuming excessive hardware resources. In a server virtualization environment all of the VMs running on a host server are competing for a finite pool of hardware resources. The host OS is also competing for those very same resources. The problem with this is a VM might occasionally consume too many resources, not leaving enough resources for other VMs or for the host. It's bad enough when this happens as a result of increased workloads, but sometimes increased resource consumption happens as a result of a compromised VM being used as a platform for launching a denial-of-service (DoS) attack.

In Windows Server 2016, Redmond has borrowed some of the code from Microsoft Azure and is using it to detect and remediate situations in which a compromised VM is launching such an attack. Although there aren't a lot of details available regarding how this feature works, the feature is said to work by looking for patterns of activity that should never occur within a non-malicious VM. If such activity patterns are detected, then the VM is throttled back so that it cannot continue to consume excessive resources.

Introducing Containers
Container support doesn't exist in Windows Server 2016 Technical Preview 2, but it's the most anticipated change to Hyper-V in the forthcoming Windows Server 2016 release later this summer.

The basic idea behind containers is that they can be used for application virtualization, and are designed to be lighter weight than a full-blown VM. Today virtualized application servers contain an application, but also contain the virtual server's OS. Containerized applications are different because they contain only the application itself, but not an OS.

So where do the OS components come into play? It's important to understand containers are going to be a Windows Server feature. Containers will also be supported by Hyper-V, but let's forget about Hyper-V for a moment.

When an application container is running on top of Windows Server, the containerized application uses the server's OS rather than providing its own OS in the way a VM would.

The disadvantage of how containers work is the server OS could potentially become a point of vulnerability. Remember that Windows Server 2016 is supposed to be a cloud-first OS. This presumably means multiple tenants will be running their own workloads. With that in mind, imagine what would happen if a tenant were to somehow hack their own containerized application in an attempt to communicate directly with the underlying OS. If that OS is also used by other containers belonging to other users, this hack could theoretically be used to launch a DoS attack against other user's containers. The technique might possibly even be used to gain access to other tenant's resources.

Microsoft is, of course, trying to prevent the server OS from becoming a vulnerability point. One of the things Microsoft is doing is to provide container support through Hyper-V.

The idea behind this is simple. Rather than let every container become dependent on a single server OS, Hyper-V could be used to establish a layer of isolation between tenants. Each container still has a dependency on an external OS, but Hyper-V can make it so that each tenant has their own server OS rather than a single OS being shared by everyone. That way, an escape attack like the one I described would be pointless because it wouldn't have any chance of allowing access to another tenant's resources. Hyper-V depends on hardware-level virtualization and so tenant isolation would essentially be enforced at the hardware level.

Of course, there's no rule that says all containers have to share a single OS. OS sharing simply helps to reduce the footprint of an application server. Some organizations have discussed the possibility of linking each of their containers to the container's own virtualized Nano server. This approach would still allow application servers to remain lightweight, but would eliminate any issues that might be associated with OS sharing.

Production Checkpoints
One of the most welcome features in Windows Server 2016 Technical Preview 2 Hyper-V is production checkpoints (see Figure 2). Production checkpoints (formerly known as snapshots) have been a part of Hyper-V for quite some time. The production checkpoint feature allows a VM to be rolled back to an earlier point in time without the need for restoring a backup.

Production checkpoints work well for rolling back VMs with bad patches or undesirable configuration changes. Unfortunately, however, production checkpoints have not previously been application-aware. Consequently, applying a production checkpoint to an application server could cause the application to be corrupted.

Production checkpoints allow checkpoints to be created in a data-consistent manner. Production checkpoints use Volume Shadow Copy Services to place the VM into a state in which the VM can be safely check pointed. Hyper-V is able to do this without having to place the VM into a saved state.

Wrapping Up
Although relatively few new features are exposed through the Hyper-V Manager, the Windows Server 2016 version of Hyper-V will include some welcome new features. Microsoft has documented the complete feature list, which is available here. In addition, there are a number of improvements in other areas of the OS (such as storage) that will directly benefit Hyper-V.