A virtual machine carries its own complete operating system. A container shares the host kernel and packages only the application. That single difference explains everything else: why a container starts in a second and a VM takes a minute, why one is megabytes and the other gigabytes, and why a VM isolates a workload more strongly than a container does.
- VMs virtualize hardware. Containers virtualize the operating system
- A container cannot bring its own kernel, so no other OS
- The container boundary is the kernel, which is weaker
- Containers are rebuilt from an image, not patched in place
- They are not rivals: most containers run inside VMs
On this page
The distinctionThe one difference, and what it costs
Both virtualization technologies answer the same question: how do you run several workloads on one physical machine without letting them interfere with each other. They answer it at different layers.
Virtual machines virtualize the hardware. The hypervisor presents virtual processors, virtual memory, virtual disks and virtual network cards. The guest installs a complete operating system onto that pretend hardware, with its own kernel, its own drivers and its own resource scheduler, and each VM genuinely believes it has the physical hardware to itself.
Containers virtualize the operating system. There is one kernel, the host's, and a container is a set of processes the kernel deliberately keeps in the dark. Namespaces give them their own view of the process list, the network stack and the filesystem.
Control groups cap the resources they can consume. From inside, the environment resembles a machine. From the host, it is a group of ordinary processes with restricted visibility.
Every other difference between the two virtualization models follows from that.
Containers carry no kernel, no init system and no drivers, so an image is measured in megabytes and starting one means starting a process. Virtual machines carry an entire operating system, so they are measured in gigabytes and starting one means booting a machine.
And because the kernel is shared, containers cannot bring their own. Linux containers need a Linux kernel and Windows containers need Windows. When Docker appears to run Linux containers on a Mac or on Windows, the software is running a Linux VM underneath and putting the containers inside it.
IsolationIsolation, honestly
This is where the comparison of containers and VMs gets loose in marketing material, and it is worth being precise.
The isolation boundary for virtual machines is the hypervisor. It is a small piece of software, it has been attacked for two decades, and escaping from a guest to the host is a serious and rare class of security vulnerability.
The isolation boundary for containers is the kernel. The kernel is an enormous piece of software with an enormous system call surface, and a kernel vulnerability reachable from inside a container is potentially an escape. These are found regularly. They are patched regularly.
That does not make containers insecure, and it does mean they are a weaker security boundary than virtual machines. The practical consequences are specific.
Do not put mutually hostile workloads in containers on one kernel. Two containers from two customers who must not reach each other belong in separate virtual machines, which is exactly why every cloud provider runs untrusted container workloads inside one machine per tenant.
Your own applications on one kernel are fine. If every containerized workload on the host is yours and equally trusted, container isolation is proportionate to the security requirement.
A root process inside a container is a serious matter. By default, root in the container is root on the host system if it escapes. Run containers as a non root user, and use user namespaces where the platform supports them.
There is a middle option worth knowing. Firecracker, Kata Containers and gVisor give each container something closer to a VM boundary, at some cost in startup time and density. They are what cloud serverless platforms run underneath, precisely because the workloads there are untrusted.
WorkloadsWhat each one is actually good at
The choice between containers and VMs is usually obvious once you name the workload and the environment it runs in.
| Workload | Fits | Why |
|---|---|---|
| Stateless web applications | Container | Start fast, scale horizontally, packaged once |
| Microservices | Container | The model assumes cheap, many, identical |
| Build and test environments | Container | Seconds to start, thrown away after |
| Legacy software with an installer | VM | It expects a machine, and it will get one |
| A different operating system | VM | Containers cannot bring their own kernel |
| A database with strict latency | VM | Predictable resources, and a simpler storage path |
| A domain controller or file server | VM | Long lived, stateful, licensed per machine |
| Anything from an untrusted party | VM | The isolation level is the whole point |
| A desktop for a person | VM | They need a whole machine, not an application |
The pattern: if the unit you are deploying is application software, use a container. If the unit is a machine, use a virtual machine.
DevelopmentDevelopment environments, which is why containers spread
The production argument for containers is density and resource efficiency. The argument that actually won teams over is development, and it is worth stating because it changes what you are choosing between.
Before containers, a development environment was a set of instructions somebody followed, and it drifted. Two developers ran different library versions, the test systems ran a third, production ran a fourth, and the phrase "it works on my machine" described a real and expensive class of failure.
A VM image could in principle fix that and was too heavy to rebuild per change.
A container image is the environment, as one file, byte for byte identical everywhere it runs. The same image a developer built runs in the test systems and then in production, with no reinstallation and nothing to drift.
That property is what virtual machine images also have in principle and never had in practice, because a multi gigabyte machine image is too slow to rebuild on every change and too large to keep one version per commit.
Two consequences follow for how the two technologies are used.
Containers made the build a definition rather than a procedure. A Dockerfile is source code, it lives in the repository beside the application, and it is reviewed like anything else. That is why containerized deployment became popular so quickly, and it is a property VMs never had in practice.
Virtual machines are still how the platform underneath is built. Nobody runs their cloud infrastructure as a container. The nodes, the databases and the network appliances are all virtual machines, defined by their own tooling, and multiple container platforms sit on top of that rather than replacing it.
The stackWhere they meet, which is most of production
The framing of containers against VMs is misleading, because almost nobody chooses. The two stack.
A typical cloud infrastructure is virtual machines on physical hardware, a container platform running inside those machines, and multiple application containers running on that. The virtual machines provide the hard isolation boundary and the operational model teams already have. The containers provide the packaging and the density.
Every managed Kubernetes service from every cloud provider does exactly this. The nodes are virtual machines and the pods are containers.
Two practical points follow from stacking containers on VMs.
You are paying the virtual machine overhead anyway, so the container density argument is about how many applications fit on a node, not about eliminating the hypervisor.
The operational models are different, and both are needed. Virtual machines are patched, backed up and monitored as machines. Containers are rebuilt from an image rather than patched, and the image is the software that gets updated. A team that patches a running container has misunderstood the model, and the change disappears at the next deployment.
PitfallsWhere people go wrong
Treating a container as a small virtual machine. A container should run one process and hold no state that matters. Installing software into a long lived container, connecting with a shell and configuring it by hand, produces something with all the drawbacks of a machine and none of the benefits.
Storing data inside the container. Container filesystems are ephemeral by design. Anything that must survive belongs on a mounted volume, and discovering that after a redeployment is a common and avoidable loss.
Assuming containers are more secure because they are smaller. A smaller image has less software to attack, and the isolation boundary is weaker. Those are different security statements and both are true.
Running everything as root inside the container. It is the default and it should not be. A non root user in the image costs one line of the Dockerfile and removes an entire privilege escalation path.
Choosing containers for a workload that wants a machine. Licensed software with an installer, a database with a latency requirement, or anything that expects to manage its own kernel parameters is fighting the model.
Adopting Kubernetes for three applications. Containerized workloads do not require an orchestrator. Three services in one environment run perfectly well under Docker Compose or systemd, and the Kubernetes operational burden is real and permanent.
ComparisonContainers and virtual machines, on what the shared kernel gains and costs
| Criterion | Container | Virtual machine |
|---|---|---|
| Carries its own kernel | No | Yes |
| Start time | Under a second | Tens of seconds |
| Image size | Megabytes | Gigabytes |
| Density per physical host | High | Lower |
| Isolation level | Process level | Strong |
| Can run a different operating system | No | Yes |
| Right for isolated untrusted workloads | No | Yes |
| Right for a stateless application | Yes | Workable |
| Patched, or rebuilt | Rebuilt from an image | Patched in place |
| Familiar to most infrastructure teams | Newer | Established |
Read the first row and the fifth together. Everything a container gains from not carrying a kernel, it pays for in the strength of the boundary around it.
FAQFrequently asked questions
What is the main difference between a container and a virtual machine?
Virtual machines carry their own operating system and run on virtualized hardware. Containers share the host kernel and package only the application. Every other difference follows from that.
Are containers faster than VMs?
They start far faster and use fewer resources, because there is no operating system to boot. Once both are running, application performance is close, and a VM can be faster for workloads sensitive to the storage path.
Are containers less secure than virtual machines?
The security boundary is weaker, because it is the kernel rather than a hypervisor. For workloads you own and trust that is proportionate. For untrusted workloads, use virtual machines.
Can a container run a different operating system?
No. It shares the host kernel, so Linux containers need a Linux kernel. Docker on Windows or macOS runs a Linux VM and puts the containers inside it.
Do containers replace virtual machines?
No, and in practice they run inside them. Every managed Kubernetes service uses virtual machines as its nodes, and the surrounding infrastructure is machines too.
Which should I use for a database?
A virtual machine, usually, for predictable resources and a simpler storage path. Containers do run databases successfully, and doing so needs more care around persistent volumes and failover than a virtual machine does.
What is a shared kernel?
The host operating system kernel, which every container on that machine uses. It is what makes containers small and what makes their isolation weaker.
Do I need Kubernetes to use containers?
No. Kubernetes is an orchestrator for many containers across many machines. A handful of services in one environment needs nothing more than Docker Compose.
What are namespaces and cgroups?
The two Linux kernel features containers are built from. Namespaces restrict what a process can see. Control groups restrict what it can consume.
Can a container escape to the host system?
Through a kernel vulnerability, yes, and such vulnerabilities are found periodically. Running as a non root user, keeping the host patched and avoiding privileged containers are the practical security defenses.
Where should containerized data live?
On a mounted volume, never in the container filesystem, which is discarded when the container is replaced.
What are Firecracker and Kata Containers?
Runtimes that give each container a lightweight virtual machine boundary instead of a shared kernel. They cost some startup time and density, and they are what cloud serverless platforms use for untrusted code.
Docker vs VM: what is the practical difference?
A Docker container shares the host's kernel and packages only the application and its libraries, so it starts in seconds and uses little memory. A VM carries a complete operating system and is isolated by the hypervisor.
In the Docker vs VM choice, containers win on density and speed, and VMs win on isolation and on running a different operating system.
Keep readingRelated concepts
Read next · Containers What Is Docker? The container runtime most people meet first, and how an image is actually built. Open this next14 min- Shared storage · 12 min NAS vs SAN Containers are stateless by design, so anything that persists goes to storage somewhere else.
- Hypervisors · 11 min Hyper-V vs VMware The hypervisors underneath, and which one to run the nodes on.
- Platforms · 10 min What a Kernel Is, and Why a Driver Can Take Down the Machine What sharing one kernel costs you in isolation.
- Operations · 11 min Infrastructure as Code, and the File That Knows What Exists What is usually on the other end of it.
- Hypervisors · 10 min Type 1 vs Type 2 Hypervisor The hypervisors underneath, when a container is not the right unit.
- Hypervisors · 10 min ESX vs ESXi, and Why the Question Is Now About Something Else What sits beside virtual machines rather than replacing them.
- Platforms · 10 min Scale Up vs Scale Out, and Why Most Offices Should Scale Up Bigger machine or more machines: which one a small business needs, and what state does to the answer.