QEMU is an open-source machine emulator and virtualizer that runs complete guest operating systems inside a host process. In Linux virtualization, QEMU provides the virtual hardware: CPUs, memory, disks, network cards, USB controllers and firmware. On its own it can emulate a foreign processor architecture in software, and combined with the KVM kernel module it runs guests of the same architecture at near-native speed.
Most virtual machines on Linux hosts, whether started by libvirt, OpenStack, Proxmox VE or a desktop tool such as GNOME Boxes, are QEMU processes underneath. Each running guest is a single QEMU process on the host, with one thread per virtual CPU plus helper threads for I/O.
How QEMU emulates and virtualizes
QEMU has two ways of executing guest code. With the Tiny Code Generator (TCG), it translates guest instructions into host instructions block by block, which lets an x86 host run ARM, RISC-V, PowerPC or s390x guests. With an accelerator such as KVM, guest instructions run directly on the physical CPU using hardware virtualization extensions, and QEMU handles only device emulation and exits that the CPU cannot complete itself.
| Mode | How guest code runs | Relative speed | Typical use |
|---|---|---|---|
| TCG system emulation | Dynamic binary translation | Many times slower than native | Foreign architectures, firmware development |
| KVM acceleration | Directly on the CPU with VT-x or AMD-V | Close to native for CPU work | Servers, desktops, cloud hosts |
| User-mode emulation | Translates one Linux binary | Slower than native | Running ARM binaries on x86, cross builds |
| Other accelerators | HVF on macOS, WHPX on Windows | Close to native | Desktop virtualization on other hosts |
User-mode emulation deserves separate mention. Programs such as qemu-aarch64 run a single foreign Linux binary and translate its system calls to the host kernel. Registered through binfmt_misc, this lets container builds produce ARM images on x86 machines transparently.
Virtual hardware and device models
QEMU offers machine types that define the chipset and board, such as q35 for a modern PCI Express x86 platform, pc for the older i440FX chipset and virt for ARM. The choice of machine type and device models has a large effect on performance and compatibility.
| Device class | Emulated option | Paravirtual option | Practical choice |
|---|---|---|---|
| Disk | IDE, AHCI SATA | virtio-blk, virtio-scsi | Virtio for Linux guests and modern Windows |
| Network | e1000, rtl8139 | virtio-net | Virtio, with vhost-net in the kernel |
| Graphics | VGA, cirrus | virtio-gpu, QXL | virtio-gpu or none for servers |
| Firmware | SeaBIOS legacy BIOS | OVMF UEFI | OVMF for Secure Boot and modern systems |
Emulated devices imitate real hardware so that unmodified guests work, but every register access causes an expensive VM exit. Virtio devices are designed for virtualization, using shared memory rings that batch requests, and they typically deliver several times the throughput of emulated equivalents. Direct PCI passthrough with VFIO hands a physical device such as a GPU or network card to the guest for native performance.
Disk images and essential options
QEMU’s native disk format is qcow2, which supports thin provisioning, snapshots, backing files and compression. Raw images are simpler and slightly faster, while qemu-img converts between qcow2, raw, VMDK, VHDX and other formats.
| Option | Purpose | Example value |
|---|---|---|
| -accel kvm | Use hardware acceleration | kvm |
| -cpu | CPU model exposed to the guest | host, or a named model for migration |
| -smp / -m | Virtual CPUs and memory | -smp 4 -m 8G |
| -drive / -blockdev | Attach a disk image | file=vm.qcow2,if=virtio |
| -netdev / -device | Network back end and card | user or tap with virtio-net-pci |
| -qmp | Machine control socket | unix:/run/vm.sock,server |
The QEMU Machine Protocol (QMP) is a JSON interface for controlling a running guest: hot-plugging devices, taking snapshots, starting live migration and querying status. Management layers such as libvirt use QMP rather than the interactive monitor.
QEMU compared with related virtualization components
QEMU is often confused with the components around it. The key distinction is that QEMU emulates the machine, KVM accelerates the CPU, and libvirt manages the lifecycle.
| Component | Role | Runs where |
|---|---|---|
| QEMU | Machine and device emulation | User space, one process per guest |
| KVM | Hardware-assisted CPU and memory virtualization | Linux kernel module |
| libvirt | Management API and XML definitions | Daemon controlling QEMU processes |
| Virtio | Paravirtual device standard | Shared between host and guest drivers |
| LXC | Operating system containers, no separate kernel | Host kernel namespaces |
| WSL 2 | Linux in a lightweight VM on Windows | Hyper-V, not QEMU |
Performance, security and common pitfalls
Running QEMU without acceleration is the most common cause of unexpectedly slow guests. Checking that /dev/kvm exists and that the user may access it avoids silently falling back to TCG.
- Use
-cpu hostfor maximum performance, but a named CPU model when guests must migrate between different hosts. - Set the disk
cache=nonewithaio=nativeorio_uringfor predictable I/O on production storage. - Isolate QEMU processes with SELinux sVirt or AppArmor, so a guest escape is contained on the host.
- Keep QEMU updated, because device emulation code is the main attack surface for guest-to-host escapes.
- Avoid memory overcommitment without ballooning or swap planning; the host OOM killer may stop a whole guest.
In everyday language
QEMU builds an imaginary computer inside a real one. It pretends to be a processor, a disk, a network card and a screen, so a whole operating system can start up and run as if it had its own machine.
On its own, QEMU can even imitate a different kind of processor, which is slow but useful. Paired with KVM, it lets the real processor do the heavy work, so the virtual computer runs almost as fast as the physical one.
Seen in the real world
An embedded software team develops firmware for an ARM single-board computer, but only three physical boards exist. The team’s continuous integration server, an x86 Linux machine, starts each test run with qemu-system-aarch64 -machine virt -cpu cortex-a72 -m 2G and a qcow2 image built from the same root file system, so that every commit is tested without hardware.
The team also runs its x86 build environment under QEMU with KVM, where -cpu host and virtio disks give near-native compile times. Emulated ARM runs are slower, with boot taking minutes rather than seconds, but they run in parallel and catch most regressions before code reaches the scarce boards. The physical boards are then reserved for final hardware validation.