Virtualization and Containers

Understanding Virtualization and Containers

Virtualization and containers both let you run multiple isolated environments on the same physical machine, but they do it in very different ways. This chapter gives you a practical mental model so that later chapters (KVM/QEMU, LXC/LXD, Docker, Podman, etc.) make sense.

Virtualization vs Containers: The Big Picture

At a high level:

• Virtualization simulates hardware so you can run entire operating systems (called virtual machines, or VMs).
• Containers share the host kernel but isolate applications and their user space.

You can visualize it like this:

• Virtualization stack
  Hardware → Hypervisor → Guest OS → Applications
• Container stack
  Hardware → Host OS + Kernel → Container runtime → Applications (in containers)

Both approaches give you isolation, but with different trade‑offs in performance, flexibility, and security boundaries.

Types of Virtualization

When people say “virtualization” on Linux, they often mean running VMs. There are multiple styles of virtualization:

Full Virtualization

Full virtualization emulates enough hardware that the guest OS doesn’t know it’s virtualized.

• Guest can be unmodified (no special drivers or patches needed).
• Usually uses hardware support like Intel VT-x or AMD-V.
• Examples: KVM (with QEMU), VMware ESXi, VirtualBox.

Implications:

• Can run different operating systems: Linux, BSD, Windows, etc.
• Strong isolation because each VM runs its own kernel.
• More overhead (RAM, disk, CPU) because each VM includes a full OS.

Paravirtualization

Paravirtualized guests are aware they’re running in a virtual environment and use special interfaces to access hardware.

• Requires a modified guest OS (or special guest drivers).
• Less hardware emulation, so better performance for some operations.
• Historically seen in Xen; today you mainly encounter paravirtualized drivers (e.g., virtio-net, virtio-blk) within otherwise “full” VMs.

In practice, modern Linux virtualization often uses:

• Full virtualization + paravirtualized devices (for performance).

Hardware-Assisted Virtualization

Modern CPUs have special extensions:

• Intel VT-x, AMD-V, VT-d (IOMMU), etc.

They allow the hypervisor to run guest OS code directly on the CPU with support for:

• Privileged instructions trapping to the hypervisor.
• Efficient context switching between guests.

Without these features, virtualization relies on slower techniques like binary translation or pure emulation.

Hypervisors: Type 1 vs Type 2

A hypervisor is the component that manages VMs.

Type 1 (Bare-Metal) Hypervisors

• Run directly on hardware, without a “host OS” in the usual sense.
• Examples: VMware ESXi, Xen in some configurations, Hyper-V (conceptually).

On Linux, KVM is often described as type 1 because:

• The Linux kernel itself acts as the hypervisor (with KVM module).
• The same kernel also provides a regular OS environment.

So you get hypervisor + full Linux host in one.

Type 2 (Hosted) Hypervisors

• Run as applications on top of a host OS.
• Examples: VirtualBox on Linux desktop, VMware Workstation.

They are easier to install and use for development, but:

• Add extra layers (host OS → hypervisor → guest), which can add overhead.
• Often used on laptops/desktops for testing multiple OSes.

KVM/QEMU, which you’ll see in a later chapter, is a mix:

• The KVM kernel module provides efficient CPU virtualization (type 1 behavior).
• QEMU runs as a user-space emulator (type 2 component) to provide hardware devices and manage the VM process.

Containers: OS-Level Virtualization

Where virtualization gives each guest a full OS, containers:

• Share the same kernel as the host.
• Isolate processes using kernel features such as:
• Namespaces (isolation of process IDs, networking, filesystems, etc.)
• cgroups (resource limits and accounting)
• Capabilities, SELinux/AppArmor (security policies)

You’ll meet these concepts in more detail in the Linux Internals and security chapters; for now just remember:

• Containers are “fancy processes with strong isolation,” not full machines.

Images, Layers, and Union Filesystems

Containers are usually built from images:

• An image is a set of filesystem layers (e.g., base OS + your app + configuration).
• Union/overlay filesystems (e.g., OverlayFS) let the runtime combine layers:
• Read-only image layers.
• A writable layer per container.

Benefits:

• Images are portable and versioned.
• Many containers can share the same base image layers to save disk.

You’ll explore these mechanisms concretely in the Docker fundamentals and Podman chapters.

Comparing Virtual Machines and Containers

Resource Usage

• VMs:
• Each VM has its own kernel and full OS stack.
• RAM and disk are typically allocated per VM.
• Heavier but predictable isolation.
• Containers:
• Share the host kernel.
• Start faster and use less memory.
• Many more instances can run on the same hardware.

Isolation and Security

• VMs:
• Hardware-level isolation.
• If a guest is compromised, the attacker generally needs an additional escape to reach the hypervisor or host.
• Better suited when strict multi-tenant isolation is required.
• Containers:
• Isolated at the kernel level, but all containers share that kernel.
• Kernel vulnerabilities can have a bigger impact.
• Hardening with namespaces, seccomp, SELinux/AppArmor, and dropping capabilities is critical in production.

Flexibility and Compatibility

• VMs:
• Can run different kernels and operating systems.
• Good for:
• Testing multiple OS versions.
• Running Windows on a Linux host (or vice versa).
• Legacy workloads that assume full machine control.
• Containers:
• Same kernel as host, usually same OS family.
• Good for:
• Packaging and shipping applications.
• Microservices.
• CI/CD pipelines.

A typical rule of thumb:

• Use VMs when you need a full environment or strong isolation.
• Use containers when you primarily need application packaging and quick, lightweight instances.

Common Linux Virtualization and Container Tools (High Level)

The following tools and technologies each get their own detailed chapter later. Here we only map them to the concepts you just learned.

Virtualization Tools

• KVM/QEMU
• KVM: kernel module providing hardware-assisted virtualization.
• QEMU: user-space hypervisor/emulator managing VM processes and devices.
• Often used with:
• libvirt as a management layer.
• GUI tools like virt-manager.
• LXC/LXD (as system containers)
• Uses container mechanisms but often called “system containers.”
• Provide an environment similar to a lightweight VM (full Linux user space in each container).
• Closer to “virtual machines using containers” than typical application containers.

Container Tools

• Docker
• Popular container engine and CLI.
• Uses images built from Dockerfiles.
• Historically introduced common concepts like registries, layers, and Compose.
• Podman
• Daemonless container engine, often considered a “drop-in” replacement for Docker CLI.
• Integrates well with rootless containers and systemd.
• Used heavily in enterprise Linux distributions (e.g., Fedora, RHEL).
• Container Orchestrators (context only)
• Kubernetes, OpenShift, etc., manage large numbers of containers across clusters.
• The focus here is on local/container technologies; full orchestration is usually a separate topic.

Typical Use Cases and Patterns

Understanding common patterns will help you choose between VMs and containers in real scenarios.

Development and Testing

• Spin up a full VM to:
• Test a new distribution or major OS change.
• Simulate realistic “server” environments.
• Use containers to:
• Package your application with exact dependencies.
• Run many test instances quickly in CI pipelines.

Production Servers

• Run multiple VMs on one physical host to:
• Separate different services (e.g., database, application server, reverse proxy).
• Isolate environments (production vs staging).
• Then use containers inside those VMs to:
• Deploy individual microservices.
• Implement blue/green deployments, rolling updates, etc.

This “VMs for isolation, containers for apps” layering is extremely common.

Desktop and Homelab

• Virtual machines:
• Trying out new Linux distributions.
• Running another OS for a specific application.
• Containers:
• Running services (e.g., Nextcloud, Jellyfin, development databases).
• Experimenting with software without installing it directly on your host.

Performance Considerations

The details depend on specific workloads and configurations, but general trends are:

• CPU:
• VMs use hardware virtualization; overhead is usually modest but higher than containers.
• Containers run almost at native speed since they use host processes.
• Memory:
• Each VM needs its own OS and kernel; memory overcommit is possible but needs tuning.
• Containers share more, so overall memory usage is typically lower.
• I/O:
• VMs often access storage via virtual disks; performance depends on drivers (e.g., virtio).
• Containers read/write through the host filesystem; overlay layers can impact performance, especially with many small file operations.

You’ll see practical tuning and tools for measuring performance in other chapters (e.g., System Monitoring, Performance Tuning).

Security and Best-Practice Overview

Security is a deep topic, covered in security-focused chapters. For virtualization and containers, remember these baseline ideas:

• For VMs:
• Keep hypervisor and host kernel updated.
• Limit management interfaces (e.g., SSH, libvirt) to trusted networks.
• Use strong disk and network isolation between tenants.
• For containers:
• Don’t run as root inside containers unless strictly necessary.
• Use minimal, well-maintained base images.
• Apply security profiles (seccomp, SELinux/AppArmor).
• Treat containers as untrusted input in multi-tenant scenarios unless you design otherwise.

How This Fits into the Rest of the Course

Later chapters in this part will build on this conceptual base:

• Virtual machines (KVM/QEMU):
  Hands-on creation and management of Linux VMs, including networking and storage.
• Linux containers (LXC/LXD):
  System containers that feel like lightweight VMs.
• Docker fundamentals:
  Application containers, building images, running and managing them.
• Podman vs Docker:
  Differences in architecture and workflows, especially for rootless containers.
• Container networking:
  How containers communicate with each other and the outside world.

Keep this chapter in mind as your “map” of the space: VMs vs containers, where each fits, and what tools implement which ideas.