Quickemu: QEMU Wrapper for Windows, macOS and Linux VMs

What Quickemu replaces, and for whom

QEMU is a machine emulator and virtualiser with a very large option surface. Getting a Windows 11 guest to boot with TPM 2.0, the right firmware and a working display means assembling arguments for machine type, accelerator, firmware, disk image, network backend and display backend, and getting all of them mutually consistent. Quickemu exists to remove that assembly step. The README describes it as a wrapper for QEMU that "automatically does the right thing" when creating virtual machines, with the explicit claim that there is "no requirement for exhaustive configuration options".

The intended user is someone who wants to test or use an operating system quickly. The README states the original objective was to enable quick testing of Linux distributions where the virtual machines and their configuration can be stored anywhere, such as external USB storage or a home directory, and no elevated permissions are required to run them. That last point shapes the whole design: Quickemu is a pair of shell scripts, not a system service, so it does not need a daemon, a system-wide database of VM definitions, or root.

The scope has grown well past Linux testing. The README lists macOS releases from Mojave through Sequoia, Windows 10 and 11 including TPM 2.0, Windows Server 2016, 2019 and 2022, most of the BSDs, and non-Linux systems such as FreeDOS, Haiku, KolibriOS, OpenIndiana and ReactOS. It also claims nearly 1000 operating system editions are supported.

How quickget and quickemu split the work

The architecture is two executables with one artifact between them. quickget resolves an operating system name and edition, downloads the upstream ISO, and writes a configuration file. quickemu reads that configuration file and launches QEMU with the hardware it detected on the host. The README states that quickemu "enumerates your hardware and launches the virtual machine with the optimum configuration best suited to your computer".

That split matters operationally. The .conf file is plain text and portable, which is why the project can claim VMs and their configuration can live on external storage. You can move the directory, keep the ISO and disk image alongside the config, and start it on another machine with the same scripts. Nothing in the described flow registers the VM with a system-wide service.

The feature list shows how much QEMU surface the wrapper covers on your behalf: SPICE with host and guest clipboard sharing, VirtIO-webdavd file sharing for Linux and Windows guests, VirtIO-9p for Linux and macOS guests, Samba sharing if smbd is installed on the host, the QEMU Guest Agent, VirGL acceleration, USB and smartcard pass-through, automatic SSH port forwarding, network port forwarding, full duplex audio, Braille support, and EFI with or without SecureBoot alongside Legacy BIOS boot. ARM64 guest support is listed too, described as native on ARM hosts and emulated on x86_64. Each of those is a decision the wrapper makes rather than one you make, which is the trade you accept.

Installing Quickemu and booting a first VM

The README does not carry install commands. It points to a wiki page titled Installation for that step, and the repository also ships packaging material: a flake.nix, package.nix, devshell.nix and a debian/ directory are present at the top level, so Nix and Debian packaging paths exist in the tree. Use the wiki installation page for your distribution rather than guessing at a command.

Once installed, the README gives a two-step quick start. The first command downloads the ISO for the operating system you want and creates the configuration file. This example is quoted directly from the README:

quickget nixos unstable minimal

Run quickget with no arguments and it prints the list of all supported operating systems, which is the practical way to find the exact name and edition tokens your target uses.

The second command starts the virtual machine using the configuration file that quickget just wrote:

quickemu --vm nixos-unstable-minimal.conf

If the VM starts, QEMU opens its display window and the guest begins booting from the downloaded ISO. The configuration file stays in the directory where quickget created it, so that directory is the unit you back up or move. The README also links a demo recording on asciinema, which is the fastest way to see the expected output before running anything yourself.

Where the wrapper model gets in your way

The central limitation is the one that makes the project attractive: quickemu decides. The README says it enumerates your hardware and applies the configuration best suited to your computer, and that the point is to avoid exhaustive configuration options. When your requirement falls outside what the wrapper infers, you are editing a generated file or working around the script, and at that point you are maintaining QEMU arguments anyway, just with an extra layer in between.

Platform support is asymmetric. Host support is listed for Linux and macOS only. Guests get far broader treatment, but if your host is Windows, the README does not claim support for you.

Several features are conditional on the host rather than bundled. Samba file sharing is described as available "if smbd is installed on the host". Accelerated graphics depend on the host graphics stack the README refers to as VirGL. Guest Agent access depends on the agent running inside the guest. None of these are failures of the project, but each is a place where a feature listed in the README will not appear on a machine that lacks the prerequisite, and the README does not enumerate per-distribution prerequisites.

Finally, the interface is a command line. The README lists alternative frontends in the wiki, and Quickgui appears in the related searches, but the main repository is the quickemu, quickget and quickreport scripts. If you expect a desktop application from the core project, you are looking at the wrong artifact.

Quickemu against libvirt and plain QEMU

The honest comparison is with the two things people already use to run QEMU: libvirt with virt-manager, and QEMU invoked directly.

libvirt manages VMs as a service. Definitions live in a daemon, storage pools are declared, and virt-manager gives you a GUI over the same API. That model scales to a host running many guests that other people connect to, and it gives you a consistent place to look up what exists. Quickemu gives up all of that. It has no daemon, no registry, and no shared state; a VM is a directory containing a config file, and if you lose the directory you lose the definition. In exchange, no elevated permissions are needed, which is exactly what the README says the project wanted.

Plain QEMU is the other end. You get every option and no help. Quickemu is a thin layer over the same binary, and the README is explicit that the wrapper exists to avoid exhaustive configuration. The difference is not capability, since the underlying emulator is the same. It is who writes the arguments and who keeps them consistent when the guest needs TPM 2.0, EFI, SPICE and file sharing at once.

One consequence of the wrapper approach is worth naming: because quickemu infers hardware from the host, the same .conf can produce different virtual hardware on two machines. That is convenient for portability and awkward when you need two environments to be identical.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-14. That is recent enough that the project is being worked on, and the release list supports the same reading: 4.9.9 on 2026-02-10, 4.9.8 on 2026-01-24, and 4.9.7 on 2024-12-30. Note the gap between 4.9.7 and 4.9.8, which is over a year. Releases are not on a fixed cadence.

Upgrade cost is low in the ordinary case. The scripts are shell, and an upgrade replaces them. What you own is the .conf files and the disk images, and the README's portability claim means those survive a script upgrade. The realistic risk is the reverse direction: a config written by an older quickemu may not describe what a newer one expects, and the README does not document a migration or compatibility policy for configuration files.

The licence is MIT, stated in the repository metadata and present as a LICENSE file at the top level. That is a permissive licence, and the practical implication is that redistributing or modifying the scripts carries few obligations beyond preserving the notice. This is a description of the licence text as identified, not legal advice; read the LICENSE file if the distinction matters to your organisation.

One maintenance detail worth checking before you build on it: the repository contains an AGENTS.md file at the top level alongside CONTRIBUTING.md and SECURITY.md, and the project has a .gitmodules file, meaning at least part of the tree is a submodule. Neither is documented in the README, so treat the layout as the source of truth for how the project is assembled.

Editorial conclusion

Adopt Quickemu if you want a Windows 11 or macOS guest on a Linux or macOS host without hand-writing QEMU arguments, and if you are content with the configuration quickget generates. Do not adopt it if you need libvirt-style fleet management, if you are on Windows as a host (the README lists host support for Linux and macOS only), or if your workflow depends on a GUI written by the same project. Before committing, run quickget with no arguments to see whether your target OS edition is in the supported list, and check that the .conf it writes matches the disk, memory and display setup you actually need.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. quickemu-project/quickemu on GitHub
4. README
5. Releases