This chapter follows Graphical desktops on Linux.
The same apt install workflow can run on a laptop, a cloud VM, a Docker container on Debian, or WSL2 on Windows—but isolation and kernel sharing differ. Picking the wrong layer causes “works in container, fails on VM,” missing kernel modules in WSL, or heavier overhead than necessary.
Full virtual machines
A VM runs a complete guest OS with its own kernel on emulated or paravirtualized hardware (KVM/QEMU on Linux, Hyper-V, VMware). Strong isolation; higher RAM and boot cost. Use VMs when you need another kernel version, a different distro for testing, or hard security boundaries between tenants.
On Debian hosts, virt-manager or libvirt manages KVM guests; cloud images are VMs with metadata-driven networking from Networking on Linux.
Containers and the shared kernel
Containers use Linux namespaces, cgroups, and images—see Linux security primitives and Docker overview. All containers on a host share one kernel; you cannot run a Windows kernel inside Linux Docker.
Containers excel at packaging app dependencies and scaling stateless services. They are weak substitutes for VMs when you need custom kernel modules unrelated to the host, or full desktop isolation.
| Layer | Kernel | Typical use |
|---|---|---|
| VM | Guest kernel | Different OS/kernel, strong isolation |
| Container | Host kernel | Portable app bundles, density |
| Bare metal | Host kernel | Maximum performance, hardware access |
WSL1 versus WSL2 on Windows
WSL1 translated Linux syscalls to Windows—no Linux kernel, odd edge cases for ioctls and filesystem semantics.
WSL2 runs a real Linux kernel inside a lightweight utility VM. Better compatibility; file I/O across \\wsl$\ boundaries still has tradeoffs. Debian and Ubuntu ship as WSL distributions via wsl --install.
Use WSL2 for Linux CLI dev on Windows workstations; use native Linux or VMs when latency to block storage or hardware passthrough matters.
When to choose each model
- Bare metal or VM — databases sensitive to noisy neighbors, custom kernel, GPU passthrough.
- Container — CI jobs, microservices, reproducible dev stacks (Installing Docker on Debian).
- WSL2 — Windows-primary developers needing Linux tooling and package managers.
Nested and hybrid setups
Kubernetes clusters often run on VMs; developers run Docker inside WSL2 on Windows. Each layer adds its own network namespace and storage path. When debugging, identify which kernel owns the process (uname -r in WSL vs on the host), which interface carries traffic (ip route in each context), and whether a bind mount crosses a performance boundary (WSL2 /mnt/c vs files under ~/ on the Linux filesystem).
Nested combos fail quietly when a tool assumes bare-metal udev or a specific cgroup controller that the outer environment does not expose. Treat hybrid stacks as chained isolation boundaries from Linux security primitives rather than as “just another folder.”
Companion references for the series: Linux glossary and Linux cheat sheet.
This is the last chapter of the Linux series. The opening chapter was A short history of Unix and Linux.
Check your understanding
Question 1 of 5
0 of 5 checked