Linux virtualization gets described as KVM, or QEMU, or libvirt, or sometimes all three at once, and newcomers reasonably conclude these are competing options. They are not. They are three layers of one stack, and knowing which layer does what makes every subsequent problem easier to diagnose.

KVM is a kernel module

KVM turns the Linux kernel into a hypervisor. It uses the hardware virtualization extensions in modern processors, Intel VT-x or AMD-V, to let guest CPU instructions execute directly on the physical processor rather than being interpreted.

That is the entire reason virtual machines are fast. Without hardware support, every guest instruction has to be examined and translated, which is roughly two orders of magnitude slower.

# Does the CPU support it?
grep -E --color 'vmx|svm' /proc/cpuinfo

# Is the module loaded?
lsmod | grep kvm

If /proc/cpuinfo shows nothing, check firmware settings before concluding the CPU cannot do it. Virtualization is disabled by default on a surprising number of consumer machines.

KVM handles the CPU and memory. It does not know what a disk is.

QEMU is everything else

QEMU emulates the rest of the machine: disk controllers, network cards, USB, graphics, firmware, timers.

QEMU can run entirely on its own, emulating the CPU too, which is how you run an ARM image on an x86 machine. That mode is slow, because every instruction is translated.

Used with KVM, QEMU hands CPU execution to the kernel module and concentrates on devices. That combination is what people mean by “KVM” in practice.

# QEMU with KVM acceleration, directly
qemu-system-x86_64 -enable-kvm -m 4096 -smp 4 \
  -drive file=disk.qcow2,if=virtio \
  -netdev user,id=n0 -device virtio-net,netdev=n0

That works and nobody manages virtual machines this way for long.

libvirt is management

libvirt is a daemon and API that sits above QEMU. It stores VM definitions as XML, manages virtual networks and storage pools, handles snapshots, and provides a stable interface that tools build on.

virsh and virt-manager are clients of libvirt, not of QEMU. So is Proxmox, and so are most cloud management layers.

sudo apt install qemu-kvm libvirt-daemon-system virtinst   # Debian and Ubuntu
sudo dnf install @virtualization                            # Fedora
sudo pacman -S qemu-full libvirt virt-install               # Arch

sudo systemctl enable --now libvirtd
sudo usermod -aG libvirt "$USER"    # then log out and back in

Our virt-manager and virsh guide covers driving it.

virtio is where the performance is

The single most consequential choice when creating a VM.

QEMU can emulate a real Intel network card or a SATA controller, which works with any guest operating system because the drivers already exist. It is also slow, because the guest is issuing hardware register writes that QEMU must interpret.

virtio devices are designed for virtualization. The guest knows it is a guest and talks to an efficient shared-memory interface instead. Disk throughput and network performance both improve substantially.

Use virtio for disk and network on any Linux guest. Windows guests need the virtio driver package installed, which is worth doing.

Where the layers show up in problems

Knowing the split tells you where to look:

• VM will not start, complains about KVM: kernel module or firmware setting
• Terrible disk or network performance: emulated devices instead of virtio
• Networking works oddly: libvirt’s virtual network configuration
• Guest sees the wrong CPU features: QEMU CPU model, set through libvirt

# What is actually running
ps aux | grep qemu-system | head -1

# What libvirt thinks
virsh dumpxml myvm | grep -E 'model|driver'

The ps output shows the real QEMU command line libvirt generated, which is the definitive answer when the XML and the behaviour disagree.

Frequently Asked Questions

What is the difference between KVM and QEMU?

KVM is a kernel module that lets guest CPU instructions run directly on the host processor using hardware virtualization extensions. QEMU is a userspace program that emulates everything else: disks, network cards, graphics, and firmware. They are used together, with KVM providing the speed and QEMU providing the devices.

Do I need libvirt?

Not strictly, since QEMU can be driven directly from the command line. In practice you want it, because libvirt manages VM definitions as XML, handles networking and storage pools, provides an API, and is what virt-manager and virsh talk to.

How do I know if my CPU supports virtualization?

Run grep -E "vmx|svm" /proc/cpuinfo, where vmx is Intel VT-x and svm is AMD-V. If nothing is returned, either the CPU lacks support or it is disabled in firmware, and the firmware setting is the more common cause.

Is KVM as fast as bare metal?

For CPU-bound work it is close, often within a few percent, because guest instructions execute natively. I/O is where the overhead lives, and using virtio drivers rather than emulated hardware recovers most of that.

What are virtio drivers?

Paravirtualized devices designed for virtual machines rather than emulations of real hardware. The guest knows it is virtualized and talks to a simple efficient interface instead of pretending to drive a physical network card. The performance difference is large.

Can I run KVM inside a virtual machine?

Yes, with nested virtualization enabled on the host. It is useful for testing and development and carries a performance cost, so it is not something to build production infrastructure on.