Virtualization: Part 5 — QEMU

QEMU — a free emulator and virtualizer, distributed under the GPLv2 license. It does two different things. First, it can emulate an entire computer, including a CPU of another architecture: for example, run an ARM system on a regular x86 server. Second, it can work together with a virtualization accelerator — on Linux this is KVM — and then virtual machines run at nearly the same speed as the host.

The current stable release as of September 2026 is QEMU 11.1.1 (26 August 2026).

How QEMU and KVM split the work

KVM is a Linux kernel module that gives a virtual machine direct access to CPU features (Intel VT-x, AMD-V). By itself it does not create disks, network cards, or a display. QEMU takes care of that: it presents disk controllers, network adapters, USB, a video card and a bootloader to the guest system. Therefore on a KVM server the virtual machine processes are QEMU processes.

Without an accelerator QEMU translates each guest CPU instruction into host instructions. This works on any architecture but is several times slower — this mode is not suitable for production workloads; for testing and development it is usually sufficient.

Where QEMU is used, even if you don’t know about it

• Proxmox VE runs virtual machines via QEMU with KVM; the qm command and the Proxmox web interface ultimately form the QEMU launch parameters.
• libvirt, virt-manager and Cockpit on regular Linux servers also manage QEMU processes.
• UTM on macOS uses QEMU, including to run x86 systems on Apple computers with ARM processors.
• Docker builds images for other architectures (docker buildx --platform linux/arm64) using QEMU user-mode: individual programs of a foreign architecture run transparently, without launching a full virtual machine.

Two modes of operation

• System emulation (qemu-system-x86_64, qemu-system-aarch64, etc.) — a full virtual machine with its own kernel, disks and devices.
• User-mode (qemu-aarch64, qemu-arm, etc.) — running a single program compiled for another architecture in the current Linux system. This is exactly what is used for cross-building and tests.

Disks: the qemu-img utility

QEMU disk images are created and converted with the qemu-img utility. The main format is qcow2: it takes up on disk only as much space as is actually written and supports snapshots. The raw format is simpler and slightly faster, but immediately occupies the full size.

# create a 40 GB disk in qcow2 format
qemu-img create -f qcow2 disk.qcow2 40G

# view image details: format, virtual and actual size
qemu-img info disk.qcow2

# convert a VMware (vmdk) disk to qcow2 — a typical step when migrating from VMware
qemu-img convert -p -f vmdk -O qcow2 server.vmdk server.qcow2

The convert operation is the main tool when migrating virtual machines from VMware or Hyper-V (vhdx) to Proxmox and other KVM-based platforms.

Launching a VM manually

In practice machines are created through Proxmox or libvirt, but it’s useful to understand what happens under the hood. Minimal launch of a Linux installer with KVM acceleration:

qemu-system-x86_64 \
  -accel kvm -cpu host \
  -m 4G -smp 2 \
  -drive file=disk.qcow2,if=virtio \
  -cdrom debian.iso -boot d \
  -nic user,model=virtio-net-pci

• -accel kvm -cpu host — enable KVM and pass host CPU capabilities to the guest;
• -m and -smp — memory size and number of virtual CPUs;
• if=virtio and virtio-net-pci — paravirtualized devices: the guest knows it’s running in a VM and exchanges data faster than with emulation of real hardware;
• -nic user — a basic NAT-based network without bridge configuration; for servers a network bridge is configured instead.

If the CPU or server does not support hardware virtualization (for example, in some cloud VMs nested virtualization is disabled), QEMU with -accel kvm will not start. You can check like this: ls /dev/kvm — the file should exist.

Emulating another architecture

Running an ARM system on an x86 server looks like this:

qemu-system-aarch64 -M virt -cpu cortex-a72 -m 2G \
  -bios QEMU_EFI.fd \
  -drive file=arm-disk.qcow2,if=virtio \
  -nographic

There is no KVM acceleration here: the ARM CPU is fully emulated and the VM runs noticeably slower. For testing firmwares, images for single-board computers and building packages for ARM this is usually sufficient.

When to choose QEMU directly

• Development and testing for other architectures — ARM, RISC-V, MIPS, PowerPC.
• Kernel and bootloader debugging: QEMU can connect to the GDB debugger (-s -S).
• Automated image tests in CI, where a graphical interface is not needed.
• One-off running of an old system from a disk image.

For continuous server operation QEMU is not used directly: it is more convenient and reliable to manage machines via Proxmox VE or libvirt, which handle autostart, networking, snapshots and backups.

Common mistakes

• Running without -accel kvm on a server where KVM is available: the machine runs in emulation mode and is slow for no apparent reason.
• Emulated devices instead of virtio: an IDE disk and an e1000 network card are slower. For Windows, virtio drivers are installed separately from the virtio-win image.
• Copying a qcow2 file of a running VM: the copy may be inconsistent. Stop the VM or use snapshots and the platform’s backup tools.
• Mixing up the format: if you don’t specify format= in -drive, QEMU detects the format automatically and emits a warning; for raw images it’s better to specify the format explicitly.