How KVM, QEMU, and libvirt Relate to Each Other

Updated

KVM is the kernel-level virtualization layer, QEMU is the userspace program that runs and emulates the virtual machine, and libvirt is the management layer that sits on top and controls QEMU/KVM guests through a stable API. You need KVM for hardware-accelerated virtualization, QEMU to provide the virtual hardware and execute the guest, and libvirt if you want a consistent management interface, tooling, and automation across one or many hosts. The KVM project's own site describes KVM as "a full virtualization solution for Linux on x86 hardware containing virtualization extensions (Intel VT or AMD-V)," and notes that the userspace component of KVM is included in mainline QEMU as of 1.3.

The three layers and what each one does

Layer Role Where it lives What it gives you
KVM Core virtualization infrastructure Linux kernel (kvm.ko plus kvm-intel.ko or kvm-amd.ko) Hardware-assisted execution of guest code; the kernel component has been in mainline Linux since 2.6.20
QEMU Userspace virtual machine monitor and device emulation Userspace process Virtual hardware (network card, disk, graphics adapter), guest execution, and the KVM userspace component since QEMU 1.3
libvirt Management API and daemon Userspace service and client libraries A stable interface for defining, starting, and managing guests, used by tools that talk to QEMU/KVM

The KVM site's description makes the split concrete: KVM consists of a loadable kernel module, kvm.ko, that provides the core virtualization infrastructure, plus a processor-specific module, kvm-intel.ko or kvm-amd.ko. QEMU supplies the rest of the machine — each virtual machine has private virtualized hardware such as a network card, disk, and graphics adapter. libvirt is not part of the KVM kernel module or QEMU itself; it is the layer that manages QEMU/KVM guests.

How the pieces fit together at runtime

  1. The kernel loads kvm.ko and the matching vendor module (kvm-intel.ko on Intel VT hardware, kvm-amd.ko on AMD-V hardware). Without hardware virtualization extensions, KVM does not apply.
  2. QEMU starts as a userspace process, creates the virtual hardware for the guest, and uses the KVM kernel interface to run guest code with hardware acceleration.
  3. libvirt, when used, defines the guest configuration and launches or controls the QEMU process, exposing operations through its API rather than requiring you to assemble QEMU command lines by hand.

A practical example: on a host with Intel VT enabled in firmware, you load the KVM modules, then start a guest. If you launch QEMU directly, you are responsible for the full command line and device configuration. If you go through libvirt, you describe the guest once (for example as a domain definition) and let libvirt manage the QEMU invocation and lifecycle. The guest itself can run unmodified Linux or Windows images, per the KVM site.

Why the distinction matters when you deploy

  • KVM alone is not a complete virtualization product. It is the kernel infrastructure. You still need a userspace component to run guests, and that component is QEMU.
  • QEMU without KVM acceleration can still emulate hardware, but the KVM site frames KVM as the full virtualization solution for Linux on x86 hardware with virtualization extensions — the acceleration path depends on those extensions.
  • libvirt is optional but useful for management. If you manage multiple guests or want a consistent interface, libvirt adds a management layer above QEMU/KVM. If you run a single guest and prefer direct control, QEMU plus KVM is sufficient.

Where to read more on linux-kvm.org

The site's navigation includes HOWTO, Documents, Downloads, and FAQ sections, plus a Management Tools entry and a Migration page. For the libvirt relationship specifically, the site lists a "Running libvirt with KVM" article among its pages and links a book titled "qemu-kvm & libvirt" under its About/Documents area. The site also points to syndicated blogs from KVM-related virtualization developers at http://planet.virt-tools.org/ and to KVM Forum pages (2020–2024) for conference material.

To verify your own setup, check that the KVM modules are loaded and that your CPU exposes Intel VT or AMD-V, then confirm which userspace stack you are running — QEMU directly or QEMU under libvirt — since that determines where you configure guests and where you troubleshoot.