Containers vs. Virtual Machines

Both let you run a workload as if it had a machine to itself. Where they draw that boundary is completely different, and it's worth understanding before reaching for either one.

Containers: isolated processes, one shared kernel

┌─────────────── Host OS, one kernel ───────────────┐
│  ┌───────────┐   ┌───────────┐   ┌───────────┐    │
│  │ Container │   │ Container │   │ Container │    │
│  │    A      │   │    B      │   │    C      │    │
│  └───────────┘   └───────────┘   └───────────┘    │
└─────────────────────────────────────────────────────┘

A container is a set of ordinary Linux processes, made to look isolated using kernel features - it's not a separate machine or a separate kernel at all:

• Namespaces - give a process its own view of specific resources: a PID namespace so it sees only its own processes (its "PID 1" isn't the host's), a network namespace with its own interfaces and routing table, a mount namespace with its own filesystem view, and others for hostnames, users, and inter-process communication.
• cgroups (control groups) - limit and account for how much CPU, memory, and I/O a group of processes can use - see Process Priority and nice for the same mechanism used for a single process's scheduling priority.
• A layered filesystem image - typically overlayfs (see Filesystem Types), stacking read-only image layers under a thin writable layer per container.

Because there's no second kernel to boot and no hardware to emulate, a container starts in well under a second and adds negligible CPU/memory overhead beyond the workload itself. See Docker Basics for actually building and running one.

Virtual machines: a complete, separate machine

┌───────────────── Host OS + hypervisor ─────────────────┐
│  ┌────────────────┐  ┌────────────────┐                │
│  │  Guest kernel   │  │  Guest kernel   │                │
│  │  + full OS      │  │  + full OS      │                │
│  │  (VM A)         │  │  (VM B)         │                │
│  └────────────────┘  └────────────────┘                │
│         virtual hardware, per guest                     │
└───────────────────────────────────────────────────────────┘

A VM runs its own complete, independent kernel on top of virtualized hardware (a virtual CPU, virtual disk, virtual network card) presented by a hypervisor - on Linux, typically KVM. The guest has no more idea it's virtualized than a container has that it's sharing a kernel; it genuinely boots and runs like a standalone machine, just on emulated or hardware-accelerated virtual devices rather than physical ones. See KVM and libvirt.

Because a VM boots a full kernel and OS, startup takes tens of seconds rather than milliseconds, and each running VM carries the memory and CPU overhead of an entire second operating system - but that also means a VM can run a different kernel or OS entirely (a Windows guest on a Linux host, for instance), which no container can ever do.

Isolation strength is not the same

Containers isolate at the process level, sharing one kernel - a kernel vulnerability that lets a process escape its namespace potentially exposes the whole host, and every container. A VM's isolation boundary is the virtual hardware itself, enforced largely by the CPU's own virtualization extensions - a much stronger boundary, which is why running genuinely untrusted or multi-tenant workloads still leans on VMs (or, increasingly, hardened container runtimes designed specifically to close this gap, like gVisor or Kata Containers) rather than plain containers alone.

Choosing between them

In practice these aren't exclusive - it's routine to run containers inside a VM, getting a VM's strong isolation boundary around a host that then runs many lightweight containers on top of it, which is exactly what most cloud-hosted container platforms do.