What's actually the difference between a container and a virtual machine, at the operating system level — not the marketing-slide version?

A VM virtualizes hardware — a hypervisor runs a full guest operating system (its own kernel included) on top of virtualized CPU/memory/disk/network devices, giving strong isolation at the cost of running an entire extra OS per instance. A container shares the host machine's kernel and uses kernel features (Linux namespaces for isolation, cgroups for resource limits) to make a process look like it has its own filesystem, network stack, and process tree — no separate kernel, no hypervisor, much lighter weight, but isolation that's fundamentally weaker because a kernel-level vulnerability can potentially be exploited across container boundaries in a way it can't across VM boundaries.

The core architectural difference is what layer the isolation happens at:

A virtual machine relies on a hypervisor (Type 1, running directly on hardware like ESXi/KVM/Xen, or Type 2, running on a host OS like VirtualBox) to present virtualized hardware to a guest — the guest boots its own complete kernel and OS, believing it has real (virtual) CPU, memory, disk, and network devices. Isolation is enforced by the hypervisor at the hardware-virtualization layer, which is a very strong isolation boundary — a process inside one VM has no path to another VM's memory or kernel without going through the hypervisor itself, which is a much smaller, more heavily scrutinized attack surface than a full OS kernel.

A container is fundamentally just a regular process on the host, made to look isolated using kernel features rather than actually running a separate kernel:

• Namespaces (PID, network, mount, UTS, IPC, user) give a process its own view of process IDs, network interfaces, filesystem mounts, hostname, and more — so a containerized process sees itself as PID 1 with its own filesystem root, even though the host kernel sees it as just another process in its own process tree.
• cgroups (control groups) limit and account for a process's resource usage — CPU, memory, I/O — so one container can't starve others sharing the same host kernel.
• Because there's no separate kernel per container, all containers on a host share literally the same running kernel instance. This is what makes containers lightweight (no OS boot, no duplicated kernel memory footprint, near-instant startup) but also what makes the isolation boundary weaker in principle: a kernel exploit that escapes namespace/cgroup confinement compromises the host and everything else sharing that kernel, a class of risk that simply doesn't exist the same way across VM boundaries, since VMs don't share a kernel at all.

This is why security-sensitive multi-tenant platforms sometimes layer VMs and containers together (e.g. running each container, or group of containers, inside its own lightweight VM — the approach taken by gVisor, Kata Containers, and Firecracker microVMs) to get container-like density and speed with closer-to-VM isolation guarantees, rather than treating "containers vs VMs" as a strictly either/or choice.

• What specific Linux namespace types exist, and what does each one isolate?
• Why does a container image being much smaller than a VM image matter for both startup time and attack surface?
• How would you explain the security trade-off of containers vs. VMs to someone deciding whether to run untrusted third-party code?

• VMs virtualize hardware and run a full separate guest kernel per instance; containers share the host kernel and use namespaces/cgroups to fake isolation for a regular process.
• Shared-kernel architecture is what makes containers lightweight and fast to start, and also what makes their isolation boundary fundamentally weaker than a VM's.
• Namespaces provide the "looks isolated" view (PID, network, mount, etc.); cgroups provide the resource-limiting/accounting.
• Technologies like gVisor, Kata Containers, and Firecracker exist specifically to close the isolation gap by running containers inside lightweight VMs.

• Linux man-pages: namespaces(7)
• Linux man-pages: cgroups(7)
• Kata Containers: Architecture overview