Key Concepts:

Windows Containers

How are Windows containers different to Linux containers and how can they be used most effectively?

Key points:

  • Despite their similarities to Linux containers, Windows containers introduce additional complexities that must be understood in order to use them in an optimal manner.

  • Process isolation mode should be strongly preferred over Hyper-V isolation mode when building and running Unreal Engine containers.

  • Choose the version of Windows Server that you run on your container hosts carefully to avoid excessive maintenance overheads.

Windows containers are a far newer technology than their more mature Linux counterparts, having first been introduced in Windows Server 2016. The manner in which Windows container images interact with the host system kernel brings with it additional mechanisms and associated complexities which are not present when working with Linux containers. This page provides an overview of the key differences between Windows containers and Linux containers, and provides guidance on how to achieve optimal performance when building and running Windows containers.


Windows container architecture

The Windows container platform page provides an overview of the key architectural differences between containers running under Windows hosts and those running under Linux hosts. Further technical detail is provided in this DockerCon presentation discussing the initial implementation of container support in Windows. The key architectural differences are summarised below:

Kernel version compatibility

Due to the excellent backward-compatibility of the Linux kernel, Linux containers encapsulating older distributions will continue to work correctly with newer kernel versions. Newer distributions will also often continue to function correctly on older kernel versions, although this will not be the case if the software inside the container relies on newer kernel features that are not present in the older kernel. As a result, the Linux host system needs only to maintain an up-to-date kernel version to ensure maximum compatibility with a wide range of Linux container images 3.

This is not the case for Windows containers. Container images based on older Windows versions will not run on newer host kernel versions, nor will newer containers run on older host kernel versions 4. Microsoft maintains a compatibility table detailing supported host/container configurations, accompanied by a detailed discussion of how Windows container version compatibility works. As can be seen in the compatibility table, older container images can actually be run on newer host systems, but only by utilising a mechanism called Hyper-V isolation mode, which is described in the next section. It is worth noting that work is underway to improve kernel version compatibility in newer versions of Windows.

Isolation modes

Windows containers can run in one of two “isolation modes”:

Although Hyper-V isolation mode offers the convenience of improved compatibility by decoupling the host kernel from running containers, the use of Hyper-V VMs introduces additional complexities and associated issues. These issues are discussed in the next section.

What about HostProcess containers?

HostProcess containers are a new type of Windows container that will be supported in upcoming releases of containerd and Kubernetes. The Microsoft documentation has not yet been updated to include information about HostProcess containers, so it is unclear whether this will be classified as a third isolation mode or a separate category entirely. This page will be updated to reflect Microsoft’s decision once their documentation is released.

Hyper-V isolation mode issues

There are a number of issues present in the current implementation of Hyper-V isolation mode that significantly hinder its suitability for use in production systems:

The implementation of Hyper-V isolation mode under older versions of Windows also suffered from additional issues that have subsequently been fixed in modern releases:

Windows base image variants

Microsoft provides three primary variants of the Windows base image:

Windows Server 2022 will introduce a fourth base image called, which is equivalent to a full installation of Windows Server with the Desktop Experience enabled. The list above will be updated with the relevant details once Windows Server 2022 is released.

All Windows container images must derive either directly or indirectly from one of these base image variants. (The FROM scratch directive that can be used to create Linux base images is not supported for Windows containers, although there may be an equivalent supported for HostProcess containers.) It is also worth noting that the filesystem layers for each of the Windows base images are marked as foreign layers, which means they are not stored in private container registries by default and are instead pulled directly from the Microsoft Container Registry.

Hardware acceleration support

For information about GPU acceleration specifically, see GPU support for Windows containers.

Docker versions 19.03 and newer running on Windows Server 2019 or newer and Windows 10 version 1809 or newer can utilise experimental support for accessing hardware devices inside Windows containers by specifying the --device flag, in a similar manner to how this flag is currently used to expose hardware devices to Linux containers. The experimental device access functionality includes special treatment of GPU devices, with support for hardware acceleration using the DirectX API. It is important to note that this functionality is not the same as that provided by the NVIDIA Container Toolkit for Linux containers, which supports OpenGL, OpenCL, Vulkan and NVIDIA CUDA.

Official support for hardware acceleration is currently limited to containers derived from the base image that are running in process isolation mode, although testing performed by the authors of this documentation has indicated that GPU acceleration will also function correctly in other base images if the necessary DLL files are copied over from the Windows client base image. (Note that the announcement for the upcoming base image indicates that hardware acceleration will also be officially supported for that image.)

Hardware acceleration is not supported for containers running in Hyper-V isolation mode, and testing has confirmed that this is indeed a genuine technical limitation.

Recommendations for an optimal experience