Cloud Parts

QEMU

The open-source machine emulator and virtualizer: it emulates whole computers in software, or runs them at native speed on a hypervisor such as KVM, and supplies the virtual devices either way.

What it is
Hypervisors
Type
Open source
Made by
QEMU project (started by Fabrice Bellard)
License
GPL 2.0
Facts checked
11 October 2026

What it is

QEMU is an emulator and a virtualizer in one program. As an emulator it uses TCG, the Tiny Code Generator, a just-in-time compiler that translates blocks of guest instructions into host instructions and caches them, so an x86 guest can boot on an Arm machine or the other way round. As a virtualizer it hands the CPU work to a hypervisor, which QEMU calls an accelerator: KVM on Linux, Hypervisor.framework (hvf) on macOS, the Windows Hypervisor Platform (whpx), Xen, MSHV or NetBSD’s NVMM. Guest code then runs directly on the processor and QEMU only emulates the hardware around it. That device side is what most VM platforms use QEMU for. A machine type picks the board: q35 is a PC with Intel’s Q35 and ICH9 chipset from 2009, virt is an Arm board that matches no real hardware and is meant for VMs, and microvm is a minimal x86 machine with no PCI or ACPI, inspired by Firecracker.

On that board QEMU can emulate real devices, such as an e1000 network card, or attach paravirtual virtio devices designed for VMs, and it can pass a host device straight through to the guest. Its block layer reads and writes many image formats; its native one, qcow2, grows as data is written and supports zlib compression, internal snapshots and backing files, so a thin overlay can share one base image. The qemu-img tool creates, converts and inspects images, including raw, VMDK, VDI and VHDX. Programs control a running QEMU through QMP, the QEMU Machine Protocol, a JSON protocol on a socket; libvirt, for one, drives QEMU this way.

QEMU also has a user-mode emulator that runs a single Linux program built for another CPU, translating its system calls to the host’s. Registered with the kernel’s binfmt_misc, it lets an x86 host run Arm binaries transparently, which is how Docker’s BuildKit builds multi-platform images. Fabrice Bellard started QEMU in 2003; it is now developed by a large community, has made three feature releases a year recently (April, August and December), and the latest is 11.1.2 (September 29, 2026). QEMU as a whole is GPL 2.0, while most of TCG is under BSD or MIT licenses.

Why teams pick it

  • Runs almost anything on almost anything: TCG emulates Arm, x86, RISC-V, PowerPC, s390x, MIPS and more on several host architectures, and accelerators bring same-architecture guests to near-native speed
  • The standard device model behind Linux virtualization: libvirt, Proxmox VE, OpenStack and KubeVirt all start VMs as QEMU processes
  • Complete tooling: qemu-img and qcow2 overlays, live migration, snapshots, device passthrough and a scriptable JSON control protocol (QMP)
  • User-mode emulation makes cross-architecture container builds and test runs possible without a full VM

Watch out for

  • Large and complex: decades of emulated hardware are attack surface, which is why Google wrote its own VMM for Compute Engine and smaller VMMs like Firecracker exist
  • TCG emulation is much slower than hardware virtualization; Docker warns that emulated multi-platform builds can be much slower than native ones
  • The command line is long and low-level (a one-disk test VM started by libvirt got 16 -device, -blockdev and -object options), so most people use QEMU through libvirt, Proxmox VE or another manager
  • User-mode emulation can’t emulate clone flags that create namespaces, so container runtimes can’t run under it, though emulated programs can run inside containers

Alternatives

What all hypervisors have in common →
Cloud HypervisorOpen sourceA Rust virtual machine monitor for modern cloud VMs on KVM or Microsoft’s hypervisor: virtio devices only, plus hotplug, VFIO passthrough, live migration, snapshots and Windows guests.KVM (Kernel-based Virtual Machine)Open sourceThe hypervisor built into the Linux kernel: it runs guest code directly on the CPU through `/dev/kvm`, and leaves device emulation to a user-space program such as QEMU or Firecracker.libvirtOpen sourceA stable API, daemon and `virsh` command line for managing virtual machines, storage and networks, with drivers for QEMU/KVM, Xen, LXC, Cloud Hypervisor, VMware ESX, Hyper-V and more.Microsoft Hyper-VCommercialMicrosoft’s type-1 hypervisor, built into Windows Server and Windows 10 and 11 Pro and Enterprise: a thin hypervisor under a Windows root partition, which also underpins Azure’s hypervisor and Windows features like VBS, WSL 2 and Windows Sandbox.Oracle VirtualBoxOpen sourceOracle’s free, open-source desktop hypervisor: a type-2 hypervisor that runs VMs as an application on Windows, macOS, Linux and Solaris, scriptable with `VBoxManage` and the default provider for Vagrant.Proxmox Virtual EnvironmentOpen sourceA Debian-based server platform from Vienna that runs KVM virtual machines and LXC containers, with clustering, high availability, Ceph and ZFS storage, backups and a web interface in one free ISO.VMware ESXiCommercialVMware’s bare-metal hypervisor (called ESX again since VCF 9), whose own kernel runs VMs directly on servers while vCenter adds vMotion, HA, DRS and vSAN; since Broadcom bought VMware in 2023 it is sold only as per-core subscriptions.Xen Project hypervisorOpen sourceThe open-source type-1 hypervisor from Cambridge that ran the first Amazon EC2 instances: a small microkernel-style core that boots first, with drivers and management in a privileged VM called dom0.

How it fits with other technologies

Create a qcow2 overlay and boot an x86 CirrOS guest under TCG (QEMU 10.0.13 in a Debian 13 container on an arm64 Mac, so no KVM) · bash

qemu-system-x86_64 -accel help
# Accelerators supported in QEMU binary:
# tcg
qemu-system-x86_64 -machine help | grep -E '^(q35|microvm) '
# microvm              microvm (i386)
# q35                  Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-10.0)

wget -q https://download.cirros-cloud.net/0.6.2/cirros-0.6.2-x86_64-disk.img
qemu-img create -f qcow2 -b cirros-0.6.2-x86_64-disk.img -F qcow2 vm1.qcow2 1G
qemu-img info vm1.qcow2
# file format: qcow2
# virtual size: 1 GiB (1073741824 bytes)
# disk size: 196 KiB                    # only the overlay; reads fall through to the base
# backing file: cirros-0.6.2-x86_64-disk.img

qemu-system-x86_64 -accel tcg -machine q35 -m 256 -smp 1 -nographic \
  -drive file=vm1.qcow2,if=virtio -nic user,model=virtio-net-pci
# [    0.000000] Linux version 5.15.0-71-generic ...
# [    4.113434] virtio_blk virtio1: [vda] 2097152 512-byte logical blocks (1.07 GB/1.00 GiB)
# === cirros: current=0.6.2 uptime=87.07 ===
# cirros login:
# (afterwards `qemu-img info vm1.qcow2` shows disk size: 28.4 MiB, the blocks the guest wrote)

Accelerators: who runs the guest’s CPU#

From QEMU’s documentation. Without one of the hypervisors, QEMU falls back to TCG and translates every instruction itself.

AcceleratorHost OSHost architectures
KVMLinuxArm, MIPS, PPC, RISC-V, s390x, x86
XenLinux (as dom0)Arm, x86
MSHVLinux (as dom0)x86
Hypervisor.framework (`hvf`)macOSx86, Arm
Windows Hypervisor Platform (`whpx`)WindowsArm, x86
NetBSD Virtual Machine Monitor (`nvmm`)NetBSDx86
Tiny Code Generator (`tcg`)Linux, other POSIX, Windows, macOSArm, x86, LoongArch64, MIPS, PPC, s390x, Sparc64

Driving QEMU over QMP#

Started paused (-S) with a QMP socket, then controlled with JSON commands, the way management tools do it. Run with QEMU 10.0.13 under TCG; socat is the client.

bash
qemu-system-x86_64 -accel tcg -machine q35 -m 256 -display none -S \
  -qmp unix:/tmp/qmp.sock,server=on,wait=off -drive file=vm2.qcow2,if=virtio &

printf '%s\n' '{"execute":"qmp_capabilities"}' '{"execute":"query-status"}' \
  '{"execute":"cont"}' '{"execute":"query-status"}' '{"execute":"quit"}' |
  socat -t2 - unix-connect:/tmp/qmp.sock
# {"QMP": {"version": {"qemu": {"micro": 13, "minor": 0, "major": 10}, ...}, "capabilities": ["oob"]}}
# {"return": {}}
# {"return": {"status": "prelaunch", "running": false}}
# {"timestamp": {...}, "event": "RESUME"}
# {"return": {}}
# {"return": {"status": "running", "running": true}}
# {"timestamp": {...}, "event": "SHUTDOWN", "data": {"guest": false, "reason": "host-qmp-quit"}}
# {"return": {}}

See it in a real stack

No architecture uses QEMU yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2003–2026

Fabrice Bellard began QEMU in early 2003 as an x86 CPU emulator that could run Linux programs on other processors. The first commit is dated February 18, 2003, and version 0.1, the “initial public release”, followed in March. By June, version 0.4 could boot an almost unmodified Linux kernel with no host kernel patches and no special privileges. Bellard’s 2005 USENIX paper explained the trick: a portable dynamic translator that stitched together pieces of machine code that GCC had compiled ahead of time, so supporting a new host took far less work than writing a compiler back end.

When KVM arrived in Linux in 2007, it left all device emulation to a user-space program, and QEMU filled that role. QEMU 0.10 in March 2009 brought KVM acceleration upstream, together with TCG, a real code generator that ended the dependence on old GCC versions, plus virtio devices and live migration. From then on QEMU was both an emulator and the device model under most Linux virtualization, with libvirt, OpenStack and later Proxmox VE and KubeVirt driving it.

QEMU 1.0 came out in December 2011. Since 2025 the project has shipped feature releases in April, August and December, plus stable point releases in between.

Why it’s built this way

Dynamic translation instead of an interpreter
Guest instructions are translated once into host code and cached, so each one is fetched and decoded only once. That made full-system emulation fast enough to boot real operating systems.
Portability over peak speed
The first translator glued together code fragments that GCC had already compiled, so a new host needed little new code. TCG, its 2009 replacement, kept the same goal of running many guests on many hosts.
Hand the CPU to a hypervisor when one is available
With accelerators like KVM, QEMU stops emulating the CPU and keeps only the device model, so one program serves both cross-architecture emulation and fast same-architecture virtualization.
User-mode emulation next to system emulation
Running a single foreign Linux binary needs only CPU emulation and system call translation, which Bellard used to test cross compilers; the same feature now powers cross-architecture container builds.

Timeline

  1. 2003

    First commit (February 18); 0.1 in March; 0.4 boots a Linux kernel in June

  2. 2005

    Bellard’s USENIX paper on QEMU’s portable dynamic translator

  3. 2009

    QEMU 0.10 (March): TCG, KVM acceleration, virtio and live migration

  4. 2011

    QEMU 1.0 (December)

  5. 2025

    QEMU 10.0 (April); feature releases follow in August and December

  6. 2026

    QEMU 11.0 (April) and 11.1 (August)

Sources17 · facts checked 11 October 2026

Improve this page on GitHub