An option with Windows Containers is to run a container in Hyper-V Isolation Mode. This blog shows what happens when we do this.
When we run a container normally, the processes running in the container are running on the kernel of the host. The Process ID and the Session ID of the container process are the same as on the host.
When we run a container in Hyper-V Isolation Mode, a utility VM is created and the container runs within that. We need to have the Hyper-V role installed on the host. Then we need to add --isolation hyperv to the docker run command.
Here are some of the main differences.
The processes in the container are isolated from the host OS kernel. The Session 0 processes do not appear on the host. Session 1 in the container is not Session 1 on the host, and the Session 1 processes of the container do not appear on the host.
Container:
Host:
There is no mounted Virtual Hard Disk (VHD):
Instead we have a set of processes for the Hyper-V virtual machine:
A set of inbound rules is not automatically created on the host Windows firewall. There are no rules for ICC, RDP, DNS, DHCP as there are when we create a standard container:
But the container is listening on port 135, and we can connect from the host to the container on that port, as we can with a standard container:
And if we create another, standard, container, they each respond to a ping from the other.
Hyper-V does not add to the manageability of containers. The Hyper-V containers do not appear in the Hyper-V management console.
So in summary: in Hyper-V Isolation Mode the container processes are fully isolated; but the container is not on an isolated network, and is still open to connections from the host and from other containers by default.