Container vs virtual machine
“What is the difference between a container and a virtual machine? If a container has no kernel of its own, what is actually isolating it?”
What this tests
- A VM as a hypervisor-virtualised machine with its own kernel
- A container as ordinary processes: namespaces, cgroups, layered filesystem, capabilities/seccomp
- Consequences: shared kernel as the security boundary, start-up time, density
- Resource limits as cgroup accounting: OOM kills, CPU throttling, page cache
Answers by level
Read the beginner answer first and notice what is missing.
A virtual machine is created by a hypervisor (KVM, Hyper-V, ESXi) that presents virtual CPUs, memory and devices; a complete guest kernel boots on them and schedules its own processes. The isolation boundary is hardware virtualisation (Intel VT-x / AMD-V, a second level of page tables): the guest kernel cannot touch the host (VM vs Container: Where the Boundary Is).
A container is one or more ordinary processes on the host kernel with a different *view* of the system. Namespaces change what the process sees: its own PID numbering (its first process is PID 1), its own mount table and root filesystem, its own network stack with its own interfaces and ports, its own hostname, IPC and user ids. Control groups bound what it may use: CPU shares and quotas, memory, PIDs, I/O bandwidth. A layered filesystem (overlayfs) gives it an image without copying it. Capabilities, seccomp filters and an LSM (AppArmor/SELinux) restrict which syscalls and privileges the process has (Containers Are Processes With the Kernel’s View Narrowed, Process Isolation: One Kernel, Many PID 1s).
The consequences follow. From the host, ps shows the container’s processes as normal processes with different PIDs; there is no second kernel, so start-up is milliseconds and density is high; two containers can both bind port 80 because they have separate network namespaces. But the kernel is shared: a kernel vulnerability reachable through a syscall escapes the container, whereas a VM escape must break the hypervisor. That is why multi-tenant platforms run untrusted code in microVMs (Firecracker) or sandboxes (gVisor) rather than plain containers.
Resource limits are cgroup accounting on the host kernel. A container exceeding memory.max gets a process OOM-killed by the host (exit code 137); a CPU quota throttles it for the rest of each 100 ms period once it has used its share — a service can be throttled at 30% average utilisation. And the page cache for files the container reads is charged to its memory cgroup, so a container that writes large files can hit its limit while its heap is small (label: Linux cgroup v2).
Green flags · Red flags
- Says a container is a process with namespaces and cgroups, not a small VM
- Names at least four namespaces and what each hides
- Identifies the shared kernel as the security boundary
- Explains OOM kill and CPU throttling as cgroup mechanisms
- Knows PID 1 responsibilities or runtime container-awareness
- "A container is a lightweight VM"
- Believes containers have their own kernel
- Cannot explain how two containers bind the same port
Follow-up questions
docker stop do and why can it take 10 s?Scenario
limits.cpu: 1 and 4 GB memory shows p99 latency spikes and periodic restarts with exit code 137 although average CPU is 25% and heap is 1.5 GB. Diagnose both symptoms.