What does a container share with its host that a virtual machine brings its own, and what does that buy at start-up?
answer
- two boundaries, different depths
- one kernel or two
- the image carries no kernel
- nothing to boot, so milliseconds
- shared kernel is the price
basics
~20 sA container shares the host's already-running kernel; a virtual machine boots a guest kernel and a whole system of its own from a disk image. Sharing removes the boot, so a container starts a process in milliseconds instead of booting a machine.
solid answer
~50 sBoth give a workload its own view of the world, but the boundary is drawn at different depths. A virtual machine is handed emulated hardware and boots **its own kernel**, its own first process and its own system services from a disk image. A container is an ordinary process on the host, issuing its system calls to the **host's already-running kernel**; what makes it a container is that the kernel hands it separate per-resource views — its own filesystem root, process table, network stack, user ids and hostname — and puts it in an accounting group that caps its CPU and memory. Because the kernel is already up there is nothing to boot: assemble the layers, apply the fences, start the process. That is milliseconds against tens of seconds, and the same fact drives density and image size. The price is that every container on the host trusts one kernel.
code
pseudocode · 16 linesstart_behind_machine_boundary(workload):
power_on_virtual_firmware()
discover_virtual_devices()
load_and_boot_guest_kernel()
mount_guest_root()
start_guest_first_process()
start_guest_system_services()
start(workload) # tens of seconds later
start_as_container(workload):
root = assemble_readonly_layers(image) # usually already on this host
views = separate_views(filesystem = root,
processes, network, ids, hostname)
group = accounting_group(cpu_ceiling, memory_ceiling)
drop_privileges_not_requested()
start(workload) inside views, group # host kernel already runninggo deeper
Recall the one-line core: a container shares the host's running kernel, a virtual machine brings its own. Everything else in the comparison — start-up, size, density, blast radius — follows from that sentence, so lead with it.
Explain the mechanics: which separate views the kernel hands a container, why skipping firmware and kernel boot is what makes start-up milliseconds, and why the image needs no kernel at all. Name the trade rather than listing benefits.
Show that you have felt both sides in production: what an uncached pull does to the "milliseconds" claim, what one kernel fault does to a whole host of workloads, and how you decide which of the two boundaries a given workload gets.
Frame it as a fleet economics question. Density and start-up are a cost curve; the shared kernel is a trust assumption. Say where your estate draws that line and what evidence would move it.
## Two boundaries drawn at different depths A **virtual machine** boundary is drawn *under* the operating system. The workload is handed something that behaves like a machine — firmware, a disc, a network interface, a block of memory — and inside it boots **its own kernel**, its own first process and its own system services from a disk image. Nothing above that guest kernel needs to know it is not running on bare hardware. A **container** boundary is drawn *above* the kernel. A container is an ordinary process on the host, scheduled by the host's kernel and issuing its system calls to that same kernel. What makes it a container is that the kernel hands the process **separate per-resource views** — its own filesystem root, its own process table, its own network stack, its own user-id space, its own hostname — and places it in an **accounting and limiting group** that caps the CPU time and memory it may consume. Take those away and you are left with a plain process. That is all a container has ever been. ## Side by side | | container | virtual machine | |---|---|---| | kernel | the host's, shared by all of them | its own guest kernel | | what the artifact holds | only the files the process needs | a whole system in a disk image | | start-up | start a process: milliseconds to about a second | firmware, kernel boot, system start-up: tens of seconds | | copies per host | typically hundreds | typically tens | | failure domain | one kernel covers every container on the host | each guest kernel is its own | | kernel version and modules | whatever the host happens to run | chosen per guest | ## Why start-up differs so much Bringing up a guest does roughly this: 1. start the emulated firmware and discover the virtual devices; 2. load and boot the guest kernel; 3. mount the guest root filesystem, start its first process and its system services; 4. finally start the application. Bringing up a container does this: 1. assemble the image's read-only layers into a root filesystem — usually already on the host from an earlier pull; 2. create the per-resource views, put the process in its accounting group, and drop the privileges nobody asked for; 3. start the process. Steps 1 to 3 of the guest sequence have no counterpart, because the kernel they would produce is already running and already serving every other workload on the machine. One honest caveat: when the image is *not* already on the host, the pull dominates and the start is not milliseconds either — but that is a distribution cost, not a boot. ## What the shared kernel buys beyond speed - **Density.** The marginal cost of one more copy is roughly that process's own working set, rather than a guest's resident kernel plus system services plus whatever memory was set aside for it up front. - **Artifact size.** The image needs no kernel, no firmware and no full userland. A minimal one ships a few megabytes with no shell and no package manager, against gigabytes for a disk image. - **One kernel to patch.** Patching the host's kernel covers every workload on it at once — the same fact as the failure domain below, seen from its pleasant side. - **Cheap enough to be disposable.** Start-up measured in milliseconds is what makes replacing a workload, scaling it out for a spike and scaling it back afterwards an ordinary operation instead of a planned one. ## What it costs One price pays for all three benefits: **blast radius**. Every container on the host is one kernel away from every other one. A kernel-level fault takes every workload on that host down together, and a flaw reachable through the kernel's call surface is reachable from inside any container that can make the call. A guest kernel per workload moves that line outward: getting from one workload to another means crossing a machine boundary rather than one shared call surface. That is the whole trade, and it is why "container or virtual machine" is still a real question. Start-up, density and size sit on one side; the width of the failure domain sits on the other. ## Where candidates state it backwards - "A container is a lightweight virtual machine." It is not a machine at all. It is a fenced process, and the absent guest kernel is the entire difference. - "The runtime isolates the container." The kernel isolates it; the runtime asks the kernel to. - "Containers start fast because the image is small." Size helps the pull. Start-up is fast because there is no boot. - "Containers are safer because there is less inside them." A smaller image is a smaller software inventory, which is genuinely useful, but the boundary itself is thinner, not thicker.
- If there is no boot, what actually happens between "start this container" and the first line of application code?The runtime assembles the image's read-only layers into a root filesystem, usually from what is already on the host; creates the separate per-resource views; puts the process in an accounting group with its ceilings; drops privileges that were not requested; then starts the process. The delays left are the image pull when it is not cached, and the application's own warm-up.
- Does a container image need a whole operating system inside it?No. The image needs only the files the process itself needs, because the kernel comes from the host. That is why a minimal image can be a few megabytes with no shell and no package manager, while a disk image for a guest carries firmware-to-userland everything. Many images do ship a full userland, but that is convenience, not a requirement.
- Both boundaries can cap CPU and memory. So is resource capping the difference?No. Ceilings exist on both sides: a guest is given a fixed allocation, and a container is capped by the kernel's accounting and limiting mechanism. The difference is whose kernel serves the workload's system calls, which is what decides start-up cost, density, artifact size and how wide one failure reaches.
Flats in one block against detached houses: the flats are quick to fit out and you get far more of them on the same plot, because the plumbing and the foundations are shared. That sharing is also why one burst pipe in the common riser reaches every flat at once.
saying these in an interview costs you the question
- Calls a container a lightweight virtual machine that boots its own small kernel.
- Says the container boundary is enforced by a virtualization layer rather than by the kernel.
- Explains fast start-up by image size instead of by the absence of a boot.
- Assumes a container boundary is as strong as a machine boundary.
- Believes a container can run a kernel version other than its host's.
- Thinks each container holds its own copy of the kernel in memory.