KVM (Kernel-based Virtual Machine) is the hypervisor built into the Linux kernel that uses hardware virtualization extensions, Intel VT-x or AMD-V, to run full virtual machines with their own operating systems. Each virtual machine runs as an ordinary Linux process, and each virtual CPU as a thread, so the host kernel schedules, isolates and accounts for guests with its standard mechanisms.
In Linux virtualization, KVM supplies only CPU and memory virtualization; a user-space program such as QEMU emulates the devices, and libvirt manages the machines. KVM was merged into Linux 2.6.20 in 2007 and now underpins most open-source virtualization stacks, OpenStack deployments and several large public clouds.
How KVM turns Linux into a hypervisor
KVM consists of a generic module, kvm.ko, and a processor-specific module, kvm_intel or kvm_amd. Together they expose the /dev/kvm device, through which a user-space virtual machine monitor creates a VM, assigns guest memory and starts virtual CPUs with a set of ioctl calls.
When a vCPU thread enters guest mode, the processor executes guest code directly on the hardware. Only sensitive events, such as access to an emulated device or certain privileged instructions, cause a VM exit back to the host. KVM handles many exits inside the kernel and forwards the rest, mostly device I/O, to the user-space monitor.
Guest memory is ordinary memory of the monitor process, translated in hardware by second-level address translation (Intel EPT or AMD NPT). Because KVM reuses the host kernel for scheduling, memory management and drivers, it is usually classified as a type 1 hypervisor, even though the host remains a full Linux system.
Hardware requirements and supporting features
KVM requires hardware virtualization support on the CPU, enabled in the firmware. The table below lists the features that matter in practice and how to verify them on a host.
| Feature | Intel name | AMD name | Why it matters |
|---|---|---|---|
| CPU virtualization | VT-x (vmx flag) | AMD-V (svm flag) | Mandatory, KVM cannot load without it |
| Second-level paging | EPT | NPT (RVI) | Removes most memory-management exits |
| IOMMU | VT-d | AMD-Vi | Needed for safe device passthrough |
| Interrupt virtualization | APICv, posted interrupts | AVIC | Fewer exits for interrupts |
| Nested virtualization | VMCS shadowing | Nested SVM | Running hypervisors inside guests |
A quick check is grep -cE 'vmx|svm' /proc/cpuinfo, which returns the number of logical CPUs reporting the flag; a result of 0 means the feature is missing or disabled in firmware. KVM also runs on ARM64, IBM Z, POWER and RISC-V, each using its own architecture extensions.
KVM, QEMU and libvirt in one stack
A typical Linux virtualization stack has three layers with distinct jobs, and confusing them is the most common misunderstanding about KVM. The kernel module accelerates execution, the monitor builds the virtual hardware, and the management layer stores definitions and policies.
| Layer | Component | Responsibility |
|---|---|---|
| Kernel | KVM | vCPU execution, memory virtualization, in-kernel interrupt controllers |
| User-space monitor | QEMU, Firecracker, Cloud Hypervisor | Emulated and virtio devices, firmware, migration |
| Management | libvirt | VM definitions, storage pools, networks, access control |
| Interfaces | virsh, virt-manager, OpenStack | Administration and orchestration |
For I/O performance, guests use virtio paravirtual devices instead of emulated hardware. A virtio network or disk driver in the guest exchanges data with the host through shared memory rings, and accelerators such as vhost-net move the data path into the host kernel.
KVM compared with other virtualization approaches
KVM differs from other hypervisors mainly in reusing a general-purpose kernel rather than shipping a separate one, and it differs from containers by running a separate guest kernel.
| Technology | Architecture | Guest kernel | Typical use |
|---|---|---|---|
| KVM | Hypervisor inside the Linux kernel | Any supported OS | Servers, clouds, desktops |
| Xen | Separate hypervisor with a control domain | Any supported OS | Legacy clouds, embedded |
| Hyper-V | Microsoft hypervisor | Any supported OS | Windows hosts, WSL 2 |
| VirtualBox | Hosted, type 2 hypervisor | Any supported OS | Desktop testing |
| LXC | Operating-system containers | Shares the host kernel | Lightweight Linux isolation |
Tuning KVM for performance
With hardware support, CPU-bound guest workloads typically run within a few percent of native speed. Larger gaps usually come from I/O configuration, memory layout or overcommitment, which the following techniques address.
| Technique | Effect | Trade-off |
|---|---|---|
| virtio drivers | Fast disk and network I/O | Guest needs the drivers |
| CPU pinning | Stable latency, better cache use | Less scheduling flexibility |
| Huge pages | Fewer TLB misses | Memory reserved up front |
| NUMA alignment | Local memory access | Requires topology planning |
| host-passthrough CPU model | Exposes all host CPU features | Limits live migration targets |
| VFIO passthrough | Native device performance | Device cannot be shared or migrated easily |
Limitations and common mistakes
- Virtualization disabled in firmware is the most frequent reason KVM modules fail to load.
- Running a guest without KVM acceleration falls back to QEMU software emulation, which is many times slower.
- Overcommitting memory without monitoring can trigger host swapping or the out-of-memory killer, which hits whole guests.
- Mixing CPU models across hosts breaks live migration when the destination lacks a feature the guest uses.
- Treating KVM as a complete product overlooks that QEMU and libvirt need their own security updates.
In everyday language
KVM lets one physical computer behave like several separate computers. Each of these virtual machines can run its own operating system, such as another Linux or Windows, without knowing it shares the hardware.
Think of a large office building with one power supply and one foundation. KVM divides it into locked apartments, and each tenant gets private rooms while the building manager, the Linux kernel, keeps the shared utilities running fairly. Modern processors include special support for this, so the apartments work almost as fast as a standalone house.
Seen in the real world
A mid-sized company replaces eight aging physical servers with two new hosts, each with 64 CPU cores and 512 GiB of memory, running Linux with KVM, QEMU and libvirt. The old servers become virtual machines with virtio disks and networking, each sized to its actual workload.
The database guest receives 16 dedicated cores pinned to one NUMA node and 128 GiB backed by huge pages, which keeps its latency stable. The remaining guests share the other cores. Because both hosts use the same CPU model in their VM definitions, administrators live-migrate guests between hosts before firmware updates, so maintenance no longer requires downtime, and the company now powers 2 servers instead of 8.