For a Windows container, how do --isolation=process and --isolation=hyperv differ?
answer
- One mode borrows a kernel, one brings one
- Ask what each container costs to start
- Version matching only binds one of them
- Server and client hosts default differently
- Job objects versus a utility virtual machine
basics
~20 sWith --isolation=process a Windows container's processes run directly on the host's Windows kernel, so it starts fast and uses little memory but its base image build must match the host's. With --isolation=hyperv each container gets its own lightweight virtual machine and kernel, costing startup time and memory but removing that matching requirement.
solid answer
~50 sBoth flags describe how a Windows container is separated from the host. `--isolation=process` is the mode that behaves like a Linux container: the container's processes are ordinary host processes with their own object namespace, filesystem view and job-object limits, running on the host's Windows kernel. It starts in a second or two and adds no per-container kernel memory, but because it borrows the host kernel, the base image's Windows build must match the host's build. `--isolation=hyperv` boots a purpose-built, minimal virtual machine per container and runs the container inside it, so the container carries its own kernel. That buys a hardware-enforced boundary and lets an image built for an older Windows build run on a newer host, at the cost of noticeably slower start and a fixed memory overhead per container. `--isolation=default` follows the daemon's default, which is process isolation on Windows Server and Hyper-V isolation on Windows client editions.
code
bash · 3 linesdocker run --rm --isolation=process mcr.microsoft.com/windows/servercore:ltsc2022 cmd /c ver
docker run --rm --isolation=hyperv mcr.microsoft.com/windows/servercore:ltsc2022 cmd /c ver
docker inspect --format '{{.HostConfig.Isolation}}' recon-batchgo deeper
Recall that Windows containers have two isolation modes and that --isolation=hyperv gives each container its own kernel inside a small VM while --isolation=process uses the host's kernel. Know the flag exists on docker run.
Explain the mechanics: job objects and a private object namespace under process isolation, a utility VM under Hyper-V isolation, and why only the first requires the image build to match the host build.
Demonstrate the operational tradeoff with numbers: startup latency, per-container memory for the extra kernel, density on a host, and using Hyper-V isolation as a temporary bridge while base images are rebuilt after a host upgrade.
Own the fleet-level choice: which workloads justify a hypervisor boundary, whether nested virtualization is available on your instance types, and how the isolation default differing between developer laptops and servers should be normalised.
## Two ways to run the same image A Windows container image is the same artefact in either mode; only the enforcement mechanism changes. The mode is chosen per container at run time: ``` docker run --isolation=process mcr.microsoft.com/windows/servercore:ltsc2022 cmd /c ver docker run --isolation=hyperv mcr.microsoft.com/windows/servercore:ltsc2022 cmd /c ver ``` and read back afterwards with `docker inspect --format '{{.HostConfig.Isolation}}' <container>`. ## Process isolation Under process isolation the container's processes are real processes in the host's process table. They share the host's Windows kernel and are separated by kernel constructs: a private object namespace so the container sees its own registry view, device map, named pipes and session; a virtualised filesystem view assembled from the image layers; and a job object that carries the CPU, memory and I/O limits you set with `--cpus` or `--memory`. This is the direct analogue of how a Linux container works, and it has the same performance profile: a container starts in about a second, adds no kernel of its own, and the memory it consumes is just the memory its processes touch. The price is compatibility. Because the container's user-mode binaries call straight into the host kernel, they must be the binaries that kernel expects. Windows enforces this: the image's `OsVersion` build number must match the host's build. An `ltsc2019` image (build `10.0.17763.x`) will not process-isolate on a Windows Server 2022 host (build `10.0.20348.x`); the container fails to start with `The container operating system does not match the host operating system.` Differences in the fourth component, the revision, are tolerated on Windows Server 2019 and later, so a host patched to a newer revision than the image was built against still works. ## Hyper-V isolation Under Hyper-V isolation the engine boots a minimal utility virtual machine and runs the container inside it. The container gets its own kernel, loaded from the image, and the boundary between it and the host is the hypervisor rather than kernel object namespaces. Two things follow. First, version compatibility largely disappears. Because the kernel comes from the container image rather than from the host, an older base image can run on a newer host; this is the standard bridge when a host fleet is upgraded ahead of the images. Second, the isolation boundary is stronger and the cost is real. Startup goes from roughly a second to several, since a VM has to boot before the entrypoint runs. Each container reserves memory for its own kernel, so density drops sharply; running dozens of Hyper-V-isolated containers on one host is a very different capacity calculation from running dozens of process-isolated ones. The host must also have the Hyper-V platform available, and if the host is itself a virtual machine, nested virtualization must be enabled by the platform underneath it, which not every cloud instance type offers. ## Defaults, and where each is used `--isolation=default` means "whatever the daemon is configured to do". On Windows Server that is process isolation; on Windows client editions, Hyper-V isolation is the default and is what a developer laptop normally uses. That difference is a classic source of "it works on my machine": a container that starts in eight seconds on a developer's client Windows machine starts in one on the Server host, and one that a developer never had to version-match starts failing when it lands on a Server host running process isolation. The practical selection rule is: process isolation for production density and startup latency, where you control the host build and rebuild base images along with the OS; Hyper-V isolation where you need a stronger boundary for less trusted workloads, or where you must run an image whose Windows build does not match the host and rebuilding is not immediately possible. ## What the flag does not change The mode does not change the image format, the registry protocol, the Dockerfile, the network drivers you can attach, or the CLI. It does not let a Windows engine run Linux images, and it does not make a Windows image smaller. It also does not silently fall back: if you ask for process isolation with a mismatched image, the run fails rather than quietly switching to Hyper-V. ## Summary Process isolation shares the host kernel: fast, dense, and strictly version-matched. Hyper-V isolation gives each container its own kernel inside a small VM: slower and heavier per container, but a stronger boundary and free of the build-matching rule. Knowing which one a given host defaults to is usually the first thing to check when a Windows container behaves differently between a laptop and a server.
- Which isolation mode do you pick for a container density target, and why?Process isolation, almost always. Each Hyper-V-isolated container reserves memory for its own kernel and takes seconds rather than about a second to start, so density and cold-start latency both fall. Hyper-V isolation is worth that when the workload is untrusted or when the image's Windows build does not match the host and rebuilding is not yet possible.
- A container starts in eight seconds on a developer's Windows laptop and in one second on the Windows Server host. What explains that?The default isolation mode differs by edition. Client Windows defaults to Hyper-V isolation, which boots a small utility VM before the entrypoint runs; Windows Server defaults to process isolation, where the container's processes start directly on the host kernel. Pass `--isolation` explicitly if you want the two environments to behave the same.
- Does Hyper-V isolation change how you set CPU and memory limits?The flags are the same, `--cpus` and `--memory`, but what enforces them differs: process isolation applies them through a host job object, while Hyper-V isolation sizes the utility VM. Under Hyper-V isolation you are also paying for the container's own kernel on top of whatever the application uses, so the same `--memory` value leaves the application less headroom in practice.
Process isolation is a locked room in the host's own building; Hyper-V isolation is a prefabricated cabin dropped in the yard, which is why it can be a different vintage from the building.
saying these in an interview costs you the question
- Says both modes give the same isolation strength
- Thinks Hyper-V isolation runs Linux images on Windows
- Claims process isolation works with any base image
- Assumes the daemon falls back to Hyper-V on mismatch
- Believes Hyper-V isolation has no startup or memory cost
- Thinks the isolation mode changes the image format