VM vs Container: Where the Boundary Is

A virtual machine is a guest operating system running on virtual hardware. The hypervisor (KVM in the Linux kernel, Hyper-V, Xen, or a type-2 hypervisor such as VMware Workstation) presents virtual CPUs, virtual memory, a virtual disk and a virtual NIC. The guest kernel manages its own processes, page tables and drivers exactly as on real hardware; the CPU’s virtualisation extensions (VT-x, AMD-V) let guest code run natively while trapping privileged operations, and nested page tables (EPT) translate guest-physical to host-physical addresses with hardware help. A guest syscall never reaches the host kernel; a guest kernel panic is the guest’s problem.

A container is a process tree on the host kernel with namespaces, cgroups and an overlay root (Containers Are Processes With the Kernel’s View Narrowed). There is no second kernel, no virtual hardware and no hypervisor: syscalls go straight to the host kernel, memory is host memory with cgroup accounting, the “disk” is a directory. What isolates the container is the kernel’s own permission checks — and only those.

The columns of the matrix fall out of the stacks. Isolation strength is about how much code sits between an exploit and the host: the whole guest kernel plus a hypervisor with a small device surface, versus the host kernel’s syscall checks. Startup time is booting a kernel versus fork+exec. Density is memory: a guest kernel plus its page cache plus idle daemons costs hundreds of MB before the workload runs, and its RAM is hard to reclaim (ballooning helps, slowly); a container costs its own RSS. Kernel choice is the one thing only a VM gives you — a different kernel version, a different OS entirely, custom modules. Overhead on the hot path is small for both on modern hardware, but VM I/O crosses two kernels and one virtual device.

The numbers are order-of-magnitude, not benchmarks, and they move with hardware: a conventional VM boots in seconds to tens of seconds and holds hundreds of MB; a container starts in tens to hundreds of milliseconds and holds only what the process allocates; a microVM (next section) boots in ~100–200 ms with a few MB of overhead.

Firecracker (AWS, open source) is a stripped-down VMM on KVM: no BIOS, no PCI enumeration, five virtio devices, a minimal guest kernel configuration. It boots a Linux guest in about 125 ms with under 5 MB of VMM overhead and is designed to be started thousands of times per second — it is what runs AWS Lambda and Fargate, and it is the usual answer for “run untrusted code with a real kernel boundary but container-like startup”. Each function or sandbox gets its own guest kernel; a kernel exploit inside lands in a throwaway VM. Kata Containers wraps the same idea in the container interface, so Kubernetes can schedule a pod that is secretly a microVM.

gVisor (Google) takes the other road. Its Sentry is a kernel written in Go that runs in user space and *intercepts* the container’s syscalls (via ptrace or, faster, as a KVM guest), implementing them itself and touching the host kernel through a deliberately small set of about 50 syscalls. There is no guest OS to boot; the container image and workflow are unchanged; startup is close to a container’s. The cost is compatibility (not every syscall or feature is implemented) and syscall-heavy workloads paying an interception tax. It is the sandbox behind Cloud Run and GKE Sandbox, and the usual choice when you want defence in depth without changing how containers are built.

Neither is free. Firecracker pays memory and I/O virtualisation; gVisor pays syscall latency and compatibility. Both exist because the honest answer to “is a container safe enough for hostile code?” is *no*, and the honest answer to “is a full VM cheap enough for a function that runs for 40 ms?” is also *no*.

An AI agent that runs generated code, executes shell commands or installs packages is the textbook untrusted workload: the code was written by a model, possibly under the influence of a prompt injection, and it must not reach the host, other users’ data or the credentials the agent holds (Tool Permissions and Least Privilege, Tool Misuse and Data Exfiltration). “Sandbox” in that domain means one of the boundaries on this page. Most code-execution sandboxes use Firecracker microVMs or gVisor: a fresh kernel-level boundary per session, started in a fraction of a second, discarded afterward, with the network namespace configured to reach only what the tool is allowed to reach. A plain container with --privileged or a mounted Docker socket is not a sandbox; it is the host with extra steps.

Cloud platforms expose the same three tiers under product names. EC2 instances and Compute Engine VMs are hardware VMs on KVM/Nitro. ECS and GKE pods are containers on VMs you (or they) own. Lambda, Fargate and Cloud Run are microVMs or gVisor sandboxes — which is why a cold start is ~100 ms rather than ~10 ms, why you cannot load a kernel module, and why two functions from different accounts can safely share a physical host.