Windows container requirements
This guides list the requirements for a Windows container Host.
- 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.
- Starting with Windows Server version 1709 Nano Server is no long avilable as a container host.
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 14393.321.amd64fre.rs1_release_inmarket.161004-2338
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.
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.