Every interview asks it. Most answers stay surface-level. We want to go deeper, past the Docker logo and the VM diagram, into the kernel primitives that make both technologies possible and the engineering trade-offs that should govern every choice between them.
There is a question we have heard in nearly every systems-level interview we have ever observed, studied, or participated in, in some form or another: what is the difference between a container and a virtual machine? Most candidates give a version of the same answer. Containers are lighter. VMs are more isolated. Containers share a kernel. VMs have their own. The answer is not wrong. It is just incomplete in a way that matters enormously for anyone who wants to build, operate, or reason about production infrastructure. The real answer begins not with Docker or VMware, but with the Linux kernel itself, and with two features that most engineers use every day without knowing their names.
We have spent considerable time studying how both technologies are actually implemented, how the operating system enforces their boundaries, and where those boundaries break down. What we found changed how we think about deployment decisions entirely. Containers and virtual machines are not merely two points on a spectrum from lightweight to heavyweight. They are fundamentally different abstractions, solving overlapping but distinct problems, rooted in completely different layers of the computing stack. Understanding that difference at the OS level is what separates engineers who know how to use these tools from engineers who understand why they work the way they do.
"Virtual machines virtualize hardware. Containers virtualize the operating system. That single sentence contains almost everything you need to know, and almost nothing about what it actually means."
Wiz Container Security Academy, 2025Let us take that sentence apart, layer by layer, and rebuild it into something genuinely useful.
A virtual machine is, at its core, a software-constructed illusion of a complete physical computer. When you boot a VM, a piece of software called a hypervisor intercepts every attempt by the guest operating system to talk to hardware, and either emulates the hardware behavior in software or translates the request to the actual underlying hardware via a controlled interface. The guest OS believes it is running on dedicated physical silicon. It is not. It is running inside a carefully managed simulation, and the hypervisor is the magician maintaining that illusion.
Hypervisors come in two fundamental types, and the distinction matters for both performance and security. A Type 1 hypervisor, sometimes called a bare-metal hypervisor, runs directly on the physical hardware with no host operating system underneath it. VMware ESXi and the Linux Kernel-based Virtual Machine (KVM) are the dominant examples. Because there is no intermediate OS layer consuming resources, Type 1 hypervisors offer better performance and stronger security boundaries. A Type 2 hypervisor, by contrast, runs as a process on top of a host operating system. VirtualBox and VMware Workstation are familiar examples. The host OS sits between the hypervisor and the hardware, which adds latency and resource overhead, but makes these tools easy to install and use on a developer's laptop.
The defining characteristic of a VM is that each one runs a complete, independent guest operating system with its own kernel. That kernel boots the way any operating system boots: it initializes hardware drivers, establishes a process table, mounts a filesystem, and begins accepting system calls from the processes running inside it. This full isolation is exactly what makes VMs so powerful for security-sensitive workloads. When one VM is compromised, the damage is contained entirely within that VM's kernel space. The host and every other VM on the same physical machine remain completely unaware that anything went wrong. The hypervisor acts, as one researcher memorably described it, as a fortress wall between guests.
The cost of that fortress, however, is substantial. A typical VM image contains a complete operating system installation, which consumes gigabytes of storage and hundreds of megabytes of RAM before any application code even loads. Booting a VM means booting a full OS kernel, which takes anywhere from thirty seconds to several minutes depending on the image. On a single physical server, you might run a dozen VMs before resource contention becomes a meaningful concern. That density ceiling is a real architectural constraint, and it is the primary reason the industry began searching for something lighter.
A container is not a virtual machine with the unnecessary parts removed. It is a different kind of abstraction entirely. Where a VM tricks a guest OS into believing it has its own hardware, a container tricks a group of processes into believing they have their own operating system. The underlying kernel is shared. The isolation is constructed entirely in software, using two Linux kernel features that have existed for much longer than Docker: namespaces and control groups, universally abbreviated as cgroups.
Namespaces have been part of the Linux kernel since approximately 2002, with meaningful container support arriving only in 2013. A namespace wraps a global system resource and presents each process with its own private view of that resource, completely isolated from every other process's view. The Linux kernel provides several distinct namespace types, each governing a different dimension of isolation. The PID namespace gives each container its own independent process tree, so the first process inside a container sees itself as PID 1, completely unaware of the thousands of other processes running on the same host. The network namespace provides each container with its own network interfaces, routing tables, and firewall rules. The mount namespace gives it an independent filesystem hierarchy. The UTS namespace, one of the simplest, is why containers have their own hostnames distinct from the physical machine they are running on.
Namespaces answer the question of what a process can see. Control groups answer the question of how much it can use. Google engineers first developed cgroups in 2006, under the original name "process containers," and the feature was merged into the Linux kernel mainline in version 2.6.24, released in January 2008. A cgroup assigns a collection of processes to a hierarchy and attaches resource limits to that hierarchy: a maximum percentage of CPU time, a ceiling on memory consumption, limits on disk I/O throughput, and constraints on network bandwidth. When a containerized application attempts to allocate more memory than its cgroup allows, the kernel enforces the limit, either by refusing the allocation or by invoking the out-of-memory killer against the offending process.
This is how Docker, Kubernetes, and every other container runtime actually work under the hood. When you run a Docker container, Docker calls into a lower-level runtime called containerd, which in turn invokes a component called runc. Runc communicates directly with the Linux kernel to create a new set of namespaces, configure cgroup limits, and then execute the container's init process inside that isolated environment. The entire elaborate machinery of container isolation resolves, at the kernel level, to two syscall families: those that create and manage namespaces, and those that read and write cgroup control files in the virtual filesystem mounted at /sys/fs/cgroup. Containers are, in the most technically precise sense, just Linux processes with very carefully constructed views of the world.
Research published in the World Journal of Advanced Engineering Technology and Sciences in 2025 quantified the density difference with remarkable precision. A reference server configured to run 12 KVM-based virtual machines was tested against the same hardware running Docker containers with equivalent application workloads. The containerized environment supported up to 89 concurrent containers while maintaining comparable performance characteristics. Resource utilization in the containerized environment reached 78%, compared to 42% in the VM-based deployment. That difference is not merely academic. At cloud-provider scale, where the cost of a wasted CPU cycle is measured in real money across millions of servers, a density advantage of this magnitude is the difference between a profitable service and an unsustainable one. It is precisely this arithmetic that led AWS to rethink its entire serverless runtime, a decision that produced one of the most interesting pieces of systems infrastructure built in the past decade.
We want to spend time on security because it is where the container versus VM choice has the most concrete consequences, and where the most dangerous misconceptions live. The fundamental asymmetry is this: VMs achieve isolation at the hardware layer, while containers achieve it at the operating system layer. That one level of difference has cascading implications for what an attacker can do if they find a vulnerability inside a running workload.
When a process inside a VM is compromised, the attacker controls that process and potentially the guest OS kernel. But they still face the hypervisor as a boundary. Escaping from a VM requires exploiting a vulnerability in the hypervisor itself, a much smaller and more carefully audited codebase than an entire operating system kernel. The blast radius of a VM compromise is therefore contained to that VM's guest OS, and history has shown that hypervisor escapes, while possible, are genuinely rare and difficult to execute. The separation is architectural, not merely policy-based.
Containers present a fundamentally different risk profile. Because all containers on a host share the same kernel, a container escape, in which an attacker breaks out of the namespace and cgroup boundaries and achieves code execution in the host kernel context, compromises not just one container but potentially every container running on that host. The Linux kernel is an enormous, complex codebase with a surface area orders of magnitude larger than any hypervisor. Privilege escalation vulnerabilities in the kernel, such as CVE-2022-0185 in the user namespace implementation, can potentially be leveraged by an attacker who has already compromised a container to gain host-level access. This is not a hypothetical concern. It is an active engineering challenge that every organization running containers in multi-tenant environments must grapple with.
This is also why the container security community has developed a layered defense model that goes well beyond simply running Docker. Seccomp-BPF profiles restrict which system calls a container is permitted to make, reducing the kernel's attack surface substantially. AppArmor and SELinux provide mandatory access control policies that constrain container behavior even if a namespace boundary is violated. Running containers as non-root users, using read-only root filesystems, and scanning container images for known vulnerabilities are all standard practice in security-conscious organizations. These controls do not eliminate the shared-kernel risk, but they raise the cost of exploitation to a level that most attackers cannot clear.
"Containers use OS-level isolation via namespaces and cgroups while sharing the host kernel. This is like having separate apartments in one building, versus separate houses. A problem in one apartment can affect the building's shared systems."
Wiz Container vs. VM Security Analysis, 2025We find AWS Firecracker to be one of the most intellectually honest pieces of infrastructure engineering of the past decade, because it starts from a frank admission: neither pure containers nor traditional VMs were the right tool for serverless computing. Containers were too insecure for multi-tenant workloads. Traditional VMs were too slow and resource-hungry for workloads that might run for milliseconds. So AWS built something new, and what they built reveals exactly how well they understood the underlying OS primitives.
Firecracker is a microVM monitor written in Rust, built on top of Linux KVM. Each Firecracker microVM provides genuine hardware-level isolation: its own kernel, its own virtual CPU and memory, its own network interface. An attacker who compromises code running inside a Firecracker microVM faces a KVM-based hypervisor boundary before they can reach the host, the same fundamental isolation guarantee that a traditional VM provides. But Firecracker achieves this while booting in as little as 125 milliseconds and consuming less than 5 megabytes of memory overhead per microVM, numbers that are competitive with containers rather than traditional VMs. A single host can create up to 150 Firecracker microVMs per second.
The speed comes from aggressive minimalism in the device model. A traditional VM monitor like QEMU emulates an enormous range of hardware: graphics cards, sound cards, USB controllers, BIOS, PCI buses, ACPI tables. None of this is needed for a serverless function. Firecracker exposes only two virtual devices, both using the virtio interface for efficient host-to-guest communication: a network device and a block storage device. There is no BIOS emulation, no PCI bus, no display. The attack surface is vanishingly small. The boot path is so short that the entire startup time is dominated by kernel initialization rather than device enumeration. This is not a compromise. It is a demonstration of how deeply understanding the problem statement, what do serverless workloads actually need from a hypervisor, enables the elimination of everything else.
AWS Lambda now runs on Firecracker, processing trillions of function executions monthly. AWS Fargate migrated from dedicated EC2 instances to Firecracker microVMs, which allowed AWS to run customer containers at dramatically higher density on EC2 bare metal instances without sacrificing the kernel-level isolation that multi-tenant security requires. The engineering insight embedded in Firecracker is worth sitting with: the goal was never containers versus VMs. It was finding the isolation boundary that the workload actually required, and then engineering a runtime that delivered exactly that boundary at the lowest possible cost.
One of the most clarifying things we have encountered in studying container internals is the statement, made in various forms by kernel developers, that a Linux container is fundamentally just a process. Not a special entity, not a virtual machine, not a sandbox in the traditional security sense. It is an ordinary Linux process, running in ordinary kernel address space, distinguished only by the set of namespaces it belongs to and the cgroup hierarchy that governs its resource access. The implications are significant. Containers inherit all the security properties and all the vulnerabilities of the Linux process model. The isolation they provide is real, but it is constructed in software by the kernel, and software can have bugs. This is why Firecracker's hardware isolation is genuinely different in kind, not just degree, from container isolation. One uses the same kernel mechanisms that protect any process. The other interposes a hypervisor boundary that requires a distinct class of exploit to cross.
The practical guidance that follows from all of this is less about picking a side and more about matching the isolation mechanism to the threat model and operational requirements of each workload. We have seen engineering teams get this wrong in both directions: over-isolating with VMs workloads that would have run perfectly well and far more efficiently as containers, and under-isolating with containers workloads that genuinely required the stronger boundary of hardware virtualization.
Virtual machines remain the correct choice when you need to run a different operating system than the host, when regulatory compliance mandates OS-level isolation between tenants (HIPAA, PCI-DSS, and similar frameworks frequently require this), when a workload has legacy dependencies that are tightly coupled to specific kernel versions or OS configurations, or when a stateful application like a database requires predictable, consistent resource allocation that cannot tolerate the variability that comes with shared-kernel scheduling. The stronger isolation of a VM is not overhead in these contexts. It is the entire point.
Containers are the right tool for stateless microservices, CI/CD build and test pipelines, any workload that needs to start and stop rapidly and frequently, and applications that benefit from the portability guarantee of a container image. The packaging model alone has real value independent of the runtime characteristics: a container image captures the complete application environment, eliminating the class of bugs where code behaves differently across development, staging, and production because of subtle environmental differences. Container startup times averaging 1.3 seconds, compared to the minutes required for a VM, translate directly into faster deployment cycles and more responsive horizontal scaling. Organizations adopting Kubernetes have documented improvements in their application-to-administrator ratio from around 12:1 to 38:1 within eighteen months of adoption, alongside a 38% reduction in critical incidents.
The most sophisticated production architectures use both, with the choice governed by workload characteristics rather than organizational preference. A common and sensible pattern runs Kubernetes containers on top of VM-based nodes in cloud environments, obtaining the density and operational benefits of containerization while preserving VM-level isolation between groups of workloads. The containers provide application packaging and scheduling flexibility. The VMs provide the security boundary between different customers or business units sharing the same physical infrastructure. This is not a compromise. It is the correct answer, arrived at by asking the right questions about what each layer of the stack is actually responsible for.
We started writing this piece because we kept encountering the surface-level answer in interviews and architecture discussions, and we kept feeling that something important was being left out. What was being left out, we eventually realized, was the operating system itself. Containers and virtual machines are not just deployment formats or infrastructure choices. They are answers to a fundamental question in computer science: how do you run untrusted or partially trusted code on shared hardware, while preventing that code from affecting other tenants, consuming unbounded resources, or exploiting the privilege of the underlying system?
The Linux kernel answered that question with namespaces and cgroups, which enable fast, lightweight process isolation at the cost of a shared kernel attack surface. The hypervisor tradition answered it with hardware virtualization, which provides a stronger isolation boundary at the cost of substantial resource overhead. Firecracker represents a third answer: minimize the hypervisor until the overhead approaches the container model, while preserving the fundamental security property that the isolation boundary lives at the hardware layer. Each answer reflects a different set of trade-offs, and understanding those trade-offs, not just their consequences but their causes, is what allows engineers to make principled architectural decisions rather than fashionable ones.
The question every interviewer is really asking when they bring up containers versus VMs is not whether you know the marketing copy. It is whether you understand that software systems are built on layers, that each layer makes promises to the layer above it, and that security, performance, and correctness all depend on understanding precisely where those promises hold and where they break down. Namespaces and cgroups are where containers' promises are made. The hypervisor is where VMs' promises are made. Knowing that is the beginning of actually understanding either one.