Containers vs Virtual Machines

A virtual machine virtualizes hardware. A hypervisor carves a physical host into VMs, each with its own emulated CPU, memory, and devices, and each boots a full guest operating system with its own kernel. A container virtualizes the operating system instead: it is a process running on the host's kernel, handed an isolated view of the system, with no guest OS to boot at all.

That single architectural difference — own kernel versus shared kernel — explains almost everything that follows. It is why a VM takes tens of seconds to start and a container takes milliseconds, why a VM image is gigabytes and a container image is megabytes, and why a VM's isolation is stronger than a container's. The two are not rivals so much as different points on the weight-versus-isolation curve.

The Stack, Side by Side

Stack a VM from the bottom: physical hardware, then a hypervisor, then for each VM a full guest kernel, its userland of libraries and binaries, and finally the application. Stack a container: physical hardware, the host's single kernel, then for each container just its userland and the application. The container stack is missing two whole layers — the hypervisor and the per-instance guest kernel — and those two missing layers are the entire story of why containers are light.

Shared Kernel, Separate Userland

Every container on a host shares that host's one kernel, but each carries its own userland — its own libraries, its own coreutils, its own view of the filesystem. This is why a container built on Ubuntu userland runs fine on a host running a different distribution: the kernel is shared and compatible, while the userland that differs travels inside the image. What a container cannot do is run a userland that needs a different kernel — the kernel is the host's, and there is exactly one.

Weight and Startup

A VM image carries a whole operating system, so it is measured in gigabytes and "starting" it means booting that OS — initializing devices, starting init, bringing up services — which takes tens of seconds. A container image carries only the app and its userland, so it is measured in tens to hundreds of megabytes, and "starting" it means forking a process the kernel fences off, which takes milliseconds. That ratio is why you run dozens of containers on a host that would hold a handful of VMs, and why autoscaling containers feels instant where autoscaling VMs feels slow.

The Isolation Trade-off

The VM's boundary is enforced in hardware by the hypervisor; the container's boundary is enforced in software by the host kernel. The hardware boundary is stronger. A kernel exploit inside a container can, in principle, reach the host and every other container sharing that kernel, in a way a guest-kernel exploit cannot cross a hypervisor. This is why genuinely untrusted or hard multi-tenant workloads sometimes still run in VMs, or in VM-backed container runtimes that deliberately put a hypervisor back under the container interface — you trade some startup speed for a harder wall.

Why Docker Desktop Runs a VM

Linux containers need a Linux kernel to share, and macOS and Windows do not have one. So Docker Desktop quietly runs a lightweight Linux virtual machine, and your containers live inside it — the "host kernel" they share is the VM's kernel, not your laptop's. On a Linux machine there is no such layer; containers run directly on the machine's own kernel.

This hidden VM is invisible most of the time and then suddenly relevant. It is why a container cannot see your Mac's processes, why bind-mount file I/O is slower on Docker Desktop than on native Linux (it crosses the VM boundary), and why "it's fast on the server but sluggish on my laptop" is a common and expected gap. Knowing the VM is there turns those surprises into predictable consequences.