A hypervisor creates virtual hardware backed by the processor's virtualization extensions (Intel VT-x, AMD-V). A type 1 hypervisor runs on the hardware itself (VMware ESXi, Hyper-V, Xen, and KVM, which turns Linux into one); a type 2 hypervisor is an application on a desktop OS (VirtualBox 4,691 , VMware Workstation). Either way, each VM boots its own kernel. Containers diverge exactly there: every container makes system calls into the one host kernel, which enforces the isolation. This machine shows both layers, since Ubuntu 225 runs in WSL2 6 , a lightweight Hyper-V VM:
systemd-detect-virt
uname -r
docker run --rm alpine:3 uname -r
time docker run --rm alpine:3 echo hello from a containerwsl 6.18.33.2-microsoft-standard-WSL2 6.18.33.2-microsoft-standard-WSL2 hello from a container real 0m0.710s user 0m0.013s sys 0m0.054s
The Alpine 13,255 container reports the host's kernel because it has none of its own (so a Linux container needs a Linux kernel), and creating, running and deleting it took 0.71 seconds.
The price of sharing a kernel is a thinner wall. A VM's boundary is enforced by the processor; a container's by the kernel's bookkeeping, where every system call is a potential way out, which is why Container Security drops capabilities and runs as non-root. Sandboxes in between trade speed for strength: gVisor 482,968 (github.com/google/gvisor (https://github.com/google/gvisor 19,434 )) intercepts system calls in a user-space kernel, and Kata Containers 533,613 (github.com/kata-containers/kata-containers (https://github.com/kata-containers/kata-containers 8,809 )) runs each container in a lightweight VM. Both run ordinary OCI images unchanged.