Containerization and Virtualization: Every Platform Compared

“Containers vs VMs” is the wrong framing. The real question is: what isolation boundary do you need, for what workload, with what operational constraints? The answer determines whether you want a full hypervisor, an OS-level container, a system container, a rootless container, or a specialized HPC runtime.

This post maps the full landscape — every major platform, its architecture, its tradeoffs, and the workloads it’s actually suited for.

The Taxonomy First

Before comparing platforms, you need to understand that “virtualization” covers several fundamentally different isolation models:

Understanding which category a platform falls into explains most of its tradeoffs.

Type 1 Hypervisors: Bare Metal Virtualization

A Type 1 hypervisor runs directly on hardware with no host OS underneath. Guest VMs get dedicated virtual hardware: virtual CPUs, virtual NICs, virtual disks. The hypervisor manages resource allocation.

KVM (Kernel-based Virtual Machine)

What it is: KVM is a Linux kernel module that turns the kernel itself into a Type 1 hypervisor. When KVM is loaded, the Linux kernel gains the ability to run other OS kernels as guest processes, with hardware virtualization (Intel VT-x or AMD-V) doing the heavy lifting.

Architecture:

Hardware (with Intel VT-x / AMD-V)
├── Linux host kernel (with KVM module)
│   ├── QEMU process (provides virtual hardware to each VM)
│   │   ├── Guest OS 1 (Windows, Linux, BSD...)
│   │   └── Guest OS 2
│   └── libvirt (management layer, optional)

KVM itself only handles CPU and memory virtualization. QEMU provides the emulated hardware (disk controllers, network adapters, GPU). Together, KVM+QEMU gives near-native performance — typically 2–5% overhead for CPU-bound workloads, more for I/O.

Key features:

• VirtIO drivers: Paravirtualized network and disk drivers that dramatically reduce I/O overhead vs full emulation. Any Linux guest should use VirtIO.
• CPU pinning and NUMA topology: Pin vCPUs to specific physical cores, expose NUMA topology to guests for HPC workloads.
• PCI passthrough (VFIO): Pass physical hardware directly to a guest — GPUs, NVMe drives, NICs. The guest gets bare-metal performance for that device.
• Live migration: Move a running VM between hosts with sub-second downtime using shared storage.
• Nested virtualization: Run a hypervisor inside a guest (useful for testing Kubernetes clusters).

Management interfaces:

• virsh / virt-manager / virt-install — libvirt-based CLI and GUI
• Proxmox VE — full web UI wrapping KVM (covered separately)
• oVirt — enterprise-grade KVM management (upstream of Red Hat Virtualization)
• OpenStack — cloud infrastructure that uses KVM as the compute backend

When to use KVM:

• Running guest operating systems that need their own kernel (Windows on Linux, old RHEL6 services, BSD)
• Workloads requiring strong isolation (multi-tenant environments, untrusted code)
• GPU passthrough for gaming VMs or ML workloads
• Any homelab or on-premise infrastructure where you control the hardware

Performance profile: Best-in-class for a hypervisor. Memory overhead is low (the host OS itself uses ~200–500MB, VMs use only what their guest OS uses). CPU overhead with VT-x is minimal. Disk I/O with VirtIO and io_uring is competitive with bare metal.

VMware ESXi / vSphere

What it is: VMware’s enterprise Type 1 hypervisor. ESXi is the bare-metal hypervisor; vSphere is the full management platform (ESXi + vCenter + vSAN + NSX + everything else).

Architecture: ESXi has its own minimal OS (the “VMkernel”) that runs directly on hardware. Guest VMs run on top. Unlike KVM, there’s no host Linux kernel — ESXi is the OS.

Key differentiators vs KVM:

• vMotion: VMware’s live migration is battle-tested, works across different hardware (within limits), and has tooling that makes it operationally simple
• vSAN: Converged storage — build a distributed storage cluster from local disks in your ESXi hosts
• NSX: Software-defined networking with microsegmentation, distributed firewalling, overlay networks
• vCenter: Centralized management of multiple ESXi hosts, VM templates, resource pools, DRS (distributed resource scheduling)
• Hardware compatibility: VMware has the most extensive HCL (hardware compatibility list) and the most driver support for enterprise hardware

The cost reality: VMware was acquired by Broadcom in 2023. Licensing changed dramatically — perpetual licenses were eliminated, pricing shifted to subscriptions, the free ESXi tier was removed, and entry-level bundles disappeared. For many organizations, VMware’s new pricing has made it economically untenable, driving significant migration to KVM-based alternatives (Proxmox, oVirt, OpenStack).

When to use VMware:

• Large enterprises already invested in the VMware ecosystem
• Environments requiring extensive certified hardware support
• When vSphere’s specific features (DRS, vSAN, NSX integration) justify the cost
• Shrinking use case due to Broadcom pricing changes

Microsoft Hyper-V

What it is: Microsoft’s Type 1 hypervisor, built into Windows Server (and Windows 10/11 Pro as an optional feature). Hyper-V uses a “parent partition” architecture — the host Windows OS runs as a privileged VM, not directly on hardware.

Key features:

• Integration services: Paravirtualized drivers for Windows guests (similar to VirtIO for Linux)
• Hyper-V Manager / Windows Admin Center: GUI management
• Live Migration: Similar to vMotion for moving running VMs
• Shielded VMs: Encrypted VMs that protect against even host administrators
• WSL2: Windows Subsystem for Linux 2 runs on a lightweight Hyper-V VM per-user

When to use Hyper-V:

• Running mixed Windows/Linux workloads in a Windows-dominant shop
• Already licensed Windows Server (Hyper-V is included)
• WSL2 development workflows
• Azure-adjacent deployments (Azure uses Hyper-V)

Not ideal for: Linux-only environments, homelab users who don’t need Windows, any cost-sensitive scenario where the Windows Server license adds overhead.

Type 2 Hypervisors: Desktop Virtualization

Type 2 hypervisors run as applications on top of a host OS. They’re easier to set up and ideal for development, testing, and desktop use — but carry more overhead than Type 1 because they share the host OS’s kernel path.

VirtualBox

What it is: Oracle’s free, open-source Type 2 hypervisor. Runs on Linux, macOS, and Windows. Supports a wide range of guest OSes.

Architecture:

Host OS (Linux/macOS/Windows)
└── VirtualBox application
    ├── Guest VM 1 (Windows, Linux, BSD, Solaris...)
    └── Guest VM 2

Key features:

• Guest Additions: Paravirtualized drivers for shared folders, clipboard sync, dynamic resolution scaling, better performance
• Snapshots: Point-in-time VM state with unlimited nesting
• Linked clones: Create VMs from a base image without duplicating disk
• Port forwarding and NAT: Simple networking for desktop VMs
• Headless mode: Run VMs without a display for server-like usage
• VM export/import: OVF/OVA format for portability

Limitations:

• 3D graphics: Limited and buggy compared to VMware Workstation or Parallels
• Performance: Noticeable overhead vs KVM, especially for I/O
• macOS guests: Not supported on non-Apple hardware (Apple’s EULA restriction)
• Maintenance concerns: Oracle’s stewardship has been rocky; VirtualBox development pace has slowed

When to use VirtualBox:

• Free cross-platform desktop virtualization for development/testing
• Vagrant-based development environments (Vagrant defaults to VirtualBox)
• Running Windows on Linux for occasional compatibility testing
• Students and learners who need a free, accessible hypervisor

VMware Workstation / Fusion

What it is: VMware’s desktop hypervisor products. Workstation (Windows/Linux), Fusion (macOS). Both became free for personal use in 2024 after the Broadcom acquisition.

Key advantages over VirtualBox:

• 3D graphics acceleration: Much better GPU support, useful for gaming VMs and graphics-heavy applications
• Performance: Generally 10–20% better performance than VirtualBox due to more mature paravirtualization
• Snapshots: More reliable and faster than VirtualBox’s implementation
• Unity mode (Workstation) / Coherence mode (Fusion): Run Windows apps in windows on your Linux/macOS desktop without a visible VM border
• ESXi integration: Deploy VMs directly to ESXi hosts from Workstation
• Apple Silicon: Fusion 13+ has native ARM support and can run ARM Linux/Windows VMs on M-series Macs

When to use VMware Workstation/Fusion:

• Best general-purpose desktop hypervisor, especially for developers on macOS (Fusion)
• Running Windows apps on macOS (Fusion + Coherence mode)
• Needs better graphics support than VirtualBox
• Now free for personal use — previously a differentiator, now a baseline

Parallels Desktop (macOS only)

What it is: The fastest Type 2 hypervisor for macOS. Supports both Intel and Apple Silicon Macs natively.

Why it stands out on Apple Silicon:

• On M-series Macs, Parallels can run ARM Windows via virtualization (not emulation), delivering near-native Windows performance
• Deep macOS integration: Coherence mode integrates Windows apps into the macOS dock
• Game support: Best GPU passthrough among macOS hypervisors
• DirectX 12 support in Windows guests

Limitations: macOS only, commercial license required ($100–$130/year).

When to use Parallels: macOS users who need Windows — it’s definitively the best option for Apple Silicon, worth the cost vs the free alternatives.

System Containers: OS-Level Virtualization

System containers share the host kernel but provide each container with its own filesystem, process space, network stack, and user space. They feel like lightweight VMs but don’t carry VM overhead.

LXC / LXD

What it is: LXC (Linux Containers) is the foundational Linux kernel technology for OS-level containerization — namespaces + cgroups + union filesystems. LXD is Canonical’s management layer on top of LXC, providing a REST API, CLI (lxc), and orchestration features.

Architecture:

Linux host kernel
├── LXC container 1 (has its own: PID NS, net NS, mount NS, UTS NS, IPC NS)
│   └── Runs full Ubuntu/Debian/CentOS user space — systemd, sshd, cron, etc.
├── LXC container 2
└── LXC container 3

Key features:

• Full OS feel: Runs systemd, has its own /etc, /var, init system — behaves like a VM but uses the host kernel
• Sub-second boot: Starting a system container takes under a second vs 30+ seconds for a VM
• Minimal overhead: CPU and memory overhead is effectively zero — you’re paying only for the processes running inside
• Profiles: Reusable configuration for network, storage, CPU limits
• Storage drivers: ZFS, btrfs, LVM, or directory-based storage backends
• Network: Bridged, macvlan, SR-IOV, OVN for overlay networking
• Live migration: With CRIU (Checkpoint/Restore in Userspace), you can migrate running containers
• Nesting: Run containers inside containers, or Docker inside LXC

LXD clusters: LXD supports multi-host clustering — distribute containers across nodes, live migrate between them, shared storage with Ceph.

When to use LXC/LXD:

• Consolidating many Linux services on one host with near-zero overhead
• Homelab workloads where each service needs a “full OS” (systemd, its own package manager, etc.) but VM overhead is wasteful
• Development environments that need persistent, mutable OS state
• Running untrusted code with stronger isolation than Docker but less overhead than KVM
• Proxmox homelab deployments (LXC containers alongside KVM VMs)

When NOT to use LXC:

• Running Windows or non-Linux guests (requires KVM)
• Rootless/unprivileged requirements in high-security environments (Docker/Podman are better here)
• Kubernetes workloads (use OCI containers, not system containers)

OpenVZ / Virtuozzo

What it is: One of the original OS-level container platforms, predating LXC by years. OpenVZ is the open-source version; Virtuozzo is the commercial product.

Current state: Largely superseded by LXC/LXD in new deployments. Still runs massive amounts of VPS hosting infrastructure (many cheap VPS providers use OpenVZ under the hood). OpenVZ 7 uses a modified Linux kernel; OpenVZ 8 moves closer to mainline.

When to use it: Legacy environments, or if you’re specifically in the shared hosting VPS space where OpenVZ is the incumbent.

Application Containers: Docker and Friends

Application containers package a single application and its dependencies. They share the host kernel but get isolated process, network, and filesystem namespaces. They’re ephemeral by design — treat state as external.

Docker

What it is: The platform that made containers mainstream. Docker packages the container runtime (containerd), image format (OCI), build tool (Dockerfile + docker build), and CLI into a single user-friendly product.

Architecture:

Host OS
└── Docker daemon (dockerd)
    └── containerd (actual container runtime)
        └── runc (OCI runtime — creates namespaces, runs process)
            ├── Container 1 (nginx)
            ├── Container 2 (postgres)
            └── Container 3 (your-app)

Key concepts:

• Images: Layered, immutable filesystems built from Dockerfiles. Each RUN instruction adds a layer. Layers are cached and shared between images.
• Containers: Running instances of images. Ephemeral — state stored inside is lost when the container is removed.
• Volumes: Persistent storage mounted into containers. Separate from the container lifecycle.
• Networks: Bridge (default), host, overlay (for Swarm/multi-host), macvlan
• Docker Compose: Define multi-container applications in YAML. The de facto standard for local development stacks.
• Docker Swarm: Docker’s built-in orchestration (largely superseded by Kubernetes in production)

The daemon problem: Docker traditionally requires a root-owned daemon (dockerd). This is a security concern — the daemon runs as root, and access to the Docker socket is effectively root access. Rootless Docker exists but has limitations.

When to use Docker:

• Local development environments (Docker Compose is excellent here)
• Building and testing container images
• Simple single-host deployments where Kubernetes is overkill
• CI/CD pipelines for building images
• Teams where Docker’s widespread familiarity reduces friction

Podman

What it is: Red Hat’s daemonless, rootless-native container engine. OCI-compatible — Podman can run any Docker image and understands Dockerfiles.

Architecture:

Host OS
└── podman (CLI tool, no daemon)
    └── conmon (per-container monitor process)
        └── crun or runc (OCI runtime)
            └── Container (runs as your user, not root)

Key differences from Docker:

• No daemon: Each podman run is a direct process — no background service required. No single point of failure.
• Rootless by default: Containers run as your user using user namespaces. The container process never has more privileges than you do.
• Pods: Podman natively supports the pod concept (like Kubernetes pods) — groups of containers sharing a network namespace.
• podman generate kube: Generate Kubernetes YAML from running Podman containers. Useful for migrating from local dev to Kubernetes.
• Podman Compose: Compatible with Docker Compose files.
• systemd integration: podman generate systemd creates systemd unit files for running containers as services.

Drop-in Docker replacement:

1

alias docker=podman   # Works for most use cases

When to use Podman:

• Security-sensitive environments where rootless execution matters
• RHEL/Fedora/CentOS environments (Podman is the default)
• Running containers without a daemon (embedded systems, minimal servers)
• Generating Kubernetes manifests from working local containers

containerd

What it is: The actual container runtime that Docker (and Kubernetes) use under the hood. containerd was extracted from Docker and donated to the CNCF. It’s the CRI (Container Runtime Interface) implementation that Kubernetes talks to directly.

When you interact with it directly:

• Kubernetes clusters (k8s talks to containerd via CRI, not Docker)
• ctr CLI for low-level container management
• Building custom container platforms

Most users never interact with containerd directly — it’s infrastructure, not a user-facing tool.

Buildah / Kaniko / BuildKit

These aren’t runtimes — they’re container image builders, each with different tradeoffs:

• BuildKit (Docker’s build engine): Multi-stage builds, build caching, parallel execution, secrets handling. The best general-purpose builder.
• Buildah: Build OCI images without a daemon, rootless. Great for CI pipelines.
• Kaniko: Build container images inside a container/Kubernetes pod. No Docker socket required. The standard for building images in Kubernetes CI.

Singularity / Apptainer: HPC Containers

What it is

Singularity was created at Lawrence Berkeley National Laboratory for HPC (High Performance Computing) environments. In 2021, the project was renamed Apptainer and moved to the Linux Foundation. Sylabs maintains a commercial fork called SingularityCE.

HPC environments have fundamentally different requirements than cloud/web environments:

• No root access: HPC clusters have hundreds of users. Nobody gets root.
• MPI and high-speed interconnects: Jobs need to use InfiniBand, Omni-Path, and other fabric networks directly.
• Shared parallel filesystems: Jobs read/write to Lustre, GPFS, BeeGFS — not container volumes.
• GPU access: Jobs need bare-metal GPU performance via CUDA without special setup.
• No daemon: Cluster schedulers (SLURM, PBS, LSF) launch jobs as user processes.

Docker fails all of these requirements. Singularity was designed to meet them.

How Singularity works

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# Pull a Docker image and convert to Singularity Image Format (SIF)
singularity pull docker://tensorflow/tensorflow:latest-gpu

# Run interactively
singularity shell tensorflow_latest-gpu.sif

# Run a specific command
singularity exec tensorflow_latest-gpu.sif python train.py

# Bind mount host directories
singularity exec --bind /scratch/data:/data tensorflow_latest-gpu.sif python train.py

# Run with GPU support (CUDA libraries auto-injected from host)
singularity exec --nv tensorflow_latest-gpu.sif python train.py

Key properties:

• Single-file image (SIF): The entire container is one .sif file. Copy it to a cluster, run it anywhere with Singularity installed.
• Runs as the calling user: No privilege escalation. The user inside the container is the same as outside.
• Automatic bind mounts: /home, /tmp, /proc, /sys are mounted from the host by default. Your home directory is available inside the container.
• --nv flag: CUDA libraries from the host are injected into the container. No need to install CUDA in the image.
• MPI support: Use the host’s MPI installation via bind mounts, so InfiniBand works correctly.
• OCI compatibility: Can import Docker/OCI images directly.

Building Singularity images

# my_env.def
Bootstrap: docker
From: ubuntu:22.04

%post
    apt-get update && apt-get install -y python3 python3-pip
    pip3 install numpy scipy matplotlib

%environment
    export PATH=/usr/local/bin:$PATH

%runscript
    python3 "$@"

1
2
3
4
5
6
7
8

# Build (requires root or --fakeroot)
sudo singularity build my_env.sif my_env.def

# Or use --fakeroot (available on most modern HPC systems)
singularity build --fakeroot my_env.sif my_env.def

# Or use a remote build service
singularity build --remote my_env.sif my_env.def

When to use Singularity/Apptainer

• HPC clusters with SLURM/PBS: The only practical container option for most national lab and university clusters
• Reproducible scientific computing: Package your analysis environment in a SIF file, share it with your paper
• GPU workloads on HPC: --nv flag for CUDA is the most friction-free GPU container experience on Linux
• Multi-user systems without Docker: Any environment where users can’t be given Docker socket access
• Bioinformatics: Bioconductor, Galaxy, Nextflow pipelines all support Singularity natively

MicroVMs: The Middle Ground

MicroVMs are a newer category — lightweight VMs that boot in milliseconds and have much lower memory overhead than traditional VMs, while still providing kernel-level isolation.

Firecracker

What it is: AWS’s open-source microVM runtime, written in Rust. Powers AWS Lambda and AWS Fargate. Each Lambda invocation runs in its own Firecracker microVM.

Key properties:

• ~125ms cold start: Full VM boot in under 200ms
• ~5MB memory overhead: The microVM itself adds minimal memory vs the workload
• Minimal attack surface: Firecracker implements only the devices a Lambda function needs (virtio-net, virtio-block, serial console) — no USB, no PCI bus, no BIOS
• jailer: Runs the Firecracker process in a seccomp/cgroup jail before booting the guest

Architecture:

Host Linux (with KVM)
└── Firecracker VMM (uses KVM for hardware virtualization)
    └── MicroVM (minimal Linux kernel + guest app)
        └── Your function code

When to use Firecracker:

• Serverless platforms where you need VM isolation at container density/speed
• Running untrusted user code (code execution services, CI/CD sandboxes)
• Building Lambda-like platforms on your own infrastructure

Tools: containerd-firecracker-shim, Kata Containers (uses Firecracker as a backend), Flintlock (microVM lifecycle manager)

Cloud Hypervisor / QEMU microvm

Both Intel’s Cloud Hypervisor and QEMU’s microvm machine type provide similar capabilities to Firecracker — minimal device model, fast boot, low overhead. Cloud Hypervisor is used by Microsoft Azure for their container instances.

Kata Containers

What it is: Runs OCI containers inside lightweight VMs. From the outside it looks like Docker/Kubernetes — you use the same commands, same images. But each container (or pod) runs in its own VM with its own kernel.

Kubernetes
└── Kata shim (looks like containerd to Kubernetes)
    └── Firecracker or QEMU microvm
        └── Guest Linux kernel
            └── Your container (runc inside the VM)

The use case: Multi-tenant Kubernetes where container isolation isn’t strong enough. Financial services, cloud providers running customer workloads, any environment where a kernel exploit in one container must not affect others.

Proxmox VE: The Homelab and SMB Hypervisor

What it is

Proxmox Virtual Environment is a Debian-based open-source platform that wraps KVM (for VMs) and LXC (for system containers) in a polished web UI, REST API, and clustering system. It’s free to use; the paid subscription gives you access to the enterprise repository and support.

Architecture:

Bare metal hardware
└── Proxmox VE (Debian + KVM + LXC + web UI)
    ├── KVM Virtual Machines
    │   ├── Windows Server VM
    │   ├── Ubuntu VM
    │   └── pfSense VM
    └── LXC Containers
        ├── nginx container
        ├── PostgreSQL container
        └── Home Assistant container

Key features

Unified management: Manage KVM VMs and LXC containers from the same web UI. Create, start, stop, migrate, snapshot — all in one place.

Clustering: Join multiple Proxmox nodes into a cluster. VMs and containers can live migrate between nodes. Shared storage via NFS, iSCSI, Ceph, or ZFS over iSCSI.

Ceph integration: Proxmox has first-class Ceph support. Build a hyperconverged infrastructure where compute and storage run on the same nodes.

ZFS: Deep ZFS integration for storage. VM disks live on ZFS datasets, giving you instant snapshots, send/receive for backup, compression, and checksumming.

Backup with Proxmox Backup Server (PBS): Incremental backups, deduplication, encryption, retention policies. PBS is a separate product but integrates seamlessly.

SPICE/VNC console: Browser-based console access to every VM/container.

SDN (Software Defined Networking): VXLAN overlays, EVPN, zone-based network policies.

Templates and cloud-init: Download community templates for LXC containers, build VM templates with cloud-init for fast deployment.

The subscription model

Proxmox is free — you can use every feature without paying. The subscription ($100–$1,200/year per node depending on tier) gives:

• Access to the enterprise repository (more stable, tested updates)
• Commercial support
• Proxmox Backup Server enterprise repo

The no-subscription repository exists and works fine for homelab use. The “no valid subscription” banner in the web UI can be dismissed.

When to use Proxmox

• Homelab: The dominant choice for running multiple VMs and containers on a single machine or small cluster
• SMB/branch office: Replace aging VMware deployments at a fraction of the cost
• Development/test lab: Mixed Windows/Linux workloads on shared hardware
• Edge computing: Proxmox is lightweight enough to run on modest hardware
• Where VMware used to make sense but Broadcom pricing killed it

Proxmox vs VMware vSphere

Docker vs LXC vs KVM: The Core Decision

The question “should I use Docker or a VM?” is usually the wrong question. Here’s the actual decision tree:

Do you need to run Windows or a non-Linux OS?

Yes → KVM/VMware/Hyper-V. Only a full VM can run a different kernel. No container technology can run Windows.

Do you need multiple persistent, mutable Linux OS instances?

Yes → LXC/LXD or KVM. If you want separate /etc, separate package managers, separate systemd instances, and persistent state that survives reboots — use system containers (LXC) or VMs. Docker containers are not designed for this.

Is this a stateless application with well-defined external dependencies?

Yes → Docker/Podman. Web servers, API services, microservices — anything that reads config from environment variables and stores state in an external database. Docker’s image model (build once, run anywhere) and compose-based orchestration are purpose-built for this.

Is this an HPC workload on a cluster where you don’t have root?

Yes → Singularity/Apptainer. Docker won’t work. Singularity was built for exactly this.

Do you need VM-level isolation but container-level density and startup speed?

Yes → Kata Containers or Firecracker. Running untrusted third-party code, multi-tenant platforms, serverless functions.

Is this a homelab or on-premise server?

KVM via Proxmox for the underlying infrastructure. Then either KVM VMs or LXC containers depending on your workload needs. Docker/Podman for application workloads on top of that.

Performance Comparison

Numbers are approximate and workload-dependent. Use as rough guidance:

Security Isolation Comparison

Choosing for Specific Scenarios

Home lab running multiple services (Plex, Home Assistant, Nextcloud, etc.): Proxmox with a mix of LXC containers (for simple services) and KVM VMs (for anything that needs full OS isolation or Windows). LXC for stateless/simple services, KVM for your pfSense router VM and Windows gaming VM.

Development machine (running test environments locally): Docker Compose for application stacks. VMware Fusion or Parallels (macOS) / VirtualBox (Linux/Windows) for full OS testing. WSL2 if you’re on Windows.

Kubernetes cluster nodes: Docker or containerd as the container runtime, with kubelet talking to containerd directly. Podman is also supported. Don’t use VMs for the container runtime layer (you add overhead without benefit).

Multi-tenant cloud platform (running customer workloads): KVM for the hypervisor layer, Kata Containers or Firecracker for the container isolation layer. Never run untrusted container workloads in standard Docker with shared kernel.

University HPC cluster: Singularity/Apptainer. No other option integrates with SLURM, handles MPI, and works rootlessly.

CI/CD pipeline (building images in Kubernetes): Kaniko or Buildah for building container images without a Docker socket. containerd as the runtime.

Edge/IoT with limited hardware: Podman (no daemon, lower memory) or LXC for maximum density. KVM if you need to run multiple OS types.

Bioinformatics workflows (Nextflow/Snakemake pipelines): Singularity/Apptainer for cluster execution, Docker for local development. Both Nextflow and Snakemake support either.

The Ecosystem Map

┌─────────────────────────────────────────────────────────────────┐
│                    FULL VM (separate kernel)                     │
│                                                                  │
│  KVM ──────── Proxmox VE        VMware ESXi ──── vSphere        │
│  (open source, bare metal)      (enterprise, expensive)          │
│                                                                  │
│  VirtualBox ── Vagrant           VMware Workstation/Fusion       │
│  (desktop, free)                 (desktop, now free)             │
│                                                                  │
│  Firecracker ─ Kata Containers   Cloud Hypervisor                │
│  (microVM, serverless)           (Azure)                         │
├─────────────────────────────────────────────────────────────────┤
│              OS-LEVEL (shared kernel, full OS userspace)         │
│                                                                  │
│  LXC/LXD ──── Proxmox LXC       OpenVZ/Virtuozzo                │
│  (system containers)             (legacy VPS hosting)            │
├─────────────────────────────────────────────────────────────────┤
│           APPLICATION (shared kernel, single process)            │
│                                                                  │
│  Docker ──── Docker Compose      Podman ─── Podman Compose       │
│  (dominant, daemon-based)        (rootless, daemonless)          │
│                                                                  │
│  containerd ─ cri-o              Singularity/Apptainer           │
│  (Kubernetes runtimes)           (HPC, rootless)                 │
└─────────────────────────────────────────────────────────────────┘

Summary: The One-Line Guide

The technology landscape is richer than “Docker vs VMs.” Pick the tool that matches your isolation requirements, your operational model, and your hardware constraints — not the one you heard about first.