Containers vs. VMs: What the Kernel Actually Isolates

The Core Mechanism: Shared Kernel vs. Emulated Hardware

A Virtual Machine (VM) runs a complete guest operating system on top of a hypervisor (like KVM or ESXi). The hypervisor emulates physical hardware—CPU instructions, network cards, storage controllers, and memory tables. This yields total isolation, but imposes steep overhead: every VM boots its own kernel, loads systemd, and reserves dedicated memory pages.

A Container is not a lightweight VM. It is simply a regular Linux process running directly on the host kernel, restricted by kernel primitives:

• Namespaces: Provide process-level isolation (PID, NET, MNT, IPC, UTS, USER). A process inside a container cannot see processes in sibling namespaces.
• cgroups (Control Groups): Enforce hardware resource boundaries (memory limits, CPU shares, I/O bandwidth).

+-----------------------+     +-----------------------+
|  App A   |   App B    |     |  App A   |   App B    |
| (Deps)   |  (Deps)    |     | (Deps)   |  (Deps)    |
+----------+------------+     +----------+------------+
| Docker Engine / Runc  |     | Guest OS | Guest OS   |
+-----------------------+     +----------+------------+
|  Host OS & Kernel     |     |      Hypervisor       |
+-----------------------+     +----------+------------+
|   Physical Hardware   |     |   Physical Hardware   |
+-----------------------+     +-----------------------+
     CONTAINERS                         VIRTUAL MACHINES

Key Takeaway

Use containers when you need fast boot times (<100ms), high density, and consistent execution layers. Use VMs when you require kernel-level security isolation (e.g. running untrusted multi-tenant code) or non-Linux OS execution.