Windows support for the VM compute driver (Linux microVM sandboxes via WHP) #5008

User Story

I use OpenShell to run AI agent workloads in microVM sandboxes on Unix hosts, and I'm part of the team building Kaiden, a desktop workspace for local AI agents that ships to Windows, macOS, and Linux. I also maintain libkrun, the microVM runtime the OpenShell VM driver is built on, and i have added Windows support (WHP) to it (it will be available with libkrun 2.0), which is what makes this proposal possible now.

RFC 0013's MXC driver gives Windows-native agents OS-level, unelevated isolation, and it's the right tool for Windows processes. But most of my agents' toolchains are Linux-native, and some deployments require a per-sandbox kernel boundary. On Unix I use the VM compute driver for exactly that; on Windows there is no equivalent without standing up WSL2 or a nested Linux runtime underneath the gateway.

Problem Statement

RFC 0013 gave Windows one native compute driver: MXC, an AppContainer-based process-isolation tier for Windows workloads. What Windows still lacks is the other tier that Linux has: the libkrun VM driver, which runs each sandbox in its own Linux microVM with a kernel isolation boundary and the full in-guest supervisor policy stack. Two gaps result: (1) workloads that need a virtualization boundary rather than process isolation have no native Windows path, and (2) agents with Linux-native toolchains cannot get a genuine Linux sandbox environment on Windows without WSL2 or a nested-Linux gateway.

Impact / Why This Matters

Without the VM tier on Windows, users who need kernel-isolated or Linux-environment sandboxes must run a Linux gateway inside WSL2/a VM and double-virtualize every sandbox (heavy setup for desktop users, operational burden for fleets), or keep those workloads on Linux machines entirely.

Policy fidelity also improves compared to MXC layer. The VM driver enforces policy through the same cross-platform code paths as Unix. The supervisor's CONNECT proxy (OPA, L7, credential injection) using guest-supplied binary identity, and the unchanged in-guest openshell-sandbox running in the Linux guest, with no translation layer. The POC i made to test its feasibility has two known Windows divergences: the SSH relay peer-PID check (Unix SO_PEERCRED) is replaced by filesystem ACLs on the host socket directory because WinSock AF_UNIX exposes no peer credentials, and upstream DNS resolver discovery uses the default-route adapter rather than /etc/resolv.conf.

Proposed Design

Enable the existing VM compute driver on Windows x64 (WHP-backed) as a sibling of MXC, selectable through the same driver configuration, with the same user surface as on Unix:

openshell gateway --compute-driver vm

• openshell sandbox create / connect / exec behave as they do with the Unix VM driver: a Linux microVM per sandbox, immutable OCI-image rootfs with a per-sandbox writable overlay, mTLS-authenticated supervisor channel over virtio-vsock, egress policy enforced by the in-guest supervisor stack.
• Driver integration follows each driver's existing shape, unchanged by this proposal: the VM driver stays a separate openshell-driver-vm binary that the gateway spawns over an authenticated local socket, exactly as on Unix. A Windows deployment ships the driver binary alongside the gateway, matching Unix VM deployments. Driver selection is per-deployment configuration (--compute-driver vm or gateway config).
• The current compile-time "VM unsupported on Windows" stub is replaced by real support; Docker/Podman/Kubernetes stubs are unchanged.
• User-visible prerequisites: WHP enabled, with a clear error if missing; no WSL2, Docker Desktop, or nested-Linux requirement.

GPU access inside VM sandboxes on Windows is out of scope. The future path for in-sandbox GPU on Windows would be WHP GPU partitioning in libkrun; listed as potential follow-up work, not a dependency of this proposal. On Unix, VM-driver GPU uses VFIO passthrough with root and IOMMU requirements, none of that is proposed for Windows.

Acceptance Criteria

• On a Windows x64 host with WHP, a gateway built with compute-driver-vm can create, connect to, exec in, and tear down Linux VM sandboxes via CLI and SDK, using a user-chosen OCI image as rootfs
• Each sandbox runs in its own microVM with a per-sandbox writable overlay; teardown removes all per-sandbox state
• A policy parity test set (binary-scoped network rules, L7 rules, DNS-scoped rules, Landlock-backed filesystem rules) passes with the same allow/deny outcomes on Windows and Unix VM sandboxes
• Supervisor-enforced network allow/deny and L7 policy behave identically to the Unix VM driver
• MXC and VM drivers coexist in one Windows gateway build and are selectable per deployment
• The sandbox e2e scenario suite passes for the VM driver on the Windows CI lane
• Hosts without WHP produce clear, actionable errors; Windows ARM64 continues to report the existing unsupported-driver error
• Published docs cover prerequisites, configuration, and supported Windows versions

Alternatives Considered

• MXC (RFC 0013): the shipped Windows-native tier does not serve this proposal's use cases: AppContainer is process isolation rather than a virtualization boundary, it runs Windows rather than Linux workloads, and its policy translation is lossy by design. This proposal complements RFC 0013 rather than revising it; none of its D1–D4 decisions change.
• WSL2 / nested Linux gateway: works today, but reintroduces exactly the nested-Linux toolchain RFC 0013 sought to remove, and double-virtualizes every sandbox. In some cases it also requires elevation, which is unacceptable.

Agent Investigation

A working proof of concept exists on a local branch (not yet published):

• libkrun and libkrunfw run on Windows x64 against WHP, loaded as DLLs; the driver's FFI layer was restructured to support this
• Rootfs preparation uses ext4kit in place of e2fsprogs for ext4 root/overlay creation and OCI layer application — no WSL2 involvement
• The ComputeDriver gRPC surface uses a Win32 named pipe where AF_UNIX is unavailable; the driver keeps its existing subprocess shape, so the gateway↔driver boundary matches the Unix VM driver
• The guest-facing vsock/mTLS supervisor channel is unchanged; the host supervisor runs natively on Windows with small cfg-gated socket shims; the in-guest openshell-sandbox and openshell-vm-init build unchanged
• Gateway/CLI changes are #[cfg] gating on existing code paths; Unix behavior is untouched
• The full sandbox lifecycle works end-to-end in the POC on Windows 11 x64

Checklist

• I've reviewed existing issues and the published docs
• This is a design proposal, not a "please build this" request