For example, Windows Server with Desktop Experience is a superset of Server Core,
which is a superset of Nano Server, so it can therefore use Server Core or Nano Server
base OS images. Server Core has all of the APIs in Nano Server, so a Server Core
container host can run either type of base OS image; however, Nano Server does not
contain all of the APIs of Server Core and can therefore run only base OS images that
are Nano Server. Microsoft provides these two container base OS images (Windows
Server Core and Nano Server), which can be obtained via PowerShell or through the
Docker Hub.
It is because of Hyper-V containers that Microsoft added nested virtualization in
Windows Server 2016. Nested virtualization enables a container host to be a virtual
machine and still support the VM-dependent Hyper-V containers.
An important point to understand is that within a Hyper-V container is a regular
Windows container along with any containers it depends on and the base OS image.
The application container is not a different type of container for Hyper-V containers.
The choice to use a Windows container vs. a Hyper-V container is a deployment time
decision, depending on whether user-level or kernel-level isolation is required. This is
no major difference in the creation of the container. The only difference is that at
deployment time you would specify --isolation=hyperv to create a Hyper-V container
instead of a Windows container. If using containers in Windows 10, Hyper-V isolation
is the default and only option, which means the --isolation=hyperv is not explicitly
required.
For the maximum density, you would use Windows containers; for the maximum
isolation, you would use Hyper-V containers.
DRIVERS AND CONTAINERS
It is not possible to install drivers in a container image. Container instances can
utilize drivers in the base OS image, but no other container images can include
drivers.