Virtual Windows

Since the first version of Windows  NT more than 20 years ago, Microsoft has pursued its goal of providing a unified operating system for clients and servers. In the next generation of Windows, Redmond has expanded this concept: From the embedded computer on smartphones and tablets to PCs and servers for large and small companies, the Windows kernel is intended to be a universal system. Microsoft addresses larger environments with the new Windows Server edition. The preview versions pay particular attention to new features for virtualization and storage capabilities.

The development roadmap for the server operating system largely corresponds to that of its sibling Windows  10: At least one more intermediate version is expected in Spring 2015. The finished product has been announced for late Summer 2015. As always, Microsoft's contract customers with volume licenses will have first access to the new bits and bytes through the web distribution. Single versions on media will be available a few weeks later.

An overview of new features in Windows Server 2016 is available online  [1], but here, I want to take a look at the details of support for Hyper-V and Docker containers unveiled shortly after the release of the Technical Preview  [2].

Virtual Containers with Docker

A virtualization container behaves similarly to a virtual machine (VM). Unlike conventional VMs, however, a container shares most of the server resources with all other containers and processes running on the server. Thus, the container is not an encapsulated virtual machine with its own memory, virtual disks, and virtual hardware resources such as CPU and network cards, and it does not run its own instance of the operating system.

Container virtualization is based on strict isolation of processes and management of namespaces (registry, filesystem, etc.). All containers use the server operating system as their basis but only see their own isolated environment. The processes within a container are not connected to other containers. Because of resource sharing, they launch much faster than full VMs and are usually up and running within seconds.

Transferring Applications with Ease

As an additional administrative layer for this new form of virtualization, Microsoft integrates the Docker open source software. Docker offers a comprehensive set of management techniques and provides a packet format for complex applications. A Docker container, in addition to specific application software, also includes all the necessary dependencies and prerequisites, including databases, interfaces, and software libraries. Such containers can be transferred en bloc to any Docker-enabled server, and the packaged application will run there without further installation or preparation.

Docker thus solves a problem that arises in particular for operators of complex web applications: Programmers develop new versions of an application on their test systems. It can easily happen that the developer computers include components that are missing on the production computers. If a missing component is revealed after the roll-out of the new version, the application will not run correctly, thus leading to time-consuming fixes. If the application and all necessary components are encapsulated in a Docker container, such deployment errors are preventable. The entire application container can be transferred as a package from the development to the testing system, and from there to the production server, as well. Ongoing upgrades can therefore be carried out quickly and with high reliability.

Container virtualization and Docker integration are not yet available in the Technical Preview. Admins can expect to see them in the later beta versions and, of course, in the final version.

More Flexible Snapshots in Hyper-V

Microsoft's in-house virtualization environment, Hyper-V, has long established itself as a serious competitor to virtualization market leader VMware. The functions of the Windows hypervisor not only cover the needs of SMEs but increasingly those of larger environments as well. The upcoming version takes this into account and is designed especially with the new Production Checkpoints to improve the reliability of virtual servers. This feature is all about a new snapshot technology for virtual machines that is suitable for recovery from server failures (Figure 1). Thus far, VM snapshots (which Microsoft has dubbed "checkpoints" since 2012) have caused serious errors in applications, and their use was therefore not officially supported for recovery.

Figure 1: Secure snapshot: Thanks to Production Checkpoints, VM snapshots in Hyper-V will be supported for recovery purposes in the future.

A conventional snapshot saves the state of a VM in read-only files, which means that both the content of the virtual disks and the memory of the VM is available as a snapshot. The big advantage is that all data and applications are in exactly the same state as when the snapshot was grabbed. However, this can also be a disadvantage, because complex applications, in particular, become confused when they are suddenly beamed to a different time. Production Checkpoints make Hyper-V take a different approach.

This new snapshot variant works with VSS (Volume Shadow Copy Services) to switch the VM and especially its applications into a consistent state. This VSS snapshot then forms the basis for the Checkpoint  – the VM's RAM is not stored explicitly. The VM's operating system and the applications are thus in a defined state  – simply put, the VM knows that it has been backed up. If you restore the virtual machine to this checkpoint, it behaves as if you had restored a backup.

Following this paradigm shift, Production Checkpoints are now officially approved as a recovery method. Two important conditions apply, however: On one hand, the VM in question must be running under Windows, because VSS is only available there. On the other hand, the applications on the VM must explicitly support the VSS method. This is true today of most server applications. For VMs that do not meet these requirements, Hyper-V by default uses the conventional snapshot technique. Although this does not guarantee data consistency, it is sufficient in some situations. If desired, you can also switch back to the previous snapshot method.