Windows Server Containers: Hyper-V Handles Supported Build Mismatches

Four Windows-Containers Issues, #649 Through #652, Map the Parity Gap​

The requests are numbered #649 through #652. The GitHub user steskalja filed all four and promoted them in a Windows Server Insiders post on Microsoft Tech Community, asking readers to upvote them so that Windows containers become "as capable as Linux containers." On the day they were filed, each issue carried the "enhancement" and "triage / New and needs attention" labels. None had an assignee, a milestone, a project, or a linked branch or pull request. Nothing public shows Microsoft accepting, scheduling, or even commenting on any of them.

All four requests concern process-isolated containers. In this mode, Windows containers share the host's NT kernel inside a boundary Windows calls a server silo. This is the Windows mode that works most like Linux containers. The other mode is Hyper-V isolation, which Microsoft's isolation-mode documentation describes as running each container inside of a highly optimized virtual machine so that it effectively gets its own kernel. Each ticket names Hyper-V isolation as a workaround and rejects it as a real fix because of the cost of running a VM per container.

The author deliberately split the work into narrow tickets. The first issue explains that each gap has a different "owner surface": the Host Compute Service (HCS), containerd and its runhcs shim, or the Windows kernel team. The same issue says full user namespaces (UID remapping for rootless containers) and cgroups v2-style pressure-stall telemetry are related gaps that are being tracked separately. They are not part of these four requests.

Issue #649 Asks for Seccomp and Capabilities in Windows Server Silos​

The first ticket is the one its author calls the "highest-leverage" item. Linux containers can run under a seccomp-bpf profile, which filters the system calls a process may make, and can drop individual POSIX capabilities. The issue argues that Windows process-isolated containers have nothing equivalent. Their per-container controls are job-object limits and restricted tokens, which the author calls coarse, all-or-nothing controls.

The request has three parts:

• A syscall or API allow-list or deny-list, enforced at the NT syscall or Win32 API layer for each silo, configured through the HCS container config and exposed through containerd's runhcs shim.
• A capability-style breakdown of the container's process token, with explicit grants such as binding to ports below 1024, creating symbolic links, or adjusting process priority. This would replace the current binary choice between a restricted token and a full token, so images can run as non-admin and still keep the one or two privileges they need.
• CRI/containerd support on Windows for Kubernetes' securityContext.seccompProfile and securityContext.capabilities, so Linux-oriented manifests either enforce equivalent policy on Windows nodes or fail validation explicitly.

The author's security argument is that a compromised process in a shared-kernel Windows container has a much larger attack surface than a Linux container running a default seccomp profile. The ticket says this is why security teams push workloads to Hyper-V isolation by default. It also says host-level WDAC and AppLocker policies can't express per-instance rules, because they apply host-wide or per image rather than per silo. These are the author's arguments, not measured findings.

One claim in #649 needs a correction. The ticket says Kubernetes manifests that set seccompProfile are "silently ignored" on Windows nodes. Kubernetes' own Windows documentation describes a stricter contract: it lists seccompProfile and capabilities among the fields Windows Pods must not set, and says setting those listed fields prevents the Pod from being admitted by the API server. The real situation may depend on how a cluster identifies a Pod as Windows. Even so, the upstream documentation treats these fields as unsupported and rejected for Windows Pods, not as a quiet no-op. The practical gap the author describes still stands: Windows nodes can't enforce the least-privilege syscall and capability policies that Linux nodes in the same cluster can.

Issue #650 Wants a Real PID 1 Inside Windows Containers​

The second ticket deals with process visibility and lifecycle. On Linux, a PID namespace gives a container its own process numbering. The entrypoint is PID 1, it reaps orphaned child processes, and it receives the signal for a container-wide shutdown. The issue says server silos don't provide a fully isolated equivalent, and that process enumeration inside a Windows container "can still reflect host-relative process state."

The requested behavior is specific. Process-enumeration interfaces used inside the container, such as NtQuerySystemInformation, Get-Process and Task Manager, would return only the silo's processes, with PIDs renumbered starting at 1 for the entrypoint. A container stop would send its termination signal to that PID 1, and orphaned descendants would be reparented and reaped inside the silo. The ticket also asks for this to be a silo capability that containerd and runhcs can query, so CRI can report accurate process-tree information without falling back to host-relative data.

The author gives two reasons. The first is portability: entrypoint scripts and process supervisors ported from Linux images that rely on PID 1 behavior act differently or need Windows-specific workarounds. The second is security: the ticket argues that host PID visibility from inside a container gives a compromised process more information about sibling workloads on the same node. That is the author's framing of a potential information-disclosure risk, not a reported vulnerability.

The ticket also explains why the obvious workarounds fall short. A tini-style init shim built into base images can handle signal forwarding and zombie reaping in user mode today, but it can't hide other processes from enumeration, which needs kernel or silo-level support. Hyper-V isolation gives a real PID namespace "for free," in the issue's words, but at the full cost of a VM per container. Kubernetes' Windows documentation reflects the same gap from the orchestrator's side: hostPID and shareProcessNamespace are among the fields Windows Pods must not set, and the PIDPressure node condition is not implemented on Windows nodes.

Issue #651 Targets CimFS Layer Composition and Memory Sharing​

The third ticket is about image-layer storage. On Linux, overlayfs combines a container's read-only image layers with a writable upper layer at mount time. A file is copied up on its first write, and every container using the same base layer shares one copy of that layer's pages in the page cache. The issue says Windows image layers are "still fundamentally VHD/reparse-point-based" even where CimFS (Microsoft's composite image file system) is used for the read-only layer store.

According to the ticket, this causes three problems: slower create and start times for images with deep layer stacks, weaker page-cache sharing when many containers run from the same base image (which reduces density), and less predictable performance when a workload first writes to a file inherited from a lower layer. The ticket gives package managers and log rotation into inherited directories as examples of workloads affected by that last problem.

The ticket includes no benchmark numbers, so these comparisons are motivation rather than measurement. The requests are built to fix that:

• Extend CimFS, or a successor, to provide union-mount semantics for the full layer stack, with a writable upper layer over CimFS-backed lower layers and copy-up cost equivalent to overlayfs.
• Guarantee that read-only layer pages are shared in memory across containers on a host, and expose a documented metric (such as working-set pages attributable to a shared layer versus per-container private pages) so the guarantee can be tested.
• Publish cold-cache and warm-cache create/start latency benchmarks for a representative multi-layer image, such as a typical .NET or Node base plus app layers, compared against an equivalent Linux overlayfs container, and repeat them each release.

The workarounds the author lists will be familiar to anyone running Windows nodes at scale. Pre-warming idle containers hides start latency but does nothing for memory sharing. Flattening images into fewer, larger layers lowers composition cost but works against layering practices meant to maximize reuse. The ticket acknowledges that the current CimFS-for-read-only-layers design is already an improvement over the older VHD-only model.

Issue #652 Takes On the Host/Image Version Lockstep​

The fourth ticket addresses the most concrete of the four constraints, because Microsoft's documentation enforces it today. Issue #652 states that process-isolated Windows Server containers require the container base image's kernel-mode-facing API version to match the host OS build (or fall within the narrow compatibility window Microsoft publishes per release). It contrasts this with Linux, where a single host kernel runs userland from effectively any distro/version because Linux containers depend only on the stable syscall interface.

Microsoft's version-compatibility page confirms the rule: with the exception of WS2022 + Windows 11, Windows Server containers are blocked from starting when the build number between the container host and the container image are different. The rule concerns the build number, not monthly patches. Microsoft explains that the build number only changes when new versions of the OS are published, and the revision number is updated as Windows updates are applied. Its update guidance adds that as long as host and image are both Windows Server version 1809 or later, the host and container image revisions don't need to match for the container to start and run normally. In practice, the lockstep hits during OS version upgrades, such as moving hosts from Windows Server 2022 to Windows Server 2025, not during Patch Tuesday.

The client-side exception is still limited. Microsoft says process isolation on Windows client is available in preview for Windows 11 with Windows Server 2022 images - with build number mismatch. For other mismatches, the documentation says compatibility between user mode and kernel mode is possible, but not guaranteed, and thus the container image will be prevented from running on the host. Microsoft's FAQ adds that process isolation on Windows 10 and 11 client hosts is, outside IoT editions, only meant for development and testing, and production should run on Windows Server.

When the rule is broken, the failure is immediate. The compatibility page documents the Docker error "The operating system of the container does not match the operating system of the host." The documented way around it is Hyper-V isolation, which provides the container with a set of matching Kernel binaries and does not depend on the version of the host. You request it with the tag --isolation=hyperv on docker run. Supported combinations are still limited by Microsoft's compatibility matrix.

Issue #652 describes the operational cost in fleet terms. According to the ticket, teams must rebuild and redeploy images in lockstep with host patching, or the container fails to start outright with a version-mismatch error rather than degrading gracefully. Shared CI infrastructure has to maintain separate node pools per version or use Hyper-V isolation everywhere. Its proposals include a near-term step that is modest enough to be realistic: when containerd or HCS detects an unsupported mismatch, automatically and transparently start the container under Hyper-V isolation instead of failing, with a clear log/event indicating why. The author admits this doesn't close the performance gap but converts a hard failure into a degraded-but-working path. The ticket also proposes letting images declare compatibility requirements through manifest metadata.

This request isn't new. A 2020 issue in the same repository, #36, complained that Windows containers are currently more or less strictly version bound to the same version as the host (process isolation) and asked for userland to work independently of the kernel version. Six years later the lockstep is still documented policy, with the Windows 11 and Windows Server 2022 preview as the main exception.

What These Proposals Mean for Windows Container Operators​

Nothing in these tickets changes how you run Windows containers today. The decision for administrators is whether to add their voice to the requests and how to plan around the constraints the tickets describe. Everything below is based on current, documented behavior, not on anything the proposals would deliver.

For security-sensitive multi-tenant workloads, Hyper-V isolation is still the documented stronger boundary. Microsoft describes it as offering enhanced security and broader compatibility between host and container versions. Independent guidance, such as a February 2026 OneUptime walkthrough, recommends process isolation as the default for performance-sensitive workloads and Hyper-V isolation for multi-tenant environments, mixed Windows version support, and compliance-sensitive deployments. The same guide notes the trade-off of additional resource overhead and slower startup times, which matter at scale.

For mixed Linux/Windows Kubernetes clusters, the useful step is to audit shared manifests. Security contexts written for Linux, including seccomp profiles, capabilities, hostPID and shareProcessNamespace, belong to fields that Kubernetes documents as unsupported for Windows Pods. Keep separate Windows-specific templates instead of assuming a single policy applies to both node pools.

For OS upgrades, treat the base image build number as a dependency of the host. Moving process-isolated workloads to a new Windows Server release means rebuilding images against the matching base image, running version-aware node pools during the transition, or temporarily running old images under Hyper-V isolation where the matrix supports it.

• Issues #649 through #652 are open, unassigned feature requests filed on September 22, 2026, not Microsoft commitments, and no release or date is attached to any of them.
• Kubernetes documents seccompProfile, capabilities, hostPID and shareProcessNamespace as fields Windows Pods must not set, so mixed-OS clusters need Windows-specific security templates.
• Process-isolated Windows Server containers won't start when host and image build numbers differ, apart from the Windows 11 plus Windows Server 2022 preview, while monthly revision differences are fine on 1809 and later.
• Adding --isolation=hyperv is the documented workaround for supported version mismatches, at the cost of per-container VM overhead and slower starts.
• A tini-style init shim can handle PID 1 signal forwarding and zombie reaping today, but it can't hide host processes from enumeration.
• The CimFS performance claims in #651 have no published benchmark numbers, so measure your own container start times and per-container memory before redesigning images around them.

The four tickets turn a vague complaint that Windows containers lag Linux into four problems with named owners: HCS policy, silo PID semantics, the CimFS layer driver, and version compatibility. Only the last is fully documented by Microsoft as current behavior, and it has the most modest near-term ask, an automatic fallback to Hyper-V isolation instead of a hard failure. Until someone at Microsoft triages these issues, the compatibility matrix and Kubernetes' list of unsupported Windows Pod fields remain the rules to plan around. The first concrete sign of progress would be an assignee, a label change, or a milestone appearing on #649 through #652.