KVM and QEMU: the hypervisor pair

Why this matters in production

When a VM is misbehaving, the symptoms appear in three different places: the QEMU log, the host kernel log, and the guest’s own kernel. Knowing which subsystem owns which responsibility lets you triage in seconds instead of minutes.

Mental model

Think of QEMU as the machine and KVM as the engine. QEMU emulates the chipset, the BIOS or UEFI, the disk controllers, the network cards. KVM provides the privileged CPU execution mode that lets the guest’s instructions run directly on the host CPU when they do not trap.

flowchart TB
  subgraph QEMU[QEMU userspace process]
    Q1[Emulated chipset: i440fx or q35]
    Q2[Emulated or paravirt devices: disk, NIC, serial, ...]
    Q3[BIOS or UEFI firmware]
    Q4[Block layer: qcow2, raw, RBD, ...]
  end
  subgraph KVM[Linux kernel + KVM module]
    K1[VT-x / AMD-V hardware-virt mode]
    K2[IOMMU: VT-d / AMD-Vi]
    K3[vhost-net, vhost-scsi kernelspace drivers]
  end
  QEMU --> KVM
  KVM --> HW[Physical hardware]

In Proxmox, every VM is run by a QEMU process whose life is managed by the pve-qemu-kvm wrapper. You can see the process with ps.

KVM

KVM turns the Linux kernel itself into a hypervisor. It exposes a /dev/kvm device node and a set of ioctls. When a QEMU process opens /dev/kvm, it gains the ability to:

• Create virtual CPUs (vcpus) that the host kernel will schedule.
• Map guest physical memory into its own process address space.
• Run guest code with hardware-virtualisation assist when the guest executes a privileged instruction.

KVM does not emulate devices. That is QEMU’s job. KVM does not decide what the VM should look like; that is the configuration file’s job.

QEMU

QEMU is the emulator and machine model. It provides:

• The chipset (i440fx for older machine types, q35 for modern — Proxmox defaults to q35).
• The CPU model exposed to the guest.
• The disk, network, serial, USB, and other emulated/paravirtual devices.
• The BIOS or UEFI firmware.
• The block device backends that talk to the host storage layer.

In Proxmox the qm command and the API translate a VM’s <vmid>.conf into the QEMU command line that launches the process.

How Proxmox uses both

sequenceDiagram
  participant API as pvedaemon / API
  participant QM as qm command
  participant Q as QEMU process
  participant K as /dev/kvm
  participant V as Guest VM
  API->>QM: qm start 100
  QM->>Q: spawn qemu-system-x86_64 ...
  Q->>K: ioctl(KVM_CREATE_VM)
  K-->>Q: vm fd
  Q->>K: ioctl(KVM_CREATE_VCPU) × vcpus
  Q->>V: load firmware, jump to entry point
  V-->>K: trap on privileged instruction
  K-->>Q: return to userspace
  Q->>V: emulate or forward

The split lets Proxmox do things a pure-Kernel-mode hypervisor cannot:

• Snapshot a VM by snapshotting a file on the host.
• Live-migrate by copying the VM’s memory pages over the network to a peer QEMU process.
• Back up a VM by reading its block device from userspace (vzdump does this).

Important files

GUI walkthrough

Nothing in the GUI directly exposes KVM vs QEMU — it is implicit. When you choose a machine type (pc or q35), the underlying qemu-system-x86_64 -machine ... argument changes. When you choose a CPU type (host, kvm64, x86-64-v3), the CPU model flag changes. When you choose a SCSI controller (VirtIO SCSI single is the modern default), the paravirt backend changes.

CLI walkthrough

ls -l /dev/kvm && kvm-ok || true

ps -ef | grep -E 'qemu-system|kvm' | grep -v grep

tail -n 200 /var/log/pve/qemu/100.log

qm showcmd 100 --pretty

Production considerations

Common mistakes

• Setting cpu: host and being unable to migrate later.
• Looking at the host dmesg for QEMU errors. Most QEMU errors are written to the per-VM log in /var/log/pve/qemu/.
• Assuming “VirtIO” is a single thing. VirtIO is a family (net, scsi, gpu, balloon, rng, …). Each is a separate paravirt device.

Key takeaways

• KVM is the kernel-side hypervisor (hardware-virt execution mode). QEMU is the userspace machine emulator.
• Proxmox’s qm and the API turn a config file into a QEMU command line.
• The per-VM QEMU log is the first place to look for VM-level errors.

Knowledge check