Docker
Why are containers not just lightweight virtual machines?
Short answer
Because they share the host's kernel. A VM virtualises hardware and runs its own kernel; a container is an ordinary process with a restricted view of the same kernel everything else is using. Almost every practical difference follows from that one fact.
The constraint behind it
A virtual machine needs a hypervisor presenting virtual hardware, on which a complete guest operating system boots. That is why it takes tens of seconds to start and hundreds of megabytes to hold — you are booting an operating system.
A container needs none of that. It is a process the kernel has been asked to lie to: namespaces restrict what it can see (its own process tree, network interfaces, filesystem mounts) and cgroups restrict what it can use.
So a container starts in milliseconds because nothing boots. There is no kernel to initialise, no hardware to enumerate — the kernel is already running.
◈ If it were the other way
What that system would look like
If containers really were lightweight VMs, they would have their own kernels — and the two properties people value most would disappear.
Start-up would be measured in seconds, because a kernel would have to initialise. Density would collapse, because each container would carry an operating system. And you could run a Linux container on a Windows kernel directly, which you cannot.
The security story would improve, though. A VM's isolation boundary is the hypervisor, which is far narrower and better-hardened than a shared kernel's system call interface — which is precisely why lightweight VM runtimes exist for workloads that need a stronger boundary than a container gives.
◆ What it buys you
- Start-up in milliseconds, which is what makes autoscaling and per-request scheduling practical.
- Density: hundreds of containers per host, because they share one kernel and one page cache.
- Layer sharing. Ten images on the same base store that base once, so pulls are fast and disk use is sublinear.
◑ What it costs you
- Isolation is weaker, and the boundary is the system call interface — a very large surface. A kernel vulnerability is a container escape, which is why running as root inside a container matters so much more than it intuitively should.
- The kernel is shared, so it is not yours. Kernel modules, sysctls and kernel version are the host's, and a workload that needs a specific one needs a specific host.
- You cannot cross kernels. Linux containers on macOS or Windows run inside a hidden Linux VM, which is the source of a whole family of confusing filesystem and networking behaviours.
Where it bites in practice
In how resource limits are observed. A container is not a machine, so tools that read `/proc` see the *host's* CPU count and memory unless they are cgroup-aware. A runtime that sizes its thread pool or heap from that gets it badly wrong — and then gets OOM-killed for exceeding a limit it never knew about.
What comes next
Did this get you to an answer?
No text box on purpose — please do not paste production logs anywhere