LFCE 143 🐧 KVM — Concepts
KVM is the Linux kernel’s native virtualization infrastructure. It is not a separate hypervisor that runs alongside the kernel; it is a kernel module that turns the Linux kernel itself into a Type-1 hypervisor. When the module is loaded, the kernel gains the ability to run virtual machines as ordinary Linux processes, each with its own virtualized CPU, memory, and devices . The physical CPU must support hardware virtualization extensions—Intel VT-x or AMD-V—because KVM relies on those extensions to execute guest code directly on the hardware rather than emulating it .
This chapter covers the conceptual foundation of KVM: the kernel module and the /dev/kvm device that exposes it, the QEMU userspace component that emulates devices and drives the virtual machine, the hardware virtualization extensions that make near-native performance possible, and the libvirt management layer that sits above both. It also covers the distinction between KVM as a hypervisor and QEMU as an emulator, because the two are always deployed together but are architecturally separate.
Key point: KVM does not emulate hardware. It provides the CPU virtualization and memory isolation. QEMU provides the device emulation and the userspace control plane. A KVM virtual machine is a QEMU process that uses /dev/kvm to run guest code directly on the host CPU.
Why KVM is built into the kernel
The Type-1 problem. Traditional Type-1 hypervisors are separate kernels that run below the operating system. They provide strong isolation but require a separate management stack, separate drivers, and a separate security model. KVM takes a different approach: it adds a new CPU execution mode to the Linux kernel and lets the existing kernel serve as the hypervisor. The kernel already has drivers, memory management, scheduling, and security infrastructure. KVM reuses all of it .
The process-model problem. In KVM, a virtual machine is a Linux process. The QEMU process that represents the VM is scheduled by the Linux scheduler, managed by systemd like any other service, and visible in top and ps. Killing the process terminates the VM. This is a different model from a hypervisor that runs VMs outside the host operating system, and it is why KVM’s performance and operational characteristics are so closely tied to the host kernel .
The hardware-extension problem. KVM requires Intel VT-x or AMD-V. These extensions add a new privilege level and a set of instructions for entering and exiting guest mode. KVM uses them to switch the CPU between host mode and guest mode without the overhead of binary translation or paravirtualization. The guest code runs on the physical CPU at near-native speed .
a. The KVM kernel module and /dev/kvm
The KVM infrastructure consists of a loadable kernel module, kvm.ko, and a processor-specific module, kvm-intel.ko or kvm-amd.ko . When the modules are loaded, the kernel exposes a character device at /dev/kvm. Userspace processes—specifically QEMU—open this device and use ioctl() calls to create virtual machines, create virtual CPUs, map guest memory, and run the guest .
The /dev/kvm device is the interface between the kernel’s virtualization infrastructure and the userspace control plane. A process that has access to /dev/kvm can create and run virtual machines. The permissions on the device determine which users can use KVM. The kvm-ok command checks whether the CPU supports the required extensions and whether /dev/kvm exists .
b. QEMU and the separation of concerns
QEMU is the userspace component. It is a full machine emulator: it emulates the motherboard, the BIOS, the chipset, the disk controllers, the network cards, and the graphics adapters . When QEMU is used with KVM, the CPU virtualization is delegated to the kernel, but the device emulation remains in userspace.
The division is visible in the architecture. QEMU opens /dev/kvm, calls KVM_CREATE_VM to create a virtual machine, calls KVM_CREATE_VCPU to create a virtual CPU, and then runs a loop that calls KVM_RUN on each virtual CPU. When the guest executes an instruction that requires emulation—an I/O port access, a memory-mapped I/O access, or a privileged instruction that the hardware does not handle—the CPU exits guest mode and returns to QEMU. QEMU emulates the device operation and then resumes the guest .
This separation is why KVM is described as a hypervisor and QEMU as an emulator. KVM provides the fast path for CPU and memory. QEMU provides the slow path for devices. The fast path is what makes KVM competitive with native performance; the slow path is what makes it compatible with unmodified guest operating systems .
c. The hardware virtualization extensions
KVM’s performance depends on the CPU’s virtualization extensions. Intel VT-x adds a new mode called VMX (Virtual Machine Extensions). AMD-V adds a similar mode called SVM (Secure Virtual Machine). These modes allow the CPU to run guest code directly, with a separate set of control structures that define what the guest can access .
The control structure is the VMCS (Virtual Machine Control Structure) on Intel or the VMCB (Virtual Machine Control Block) on AMD. It stores the host CPU context, the guest CPU context, and the controls that determine which guest actions cause an exit to the hypervisor. KVM configures the VMCS before each KVM_RUN and reads the exit reason after the guest exits .
The hardware extensions are what make KVM a Type-1 hypervisor in practice. Without them, KVM cannot run. With them, the guest’s privileged instructions execute on the physical CPU, and the exits are limited to the operations that genuinely require emulation. The result is near-native performance for CPU-bound workloads and performance limited only by the device emulation path for I/O-bound workloads .
d. libvirt and the management layer
KVM and QEMU provide the virtualization. libvirt provides the management. It is a daemon and an API that abstracts the hypervisor-specific details and provides a consistent interface for creating, starting, stopping, migrating, and monitoring virtual machines .
The command-line tool virsh and the graphical tool virt-manager are libvirt clients. They do not talk to QEMU directly; they talk to the libvirt daemon, which talks to QEMU. The abstraction allows the same management tools to work with KVM, Xen, and other hypervisors. It also provides the storage and network management that a bare QEMU invocation does not .
For an LFCE context, the distinction matters because the management commands (virsh) and the virtualization concepts (KVM, QEMU) are separate layers. A VM that is defined in libvirt is a configuration file in /etc/libvirt/qemu/. A VM that is running is a QEMU process. The two are connected by the libvirt daemon.
Complete Example Session
# ============================================
# PART 1: THE KERNEL MODULES
# ============================================
# kvm.ko provides the core virtualization infrastructure.
# kvm-intel.ko or kvm-amd.ko provides the CPU-specific support.
# The modules are loaded automatically when KVM is used.# ============================================
# PART 2: /dev/kvm
# ============================================
# The character device that exposes KVM to userspace.
# QEMU opens it and uses ioctl() to create VMs and vCPUs.
# Permissions on /dev/kvm determine who can use KVM.# ============================================
# PART 3: THE QEMU PROCESS
# ============================================
# A KVM VM is a QEMU process on the host.
# It is visible in ps and top.
# It is scheduled by the Linux scheduler.
# Killing the process terminates the VM.# ============================================
# PART 4: THE FAST PATH
# ============================================
# Guest code executes directly on the physical CPU.
# KVM uses Intel VT-x or AMD-V to enter guest mode.
# No binary translation, no paravirtualization.# ============================================
# PART 5: THE SLOW PATH
# ============================================
# Device I/O is emulated by QEMU in userspace.
# The guest exits to QEMU on I/O access.
# QEMU emulates the device and resumes the guest.# ============================================
# PART 6: THE VMCS
# ============================================
# On Intel, the VMCS stores host and guest CPU context.
# KVM configures it before each KVM_RUN.
# The exit reason is read after the guest exits.# ============================================
# PART 7: LIBVIRT
# ============================================
# The management layer above QEMU.
# virsh and virt-manager are libvirt clients.
# The libvirt daemon talks to QEMU.# ============================================
# PART 8: THE HARDWARE REQUIREMENT
# ============================================
# Intel VT-x or AMD-V is required.
# kvm-ok checks whether the CPU supports it.
# Without the extensions, KVM cannot run.# ============================================
# PART 9: THE GUEST OS
# ============================================
# KVM supports unmodified guest operating systems.
# Linux, Windows, BSD, and others run as guests.
# The guest does not need to know it is virtualized.# ============================================
# PART 10: THE COMPLETE PICTURE
# ============================================
# Hardware: VT-x or AMD-V
# Kernel: kvm.ko + kvm-intel.ko
# Userspace: QEMU
# Management: libvirt
# Guest: the VMThe ten parts covered the kernel modules, /dev/kvm, the QEMU process, the fast path, the slow path, the VMCS, libvirt, the hardware requirement, the guest OS, and the complete picture.
Quick Reference
KVM components
| Component | Role |
|---|---|
kvm.ko | Core virtualization infrastructure |
kvm-intel.ko / kvm-amd.ko | CPU-specific support |
/dev/kvm | Userspace interface |
| QEMU | Device emulation, userspace control |
| libvirt | Management layer |
virsh / virt-manager | libvirt clients |
Hardware requirements
| Requirement | Detail |
|---|---|
| Intel | VT-x |
| AMD | AMD-V |
| Check command | kvm-ok |
| Device | /dev/kvm must exist |
Fast path vs slow path
| Path | Handled by | Behavior |
|---|---|---|
| CPU execution | KVM + hardware extensions | Guest code on physical CPU |
| Memory | KVM + hardware extensions | Guest physical memory mapped |
| Device I/O | QEMU | Emulated in userspace |
Key terms
| Term | Meaning |
|---|---|
| VMX | Intel virtualization mode |
| SVM | AMD virtualization mode |
| VMCS | Intel control structure |
| VMCB | AMD control block |
| vCPU | Virtual CPU, a thread in the QEMU process |
Best Practices
✅ Do This:
# Verify hardware support before installing
kvm-ok # ✅# Check that /dev/kvm exists and has correct permissions
ls -l /dev/kvm # ✅# Use libvirt for management
virsh list --all # ✅# Treat the QEMU process as the VM
ps aux | grep qemu # ✅❌ Don’t Do This:
# Assume KVM works without hardware extensions
# It cannot run without VT-x or AMD-V # ❌# Confuse KVM with QEMU
# KVM is the kernel module; QEMU is the userspace emulator # ❌# Manage VMs by killing QEMU processes directly
# Use libvirt or virsh instead # ❌Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
/dev/kvm not found | KVM modules not loaded or CPU unsupported | Check kvm-ok; load the module |
Permission denied on /dev/kvm | User not in the kvm group | Add the user to the group |
| Slow I/O performance | Device emulation in QEMU | Use VirtIO devices, not emulated hardware |
| VM cannot start | Insufficient memory or CPU resources | Check host resources; adjust VM allocation |
virsh cannot connect | libvirt daemon not running | Start libvirtd |
Real-World Examples
1. Check KVM support
kvm-ok2. Check the device
ls -l /dev/kvm3. List VMs
virsh list --all4. Start a VM
virsh start myvm5. Check the QEMU process
ps aux | grep qemu6. Load the module
modprobe kvm_intel7. Check the module
lsmod | grep kvm8. Create a VM with virt-install
virt-install --name test --vcpus 2 --ram 2048 --disk size=10 --cdrom /path/to/iso9. Connect to the console
virsh console myvm10. Shut down a VM
virsh shutdown myvmVisual
The KVM architecture
┌─────────────────────────────────────────────────────────────┐
│ GUEST VM │
│ └── Guest OS + applications │
│ │
│ ───────────────────────────────────────────────────────── │
│ │
│ USERSPACE │
│ └── QEMU process │
│ ├── Device emulation │
│ ├── vCPU threads │
│ └── /dev/kvm ioctl │
│ │
│ ───────────────────────────────────────────────────────── │
│ │
│ KERNEL │
│ └── kvm.ko + kvm-intel.ko │
│ ├── VMCS management │
│ ├── Memory mapping │
│ └── Guest mode entry/exit │
│ │
│ ───────────────────────────────────────────────────────── │
│ │
│ HARDWARE │
│ └── CPU with VT-x or AMD-V │
└─────────────────────────────────────────────────────────────┘The fast and slow paths
┌─────────────────────────────────────────────────────────────┐
│ FAST PATH (CPU + memory) │
│ Guest code ──► physical CPU ──► guest code │
│ KVM enters guest mode, guest runs natively │
│ │
│ SLOW PATH (device I/O) │
│ Guest I/O ──► VM exit ──► QEMU emulates ──► resume │
└─────────────────────────────────────────────────────────────┘The management stack
┌─────────────────────────────────────────────────────────────┐
│ virsh / virt-manager │
│ │ │
│ ▼ │
│ libvirt daemon │
│ │ │
│ ▼ │
│ QEMU process │
│ │ │
│ ▼ │
│ /dev/kvm │
│ │ │
│ ▼ │
│ KVM kernel module │
└─────────────────────────────────────────────────────────────┘The VM as a process
┌─────────────────────────────────────────────────────────────┐
│ Host Linux kernel │
│ └── Scheduler │
│ └── QEMU process (the VM) │
│ ├── vCPU thread 1 │
│ ├── vCPU thread 2 │
│ └── I/O thread │
│ │
│ The VM is a process. │
│ Killing it terminates the VM. │
└─────────────────────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| Type | Type-1 hypervisor, kernel module |
| Kernel integration | Since Linux 2.6.20 |
| Hardware requirement | Intel VT-x or AMD-V |
| Userspace interface | /dev/kvm |
| Device emulation | QEMU |
| Management | libvirt, virsh, virt-manager |
| VM model | QEMU process, one thread per vCPU |
| Performance | Near-native for CPU, emulated for I/O |
Key takeaways:
- KVM is a kernel module, not a separate hypervisor. It turns the Linux kernel into a Type-1 hypervisor. The kernel’s scheduler, memory manager, and drivers are reused for the virtual machines .
- The hardware extensions are mandatory. Intel VT-x or AMD-V provides the CPU mode that allows guest code to run directly on the physical CPU. Without them, KVM cannot run. The
kvm-okcommand verifies the support . - KVM and QEMU are separate components with separate responsibilities. KVM provides CPU and memory virtualization. QEMU provides device emulation and the userspace control plane. A KVM VM is a QEMU process that uses
/dev/kvmfor the fast path . - A VM is a Linux process. It is scheduled by the kernel, visible in
ps, and managed by systemd. Killing the QEMU process terminates the VM. This model is why KVM performance is so closely tied to the host kernel . - libvirt is the management layer. It abstracts the hypervisor details and provides a consistent API.
virshandvirt-managerare libvirt clients, not QEMU clients. The libvirt daemon translates their commands into QEMU operations . - The guest does not need to be modified. KVM supports unmodified Linux, Windows, and other operating systems. The guest believes it is running on physical hardware, and the hardware extensions handle the illusion .
Remember: KVM is the Linux kernel’s virtualization infrastructure. It is a kernel module that requires hardware virtualization extensions. It provides the fast path for CPU and memory. QEMU provides the slow path for device emulation and the userspace control plane. libvirt provides the management layer. A VM is a QEMU process, not a separate entity. The /dev/kvm device is the interface between the userspace and the kernel. Without the hardware extensions, KVM cannot run; without QEMU, it cannot emulate devices; without libvirt, it cannot be managed conveniently. Understanding which component is responsible for which operation is what makes KVM administration tractable.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!