VM vs Container Isolation Lab (Interactive)
Swap hypervisor, shared-kernel, or microVM boundaries and recompute packing density and boot latency. Pack workloads onto one host under Type 1/2 VMs, containers, or Firecracker microVMs and watch overhead, density and safety diverge.
VMs vs Containers: Kernel Primitives & Packing Physics
Swap the isolation boundary — hypervisor, shared kernel, or microVM — and recompute boot latency, RAM overhead and density on one host.
Cold-boot 400 workloads
1s
Max packable on host
421
Runtime overhead burned
4.7 GB
CPU virtualization tax
0.05% (0.1 cores)
Isolation boundary
Shared host kernel: Namespaces + cgroups v2
All processes share one host kernel — a Dirty-COW-style privilege escalation or a mounted docker.sock breaks out every tenant on the node.
Untrusted multi-tenant code?
❌ Not safe
Vanilla containers must not run arbitrary customer code — escalate to Firecracker microVMs or a gVisor runsc sandbox instead.
How It Works Under the Hood
A VM virtualizes hardware through a hypervisor and boots a whole guest kernel; a container is just a Linux process fenced by Namespaces (what it can see) and cgroups (what it can use) over an OverlayFS copy-on-write root. That difference is physical: containers boot in tens of milliseconds with single-digit MB overhead and pack 500-2,000 per host, while VMs cost seconds-to-minutes and a gigabyte each but enforce a Ring-0 hardware boundary. Because containers share the host kernel, a privilege-escalation CVE escapes every tenant on the node, so untrusted multi-tenant code needs Firecracker or gVisor instead.
Core Architectural Principles
- Namespaces isolate visibility (PID, NET, MNT, IPC, UTS, USER) while cgroups v2 meter CPU, memory and block I/O.
- Container cold-boot is 10-100 ms with ~12 MB overhead versus 30-180 s and 1-4 GB for a VM guest kernel.
- Exceeding cgroup memory.max triggers the OOM Killer SIGKILL (exit code 137); untrusted code needs a microVM hardware boundary.
Say plainly that a container is a namespaced, cgroup-limited process, not a mini-VM, and name OverlayFS copy-on-write as the reason startup needs no disk clone. When asked to run untrusted customer code, reject vanilla containers and propose Firecracker microVMs or gVisor because the shared kernel is a single breakout domain. Quantify density and boot latency to show you know the physics.
Containers buy 10-50x density and near-instant scaling but share one host kernel, so isolation strength trails hardware virtualization unless you add microVMs.