Junior Level

Simple Explanation

Imagine you need to run several applications on one computer. There are two approaches:

Virtual Machine (VM) — it’s like building a separate house for each application. Each house has its own foundation, walls, roof. Full-featured, but expensive and slow.

Virtual Machine (VM) — emulation of a full computer with its own OS kernel, running on top of a hypervisor. Hypervisor — software layer that creates and manages VMs (KVM, ESXi, VirtualBox).

Container — it’s like rooms in one house. All rooms share the same foundation and roof (OS kernel), but each room is isolated by its own walls.

Analogy

• VM = separate house with full infrastructure (electricity, plumbing, heating)
• Container = room in a dormitory (shared utilities, but own wall and lock)

Key Differences

	Virtual Machine	Container
Size	Gigabytes	Megabytes
Startup	Minutes	Seconds
Resources	Each VM takes lots of RAM and CPU	Containers share resources efficiently
OS	Each VM has its own full operating system	All containers use the host OS kernel

Example

# Virtual machine: need to install OS, wait for boot, configure
# It's like buying and setting up a new computer

# Container: one command
docker run -d -p 8080:8080 myapp
# It's like running a new program on a computer

When to Use What

• VM — when you need full isolation or different OSes (e.g., Windows on a Linux server)
• Containers — for modern applications, microservices, fast development and deployment

What to Remember

• Containers are lighter and faster than VMs. Lighter — because there’s no OS duplication (each VM carries its own OS, containers share the host kernel). Faster — because there’s no kernel boot, just process startup.
• VMs provide stricter isolation
• Containers share the OS kernel, VMs have their own
• Kubernetes is used to manage containers in production

When NOT to Use Containers Instead of VMs

1. Full isolation needed (multi-tenancy) — VMs are more reliable
2. Different OS required (Windows on Linux) — containers share the kernel
3. Compliance requires hardware isolation — VMs

---

Middle Level

Architectural Differences

Virtual Machines (Hardware Virtualization)

VMs run on a hypervisor:

• Type 1 (bare-metal): ESXi, KVM — run directly on hardware
• Type 2 (hosted): VirtualBox, VMware Workstation — run on top of OS

Each VM includes: full copy of the OS, its own kernel and drivers, system utilities, application. Physical hardware is virtualized (CPU, RAM, Disk).

Containers (OS Virtualization)

Containers run on a Container Engine (Docker, containerd). All containers use the host OS kernel. System resources are virtualized through Linux kernel mechanisms: Namespaces (logical isolation) and Cgroups (consumption limits).

Detailed Comparison

Characteristic	Virtual Machines	Containers
Isolation	Strong: at hardware interrupt level	Weaker: logical process isolation
Resources	High overhead from Guest OS	Minimal (almost like a native process)
Startup time	1-5 minutes (full OS boot)	< 1 second (process start)
Size	Gigabytes (OS duplication)	Megabytes (application + dependencies only)
Filesystem	Block device (Disk Image)	Layered FS (UnionFS) — layers are reused

Typical Mistakes

Mistake	Consequence	How to avoid
Choosing containers for multi-tenancy	Container escape risk	Use VMs or MicroVMs
Ignoring UnionFS overhead	Slow disk I/O	Minimize number of layers
Running Windows apps in Linux containers	Doesn’t work	Use VMs or Wine containers
Expecting full container isolation	Kernel vulnerability = compromise all	Harden, seccomp, AppArmor

UnionFS — Key to Efficiency

Containers use layered filesystems (Overlay2, AUFS):

• Each layer is a set of changes
• Layers are reused between containers
• If 10 containers use openjdk:17, base layers are stored once

Hybrid Approach

MicroVMs for containers (AWS Fargate, Kata Containers, Firecracker) — combine container speed with VM isolation. Each “container workload” runs in its own micro-VM with a lightweight kernel.

What to Remember

• Containers are processes with enhanced isolation
• VMs are full systems with hardware emulation
• UnionFS allows containers to save resources
• Containers are less secure but much faster and lighter
• Hybrid solutions are used for critical isolation

---

Senior Level

Fundamental Analysis: Levels of Abstraction

Choosing between containers and VMs is choosing a level of abstraction that determines architecture, security, cost, and operational model.

Deep Architecture

# VM: hardware virtualization
Application → Guest OS → Hypervisor (VMX root mode) → Hardware

# Containers: OS-level virtualization
Application → Dependencies → Host kernel (Namespaces + Cgroups + Seccomp) → Hardware

The hypervisor intercepts privileged CPU instructions (via Intel VT-x / AMD-V) and emulates hardware. This adds overhead on every system call. A container is a regular Linux process restricted by kernel syscalls. No emulation, no intermediate layers.

Security Analysis

Aspect	VM	Containers
Attack surface	Hypervisor (small, audited)	Linux kernel (large, shared)
Escape risk	Extremely rare, but possible via hypervisor vulnerabilities (CVE-2021-26326)	Real (CVEs in kernel, runc)
Multi-tenancy	Secure by default	Requires additional measures
Compliance	Suitable for strict regulators	Requires hardening

Container Escape vectors:

• Linux kernel vulnerabilities (Dirty COW, CVE-2022-0492 cgroups)
• Misconfigured capabilities (CAP_SYS_ADMIN = practically root)
• Mounting sensitive paths (/proc, /sys, /var/run/docker.sock)
• Running as root without restrictions

Mitigation:

• Seccomp profiles (restrict available syscalls)
• AppArmor / SELinux (Mandatory Access Control)
• Read-only root filesystem
• Drop all capabilities, add only needed
• User namespaces (UID mapping: root in container ≠ root on host)

Performance: Detailed Analysis

Containers:

• CPU overhead: < 1% (direct syscall)
• Memory overhead: ~few MB per container
• Network: nearly native (uses host stack)
• Disk I/O: possible overhead from UnionFS (Overlay2 adds one copy-on-write layer)

VMs:

• CPU overhead: 5-15% (depends on hypervisor, paravirtualization reduces it)
• Memory overhead: GB per Guest OS
• Network: requires NIC virtualization (virtio reduces overhead)
• Disk I/O: requires storage controller virtualization

Economic Analysis

Metric	Containers	VMs
Density	100+ per server	10-30 per server
CPU utilization	60-80%	20-40%
Deploy time	Seconds	Minutes
Operational costs	Lower (automation)	Higher (manual mgmt)

Modern Trends

1. MicroVMs: Firecracker (AWS Lambda/Fargate), Kata Containers — VM security + container speed. Firecracker boots a micro-VM in ~125ms with ~5MB RAM overhead.
2. WebAssembly (Wasm): even lighter isolation, user-space sandbox, potential container competitor.
3. eBPF: allows customizing kernel behavior without code modification — a new paradigm for container observability and security.
4. Confidential Containers: Intel TDX, AMD SEV-SNP — CPU-level container memory encryption, protection from compromised hypervisor.

Trade-offs

Requirement	Best choice	Why
Maximum deployment speed	Containers	Millisecond startup
Multi-tenancy / strict compliance	VM / MicroVMs	Hardware isolation
Heterogeneous OSes	VMs	Each VM with own kernel
High-density microservices	Containers	100+ per server
Legacy apps with kernel dependencies	VMs	Full kernel control

Edge Cases

• Nested virtualization: VM inside a VM. Needed for CI/CD with Docker-in-Docker on VMs. Not supported by all hypervisors.
• Real-time kernels: Containers on PREEMPT_RT kernel hosts can get guaranteed response time, but cgroups doesn’t provide real-time guarantees.
• GPU passthrough: VMs — SR-IOV or NVIDIA vGPU. Containers — NVIDIA Container Toolkit (direct GPU access via device cgroup).

Summary

• Containers are processes with enhanced isolation. VMs are full systems with hardware emulation.
• Choice is driven by security requirements, not just performance.
• For multi-tenancy and strict compliance — VMs or MicroVMs. For speed and CI/CD — containers.
• At scale, containers give 3-5x better resource utilization.
• Hybrid approaches (MicroVMs, Kata) blur the line between technologies.
• Understand trade-offs: security vs speed, isolation vs efficiency.

---

Interview Cheat Sheet

Must know:

• VM virtualizes hardware (hypervisor), containers virtualize OS (namespaces + cgroups)
• Containers: seconds startup, MB size, < 1% CPU overhead
• VMs: minutes startup, GB size, 5-15% CPU overhead
• UnionFS allows containers to reuse layers (disk/RAM savings)
• MicroVMs (Firecracker, Kata) combine container speed + VM isolation
• Container escape is possible through kernel vulnerabilities, misconfigured capabilities
• For multi-tenancy — VMs, for CI/CD — containers

Frequent follow-up questions:

• “What is a hypervisor?” — Layer between hardware and VMs (KVM, ESXi). Type 1 — bare-metal, Type 2 — hosted
• “Why are containers less secure?” — Shared kernel: kernel vulnerability = compromise of all containers
• “What is a MicroVM?” — Lightweight VM (~5MB RAM, 125ms boot) with VM security and container speed
• “What does seccomp do?” — Restricts container’s available syscalls, reduces attack surface

Red flags (DO NOT say):

• “Containers are more secure than VMs” (opposite, shared kernel attack surface)
• “VMs and containers are the same thing” (different abstraction levels)
• “Container escape is impossible” (real through kernel/runc CVEs)
• “A container can boot its own kernel” (shares host kernel)

Related topics:

• [[What is containerization and why is it needed]] — containerization basics
• [[What is Pod in Kubernetes]] — containers in K8s
• [[What is Dockerfile]] — creating images