Overview

• What you’ll learn: The foundational concepts of virtualization, including hypervisor types, hardware-assisted virtualization, paravirtualization vs full virtualization, and how containers differ from virtual machines.
• Prerequisites: Basic Linux system administration knowledge (Modules 1-3)
• Estimated reading time: 18 minutes

Introduction

Virtualization is the technology that allows a single physical machine to run multiple isolated operating system instances simultaneously. It is one of the most transformative technologies in modern computing, enabling efficient resource utilization, rapid provisioning, and flexible infrastructure management. From enterprise data centers to cloud platforms like AWS, Azure, and GCP, virtualization is the foundation upon which modern IT infrastructure is built.

Before virtualization became mainstream, each application or service typically required its own dedicated physical server. This led to significant hardware underutilization, with most servers running at only 10-15% of their capacity. Virtualization solved this problem by abstracting the hardware layer, allowing multiple virtual machines to share a single physical host while maintaining complete isolation from one another.

In this lesson, we will explore the core concepts behind virtualization technology, examine the different types of hypervisors, understand hardware-assisted virtualization extensions provided by Intel and AMD, compare paravirtualization with full virtualization, and finally compare traditional virtual machines with the newer container-based approach to isolation.

Types of Hypervisors

A hypervisor (also called a Virtual Machine Monitor or VMM) is the software layer that creates and manages virtual machines. It sits between the physical hardware and the virtual machines, allocating resources and ensuring isolation. Hypervisors are classified into two types based on their architecture.

Type 1 Hypervisors (Bare-Metal)

Type 1 hypervisors run directly on the physical hardware without a host operating system. They have direct access to hardware resources, which provides superior performance and lower overhead. The hypervisor itself acts as a minimal operating system whose sole purpose is to manage virtual machines.

• KVM (Kernel-based Virtual Machine): Built into the Linux kernel since version 2.6.20, KVM turns the Linux kernel itself into a Type 1 hypervisor. It leverages hardware virtualization extensions to provide near-native performance.
• VMware ESXi: A commercial bare-metal hypervisor widely used in enterprise data centers. It provides advanced features like vMotion (live migration) and High Availability.
• Microsoft Hyper-V: Microsoft’s hypervisor, available both as a standalone product and as a Windows Server role.
• Xen: An open-source hypervisor originally developed at the University of Cambridge, used by AWS for its early EC2 infrastructure.

Type 2 Hypervisors (Hosted)

Type 2 hypervisors run as applications on top of an existing host operating system. They rely on the host OS to manage hardware access, which introduces additional overhead but provides ease of use for development and testing scenarios.

• VirtualBox: An open-source Type 2 hypervisor from Oracle, popular for desktop virtualization and development environments.
• VMware Workstation / Fusion: Commercial desktop virtualization products for Windows/Linux and macOS respectively.
• QEMU (without KVM): When running without KVM acceleration, QEMU operates as a Type 2 hypervisor using software emulation.

# Check if your CPU supports hardware virtualization
$ egrep -c '(vmx|svm)' /proc/cpuinfo
8

# Check if KVM modules are loaded (Type 1 on Linux)
$ lsmod | grep kvm
kvm_intel            368640  0
kvm                 1028096  1 kvm_intel

# View KVM capabilities
$ cat /sys/module/kvm_intel/parameters/nested
Y

The command above checks for Intel VT-x (vmx) or AMD-V (svm) flags in the CPU information. A non-zero result means hardware virtualization is supported. The lsmod command verifies that the KVM kernel modules are loaded.

Hardware Virtualization Extensions

Modern CPUs include specialized instructions that enable efficient virtualization. Without these extensions, the hypervisor must use complex and slower software techniques to trap and emulate privileged instructions executed by guest operating systems.

Intel VT-x and AMD-V

Intel VT-x (Virtualization Technology for x86) and AMD-V (AMD Virtualization) provide hardware support for virtualizing the CPU. These extensions introduce a new privilege level specifically for hypervisors, allowing guest operating systems to execute most instructions directly on the CPU without intervention from the hypervisor.

• Root mode: The hypervisor runs in VMX root mode with full control over the hardware.
• Non-root mode: Guest VMs run in VMX non-root mode. Certain privileged operations trigger a VM exit, transferring control to the hypervisor.

Second Level Address Translation (SLAT)

Memory virtualization was initially handled through shadow page tables, which the hypervisor maintained by intercepting all guest page table modifications. Modern CPUs support SLAT through Intel EPT (Extended Page Tables) or AMD RVI (Rapid Virtualization Indexing), which provides hardware-assisted translation between guest physical addresses and host physical addresses.

# Verify Intel VT-x or AMD-V support
$ cat /proc/cpuinfo | grep -E 'vmx|svm' | head -1
flags : ... vmx ...

# Check BIOS/UEFI virtualization setting via dmesg
$ dmesg | grep -i 'virtualization'
[    0.204000] kvm: Nested Virtualization enabled
[    0.204001] kvm: Virtualization Technology (VT-x) enabled

# Verify Intel EPT support
$ cat /sys/module/kvm_intel/parameters/ept
Y

I/O Virtualization (VT-d / IOMMU)

Intel VT-d (Virtualization Technology for Directed I/O) and AMD IOMMU provide hardware-assisted I/O virtualization. These technologies allow virtual machines to have direct access to physical hardware devices (called PCI passthrough) with near-native performance, which is critical for workloads that require high-performance I/O such as GPU computing or network-intensive applications.

Paravirtualization vs Full Virtualization

Two fundamental approaches exist for handling the interaction between guest operating systems and the physical hardware: full virtualization and paravirtualization.

Full Virtualization

In full virtualization, the guest operating system runs unmodified, completely unaware that it is running inside a virtual machine. The hypervisor presents a complete virtual hardware platform that looks identical to real hardware. Binary translation or hardware-assisted virtualization is used to handle privileged instructions from the guest.

• Advantage: No modification to the guest OS required; any operating system that supports the hardware architecture can run.
• Disadvantage: Without hardware assistance, binary translation introduces overhead. With VT-x/AMD-V, this overhead is minimal.

Paravirtualization

In paravirtualization, the guest operating system is modified to be aware that it is running in a virtualized environment. Instead of executing privileged instructions directly, the guest uses hypercalls — special API calls to the hypervisor — to request operations like memory management or I/O. Xen pioneered this approach.

• Advantage: Can be more efficient than full virtualization without hardware assistance, as hypercalls avoid the overhead of trapping and emulating instructions.
• Disadvantage: Requires modifications to the guest OS kernel, which means proprietary operating systems cannot easily benefit.

Virtio: The Modern Compromise

Modern Linux virtualization uses virtio, a standardized interface for paravirtualized I/O devices. While the guest CPU runs in full virtualization mode using hardware extensions, I/O devices (disk, network, etc.) use paravirtualized virtio drivers for optimal performance.

# Check for virtio devices in a guest VM
$ lspci | grep -i virtio
00:03.0 Ethernet controller: Red Hat, Inc. Virtio network device
00:04.0 SCSI storage controller: Red Hat, Inc. Virtio block device

# View loaded virtio kernel modules
$ lsmod | grep virtio
virtio_net             65536  0
virtio_blk             20480  2
virtio_pci             28672  0
virtio_ring            36864  3 virtio_net,virtio_blk,virtio_pci
virtio                 20480  3 virtio_net,virtio_blk,virtio_pci

Containers vs Virtual Machines

While virtual machines provide hardware-level isolation by running complete operating system instances, containers offer a lighter-weight alternative by sharing the host kernel and isolating applications at the process level using Linux kernel features.

Virtual Machines

• Run a complete guest OS with its own kernel
• Strong isolation through hardware-level separation
• Higher resource overhead (each VM needs its own memory, CPU allocation, kernel)
• Boot time measured in seconds to minutes
• Ideal for running different operating systems or when strong security isolation is required

Containers

• Share the host kernel; only the user-space environment is isolated
• Use Linux namespaces (pid, net, mnt, uts, ipc, user) for isolation
• Use cgroups (control groups) for resource limiting (CPU, memory, I/O)
• Minimal overhead; near-native performance
• Start in milliseconds
• Ideal for microservices, CI/CD, and application packaging

# View Linux namespaces for a process
$ ls -la /proc/self/ns/
lrwxrwxrwx 1 root root 0 Dec  1 10:00 cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx 1 root root 0 Dec  1 10:00 ipc -> 'ipc:[4026531839]'
lrwxrwxrwx 1 root root 0 Dec  1 10:00 mnt -> 'mnt:[4026531841]'
lrwxrwxrwx 1 root root 0 Dec  1 10:00 net -> 'net:[4026531840]'
lrwxrwxrwx 1 root root 0 Dec  1 10:00 pid -> 'pid:[4026531836]'
lrwxrwxrwx 1 root root 0 Dec  1 10:00 user -> 'user:[4026531837]'
lrwxrwxrwx 1 root root 0 Dec  1 10:00 uts -> 'uts:[4026531838]'

# View cgroup resource limits
$ cat /sys/fs/cgroup/memory/memory.limit_in_bytes
9223372036854771712

# Create a simple namespace isolation example
$ sudo unshare --fork --pid --mount-proc bash -c 'ps aux'
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   7236  4020 pts/0    S    10:00   0:00 bash

The unshare command demonstrates the PID namespace: inside the new namespace, the shell process appears as PID 1, completely isolated from the host’s process tree. This is the same mechanism that container runtimes use to isolate processes.

Key Takeaways

• Type 1 (bare-metal) hypervisors like KVM run directly on hardware for maximum performance, while Type 2 (hosted) hypervisors like VirtualBox run on top of a host OS for convenience.
• Intel VT-x and AMD-V provide hardware-assisted CPU virtualization, while EPT/RVI handle memory virtualization and VT-d/IOMMU enable direct I/O device access.
• Full virtualization runs unmodified guest OSes, while paravirtualization uses hypercalls for better performance; modern Linux uses virtio as a hybrid approach for I/O.
• Containers use Linux namespaces and cgroups to provide lightweight process-level isolation, sharing the host kernel rather than running a complete guest OS.
• Virtual machines offer stronger isolation and support multiple OS types, while containers offer faster startup, lower overhead, and are ideal for microservices architectures.

What’s Next

In Lesson 55, you will learn about QEMU/KVM Virtual Machines, including how to create and manage virtual machines using QEMU with KVM acceleration, work with disk image formats, and configure CPU and memory allocation on Ubuntu.

# 檢查 CPU 是否支援硬體虛擬化
$ egrep -c '(vmx|svm)' /proc/cpuinfo
8

# 檢查 KVM 模組是否已載入
$ lsmod | grep kvm
kvm_intel            368640  0
kvm                 1028096  1 kvm_intel

# 驗證 Intel VT-x 或 AMD-V 支援
$ cat /proc/cpuinfo | grep -E 'vmx|svm' | head -1
flags : ... vmx ...

# 驗證 Intel EPT 支援
$ cat /sys/module/kvm_intel/parameters/ept
Y

# 在客戶 VM 中檢查 virtio 裝置
$ lspci | grep -i virtio
00:03.0 Ethernet controller: Red Hat, Inc. Virtio network device
00:04.0 SCSI storage controller: Red Hat, Inc. Virtio block device

# 查看行程的 Linux 命名空間
$ ls -la /proc/self/ns/

# 使用 unshare 建立簡單的命名空間隔離
$ sudo unshare --fork --pid --mount-proc bash -c 'ps aux'
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   7236  4020 pts/0    S    10:00   0:00 bash

# CPU がハードウェア仮想化をサポートしているか確認
$ egrep -c '(vmx|svm)' /proc/cpuinfo
8

# KVM モジュールがロードされているか確認
$ lsmod | grep kvm
kvm_intel            368640  0
kvm                 1028096  1 kvm_intel

# Intel VT-x または AMD-V サポートを確認
$ cat /proc/cpuinfo | grep -E 'vmx|svm' | head -1

# Intel EPT サポートを確認
$ cat /sys/module/kvm_intel/parameters/ept
Y

# ゲスト VM で virtio デバイスを確認
$ lspci | grep -i virtio
00:03.0 Ethernet controller: Red Hat, Inc. Virtio network device
00:04.0 SCSI storage controller: Red Hat, Inc. Virtio block device

# プロセスの Linux 名前空間を表示
$ ls -la /proc/self/ns/

# unshare で簡単な名前空間分離の例
$ sudo unshare --fork --pid --mount-proc bash -c 'ps aux'