Windows container requirements

This guides list the requirements for a Windows container Host.

OS Requirements

  • The Windows container feature is only available on Windows Server build 1709, Windows Server 2016 (Core and with Desktop Experience) and Windows 10 Professional and Enterprise (Anniversary Edition).
  • The Hyper-V role must be installed before running Hyper-V Containers
  • Windows Server Container hosts must have Windows installed to c:. This restriction does not apply if only Hyper-V Containers will be deployed.

Virtualized Container Hosts

If a Windows container host will be run from a Hyper-V virtual machine, and will also be hosting Hyper-V Containers, nested virtualization will need to be enabled. Nested virtualization has the following requirements:

  • At least 4 GB RAM available for the virtualized Hyper-V host.
  • Windows Server build 1709, Windows Server 2016, or Windows 10 on the host system, and Windows Server (Full, Core) in the virtual machine.
  • A processor with Intel VT-x (this feature is currently only available for Intel processors).
  • The container host VM will also need at least 2 virtual processors.

Supported Base Images

Windows Containers are offered with two container base images, Windows Server Core and Nano Server. Not all configurations support both OS images. This table details the supported configurations.

Host Operating System
Windows Server Container
Hyper-V Container
Windows Server 2016 (Standard or Datacenter)
Server Core / Nano Server
Server Core / Nano Server
Nano Server*
Nano Server
Server Core / Nano Server
Windows 10 Pro / Enterprise
Not Available
Server Core / Nano Server

  • Starting with Windows Server version 1709 Nano Server is no long avilable as a container host.

Memory requirments

Restrictions on available memory to containers can be configured though resource controls or by overloading a container host. The minimum amount of memory required to launch a container and run basic commands (ipconfig, dir, etc...) are listed below. Please note that these values do not take into account resource sharing between containers or requirments from the application running in the container.

Windows Server 2016

Base Image Windows Server Container Hyper-V Isolation
Nano Server 40MB 130MB + 1GB Pagefile
Server Core 50MB 325MB + 1GB Pagefile

Windows Server version 1709

Base Image Windows Server Container Hyper-V Isolation
Nano Server 30MB 110MB + 1GB Pagefile
Server Core 45MB 360MB + 1GB Pagefile

Nano Server vs. Windows Server Core

How does one choose between Windows Server Core and Nano Server? While you are free to build with whatever you wish, if you find that your application needs full compatibility with the .NET Framework, then you should use Windows Server Core. On the other side of the coin, if your application is built for the cloud and uses .NET Core, then you should use Nano Server. This is because Nano Server was built with the intention of having as small a footprint as possible therefore several nonessential libraries were removed. This is good to keep in mind as you think about building on top of Nano Server:

  • The servicing stack was removed
  • .NET Core is not included (though you can use the .NET Core Nano Server image)
  • PowerShell was removed
  • WMI was removed

These are the biggest differences and not an exhaustive list. There are other components not called out which are absent as well. Keep in mind that you can always add layers on top of Nano Server as you see fit. For an example of this check out the .NET Core Nano Server Dockerfile.

Matching Container Host Version With Container Image Versions

Windows Server Containers

Because Windows Server Containers and the underlying host share a single kernel, the container’s base image must match that of the host. If the versions are different the container may start, but full functionally cannot be guaranteed. Therefore mismatched versions are not supported. The Windows operating system has 4 levels of versioning, Major, Minor, Build and Revision – for example 10.0.14393.0. The build number only changes when new versions of the OS are published. The revision number is updated as Windows updates are applied. Windows Server Containers are blocked from starting when the build number is different - for example 10.0.14300.1030 (Technical Preview 5) and 10.0.14393 (Windows Server 2016 RTM). If the build number matches but the revision number is different, it is not blocked from starting - for example 10.0.14393 (Windows Server 2016 RTM) and 10.0.14393.206 (Windows Server 2016 GA). Even though they are not technically blocked, this is a configuration that may not function properly under all circumstances and thus cannot be supported for production environments.

To check what version a Windows host has installed you can query HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion. To check what version your base image is using you can review the tags on the Docker hub or the image hash table provided in the image description. The Windows 10 Update History page lists when each build and revision was released.

In this example 14393 is the major build number and 321 is the revision.

Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. All rights reserved.

PS C:\Users\Administrator> (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\').BuildLabEx

Hyper-V Isolation for Containers

Windows Containers can be run with or without Hyper-V isolation. Hyper-V isolation creates a secure boundary around the container with an optimized VM. Unlike standard Windows Containers, which share the kernel between containers and the host, each Hyper-V isolated container has its own instance of the Windows kernel. Because of this you can have different OS versions in the container host and image (see compatibility matrix below).

To run a container with Hyper-V isolation, simply add the tag "--isolation=hyperv" to your docker run command.

Compatibility Matrix

Windows Server builds after 2016 GA (10.0.14393.206) can run the Windows Server 2016 GA images of both Windows Server Core or Nano Server in a supported configuration regardless of the revision number.

It is important to understand that in order to have the full functionality, reliability and security assurances provided with Windows updates you should maintain the latest versions on all systems.