qemu: Virtualization
`qemu-system-x86_64 -m 2048 -hda disk.img` — that command has been running the same way since 2003, and it is still the shortest path to a working virtual machine. QEMU, short for Quick Emulator, is the open-source software that makes almost all virtualization in the Linux world possible.
The core of QEMU is twofold. As an emulator, it mimics complete systems — CPU, memory, disks, network — for architectures you do not physically have. Running an ARM system on an x86_64 machine is possible with it, as is a MIPS router or a SPARC server. That costs computing power, because every instruction is translated, but it works. For embedded developers, that is worth its weight in gold: testing firmware without the hardware existing.
In addition, QEMU supports user-mode emulation. It does not emulate a full system then, but only a single process from another architecture. That is how Docker and Podman build ARM container images on x86 machines: via binfmt_misc and buildx, QEMU inserts itself between the host and the process being built.
But the real strength lies in the combination with KVM, the Kernel-based Virtual Machine. KVM uses the virtualization extensions of the CPU — Intel VT-x or AMD-V — to run a guest at nearly native speed. QEMU then provides the user-space component: the virtual network cards, disk controllers, and graphical interfaces that KVM does not handle itself.
That QEMU + KVM combination lies under the hood of Proxmox VE, OpenStack, and a large part of cloud infrastructure. Hundreds of virtual machines on one physical server, each isolated from the other, is thus daily practice.
The price of that flexibility is complexity. You configure QEMU via the command line, with dozens of parameters for memory, disks, network, and devices. Calling `qemu-system-x86_64` with the right flags requires knowledge of what you are running and why. Those who do not want that use a front-end: virt-manager, virsh, or Snowglobe, a virtual-machine viewer that talks to running QEMU instances via DBus.
Fabrice Bellard wrote the first version, and the preview release appeared in 2003. The project has been continuously active ever since. In August 2026, version 11.1.1 was on the official site; the release cycle is regular enough that companies can plan their updates around it.
The source code is written in C and freely available under an open-source license. That means not only that you can see what the software does, but also that you can adapt it to your own infrastructure. The community is active, with contributions from individual developers and companies that incorporate QEMU into their products.
QEMU speaks with a wide range of architectures: x86, x86_64, ARM, ARM64, MIPS, PowerPC, RISC-V, and SPARC. That breadth makes it indispensable in embedded development, where the target processor is often not on the development workstation.
Self-hosting sounds wonderful, until something crashes on Sunday evening at half past eleven. Then you are not a customer waiting on the helpdesk. Then you are the helpdesk — and QEMU is the tool with which you solve the problem or not.
For those running containers, QEMU sometimes seems unnecessary. Containers share the host kernel and do not need full virtualization. But as soon as you want to build multi-arch images, or run a guest with a different kernel than the host, you end up back at QEMU.
The boundary between emulation and virtualization is thinner in practice than theory suggests. QEMU does both, and the choice is made by which flag you pass to the same command.
Those starting with QEMU would do well to start small: a single VM, a simple disk image, no network. The error messages are cryptic, and the documentation assumes you know what a virtio driver is. You know that after a week, not after an hour.
Front-ends hide part of that complexity, but not everything. Ultimately, you must understand what a VM needs: memory, storage, a way to reach the outside world. QEMU forces you to answer those questions, even if you put a graphical shell around it.
The development history of QEMU is a series of compromises between speed and accuracy. Emulation is slow, virtualization with KVM is fast, and the art is knowing when you need which. An old operating system that does not know virtio drivers runs better in pure emulation; a modern Linux guest runs best with KVM and virtio.
The release history shows a steady development: 0.12.2 in January 2010, 1.2.0 in September 2012, 2.0.0-rc0 in March 2014, 7.2.0 in December 2022, 9.0.0-rc0 in October 2024, 10.0.0-rc0 in March 2025. No big leaps, but a constant stream of improvements.
What distinguishes QEMU from proprietary alternatives is not only the price, but the control. You can see what happens, you can adjust it, and you are not dependent on a vendor's roadmap. For many organizations, that weighs more heavily than the initial learning curve.
The role of QEMU in modern infrastructure is greater than most users realize. When a cloud provider starts a VM for you, the chance is high that QEMU is involved somewhere. When a developer builds a container image for another platform, QEMU is the silent intermediary.
For those who must choose between QEMU and a closed alternative: the closed options are often more user-friendly and have better support. But they demand a price in flexibility and transparency that you do not always see on the invoice.
The real question is not whether QEMU is better than the rest, but whether you want to manage the complexity that comes with the flexibility. For those who do, QEMU is one of the most complete virtualization solutions that exists. For those who don't, there are plenty of other paths.
Every virtual machine you start with QEMU is a small miracle of translated instructions and emulated hardware. It works because thousands of developers have tinkered with it for two decades, and it keeps working because the basics — a simple command with a disk image — have never changed.