Kernel-based Virtual Machine (KVM) is a Linux kernel feature that turns the kernel itself into a Type-1 hypervisor. The team that uses KVM runs Linux virtual machines with near-native performance, supports live migration between hosts, and inherits hardware-accelerated virtualization from Intel VT-x or AMD-V. The team that uses KVM in production is running the same technology that powers AWS, GCP, OpenStack, and most public cloud platforms - KVM is not a niche choice, it is the default Linux virtualization layer.
Table of contents
- What KVM actually is
- Hardware requirements: VT-x and AMD-V
- KVM vs other hypervisors
- KVM in production: what it powers
- When to choose KVM (and when not to)
- FAQ
What KVM actually is
KVM is two kernel modules: kvm.ko (the core virtualization infrastructure) and either kvm-intel.ko or kvm-amd.ko (the CPU-specific accelerator). When loaded, the Linux kernel gains the ability to act as a hypervisor. The team that runs lsmod | grep kvm on a modern Linux server sees these modules loaded by default - they are not optional.
Before KVM, Linux userspace virtualization was QEMU emulating the CPU. QEMU is software emulation - it runs the guest CPU instructions in software, which is slow. KVM adds hardware-accelerated virtualization: the guest CPU runs directly on the host CPU through VT-x or AMD-V instructions, and QEMU handles the I/O emulation (disk, network, USB). The team that runs KVM+QEMU has hardware-accelerated VMs with QEMU-managed I/O - this is what ‘QEMU/KVM’ or just ‘KVM’ refers to in practice.
KVM is Type-1 virtualization, not Type-2. A Type-2 hypervisor runs as an application on top of a host OS (VirtualBox, VMware Workstation). A Type-1 hypervisor runs directly on the hardware with the OS as a peer (ESXi, Hyper-V). KVM is unusual: the kernel IS the hypervisor, so the boundary between Type-1 and Type-2 blurs. The team that runs KVM gets Type-1 performance with a familiar Linux environment for management.
Hardware requirements: VT-x and AMD-V
KVM requires hardware virtualization extensions. Intel CPUs need VT-x (vmx flag in /proc/cpuinfo); AMD CPUs need AMD-V (svm flag). Without these extensions, KVM cannot run VMs in hardware-accelerated mode - it falls back to QEMU’s software emulation, which is too slow for production use.
Most modern server and desktop CPUs have these extensions. Intel has shipped VT-x since 2005 (Pentium 4 / Xeon), AMD has shipped AMD-V since 2006 (Athlon 64 / Opteron). The team that runs a server built in the last 15 years has hardware virtualization support. The team that runs older hardware without VT-x/AMD-V cannot use KVM and must run a different hypervisor (Xen, Hyper-V, or VMware ESXi).
Verify support before deploying KVM. Run grep -E '(vmx|svm)' /proc/cpuinfo on the host. If the command returns output, the CPU supports hardware virtualization. If it returns nothing, the host cannot run KVM with hardware acceleration. The team that checks this before provisioning avoids the ‘KVM won’t boot the VM’ debug session that comes from missing CPU flags.
KVM vs other hypervisors
KVM vs Xen: KVM is integrated into the Linux kernel; Xen is a separate hypervisor with a privileged domain. Xen has stronger isolation (the hypervisor runs in ring -1, separate from the kernel) but adds operational complexity (Xen-specific tools, separate kernel patches). KVM wins on operational simplicity - the team that knows Linux already knows how to run KVM. AWS used Xen until 2017, then migrated to KVM for this reason.
KVM vs VMware ESXi: ESXi is a commercial Type-1 hypervisor with deep enterprise features (vMotion, vSAN, NSX). ESXi requires VMware licensing, which gets expensive at scale. KVM is free and open source, with comparable features in the OpenStack ecosystem (live migration via virsh migrate, storage replication via Ceph). The team that runs a small deployment uses ESXi for its polish; the team that runs thousands of hosts uses KVM because the licensing math stops working.
KVM vs VirtualBox: VirtualBox is a Type-2 hypervisor for desktop use. VirtualBox runs as an application on a host OS, which makes it easy to install on a laptop but slow in production. KVM runs as part of the kernel, which makes it faster but harder to install on a desktop without root. The team that develops on a laptop uses VirtualBox; the team that deploys to a server uses KVM.
KVM in production: what it powers
AWS EC2 runs on a heavily modified KVM (originally Xen, migrated in 2017). The team that runs EC2 is running KVM under the hood, with Nitro hardware offloading for networking and storage. GCP runs on KVM with custom hypervisor extensions. Azure runs on Hyper-V for legacy reasons but is migrating workloads to KVM-based hosts. DigitalOcean, Linode, Vultr, and most VPS providers run KVM.
OpenStack uses KVM as the default compute driver. When the team deploys OpenStack, the VMs run on KVM hosts managed by libvirt. Proxmox VE bundles KVM with a web UI for management. oVirt is the upstream project for Red Hat Virtualization, which is KVM-based.
The team that uses a managed cloud platform inherits KVM without choosing it. The team that runs OpenStack, Proxmox, or bare KVM with libvirt chooses KVM directly. Either way, the hypervisor is KVM - it is the default Linux virtualization layer in 2026.
When to choose KVM (and when not to)
Choose KVM when the team already runs Linux, needs hardware-accelerated virtualization, and wants open source. KVM is the default Linux choice. It runs on any modern CPU, integrates with the rest of the Linux stack (cgroups, namespaces, SELinux, iptables), and has no licensing cost.
Choose something else when the team needs Windows-only guest support with maximum compatibility. Hyper-V has the best Windows guest integration (Microsoft writes both sides). VMware ESXi has the deepest enterprise feature set (vMotion, vSAN, NSX) but at licensing cost. The team that runs Windows-heavy workloads may prefer these for compatibility reasons.
Choose containers instead when the workload does not need a full VM. Docker, Podman, and Kubernetes run Linux processes in isolated namespaces without the overhead of a separate kernel. Containers start in milliseconds; VMs start in seconds. The team that ships a Linux service without Windows-specific dependencies should run containers, not VMs. The team that runs Windows, runs legacy x86 software, or needs hardware isolation should run KVM.
FAQ
Is KVM free?
Yes, KVM is GPL-licensed open source software. There is no licensing cost for KVM itself. The team that uses libvirt, QEMU, and OpenStack around KVM is also using free software; the cost comes from support contracts (Red Hat, Canonical) if the team wants them.
Does KVM run on ARM?
Yes. KVM has supported ARM since Linux 3.9 (2013) and supports both 32-bit ARM and 64-bit ARM (AArch64). AWS Graviton instances, Apple Silicon Macs (via Asahi Linux), and most modern ARM servers run KVM. The performance is comparable to x86 KVM with hardware virtualization extensions.
Can KVM run Windows?
Yes, KVM runs Windows guests well. virtio drivers (paravirtualized disk and network) give near-native I/O performance. The team that runs Windows Server on KVM gets the same performance as Hyper-V for most workloads, with the operational advantage of Linux-based management tools.
What is the difference between KVM and QEMU?
QEMU is a CPU emulator that can run VMs without hardware acceleration (slow). KVM is the Linux kernel feature that adds hardware acceleration. The team that runs ‘KVM’ in production runs QEMU/KVM: QEMU handles I/O emulation and management, KVM handles CPU and memory virtualization.
What is libvirt?
libvirt is a management API for KVM (and other hypervisors - Xen, VMware, Hyper-V). The team that uses libvirt gets a uniform interface (virsh, virt-manager, OpenStack) across hypervisors. libvirt is not required for KVM - the team can use QEMU directly - but most production deployments use libvirt for orchestration.
How do I check if my CPU supports KVM?
Run grep -E '(vmx|svm)' /proc/cpuinfo. If the command returns output (vmx for Intel VT-x, svm for AMD-V), the CPU supports hardware virtualization. If it returns nothing, the CPU does not support KVM with hardware acceleration.
How this fits the rest of the stack
For a sense of what the full project costs before it commits, the RunxBuild hosting calculator shows the line items together. The API, the database, the storage, the worker, the bandwidth - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers.
Useful related references: