Can Firecracker Run Windows? No, and the Reason Is the Point

No. Firecracker cannot boot a Windows guest, there is no flag for it, there is no patch series pending, and it is not on anyone's roadmap. If you came here from a search box, that is the answer and you can stop reading. If you are about to spend an afternoon looking for the configuration option that must surely exist somewhere, I would like to save you the afternoon: it does not exist, and the reason it does not exist is more interesting than the absence.

Here is the one-sentence version. Firecracker has no firmware. It does not run a BIOS or a UEFI implementation; it loads a Linux kernel image into guest memory and jumps straight into its entry point. Windows begins its life as a boot manager that a firmware environment loads and executes. There is no firmware stage for that boot manager to run in, so Windows never gets as far as discovering that it also has no devices it recognises. Every other blocker — and there are several, each sufficient on its own — sits behind that one.

I'm Ajay; I build PandaStack, which runs Firecracker microVMs as a product, so I spend a lot of time in exactly this part of the stack. Two housekeeping notes before the detail. First, Firecracker's device model has genuinely grown across releases, and a good deal of the "Firecracker has no X" writing on the internet — including, I will cheerfully admit, some claims I would have made confidently a year ago — is now out of date. Check the version you are actually running against upstream's own documentation rather than trusting me or anyone else. Second, none of what follows is a complaint. The omissions are the product.

What Firecracker actually hands a guest

Firecracker's FAQ still describes the device model with a number, and the number is six: virtio-net, virtio-block, virtio-vsock, virtio-balloon, a serial console, and a minimal i8042 keyboard controller whose entire job is to notice that the guest asked to reboot. That is the machine. Not a stripped-down PC — a different shape of object that happens to run the same kernels.

"only 6 emulated devices are available" — Firecracker's own FAQ, which is already behind its own code.

It is behind the code because the list has grown. Current Firecracker also offers an entropy device (virtio-rng) and a pmem device, and — this is the part that surprises people who last looked a couple of years ago — a virtio PCI transport behind an opt-in `--enable-pci` flag, with hot-plug and hot-unplug of virtio-block, virtio-net and virtio-pmem marked as a developer-preview feature. The guest kernel config upstream documents for Firecracker lists `CONFIG_ACPI` and `CONFIG_PCI` among the relevant options. So the flat statements "Firecracker has no PCI bus" and "Firecracker has no ACPI" are, as of today, wrong in the general case, even though they remain true of most deployments and of ours.

What has not grown, and what is structural rather than incidental, is everything in this list:

• No firmware of any kind. No SeaBIOS, no OVMF, no EDK II, no option ROMs, no boot sector execution.
• No display device. No VGA, no QXL, no virtio-gpu, no framebuffer. The serial port is the entire graphics subsystem.
• No legacy storage emulation. No IDE, no SATA/AHCI, no CD-ROM, no El Torito ISO boot. A disk is a raw file behind virtio-block.
• No USB controller, no sound device, no emulated TPM, no PS/2 mouse, no floppy — and the keyboard controller that does exist is a reset button wearing a keyboard's clothes.
• No device passthrough. There is no VFIO machinery, so no GPU, no real NIC, no hardware dongle.
• No CPU emulation across architectures. The guest must be built for the host's architecture; Firecracker is a KVM frontend, not an emulator.

Blocker one: there is no firmware, and nowhere to put one

This is the load-bearing one. Firecracker's boot configuration lives at a single API endpoint, `PUT /boot-source`, and that endpoint accepts exactly three fields: `kernel_image_path` (required), `boot_args`, and `initrd_path`. That is the complete schema. There is no `firmware`, no `bios`, no `rom`, no `machine` field, and no second endpoint hiding one.

# Firecracker's boot-source API, in full. Three fields, one of them required.
# Field names verified against src/firecracker/swagger/firecracker.yaml
# upstream -- not from memory, because this is exactly the kind of thing
# people get subtly wrong.
SOCK=/run/firecracker.socket

curl --unix-socket "$SOCK" -i \
  -X PUT 'http://localhost/boot-source' \
  -H 'Content-Type: application/json' \
  -d '{
        "kernel_image_path": "/var/lib/pandastack/kernels/vmlinux-5.10.239",
        "boot_args": "console=ttyS0 reboot=k panic=1 pci=off"
      }'

# The root disk is a raw filesystem image behind virtio-block. Not an ISO,
# not a CD-ROM, not a partitioned device with a boot sector that something
# executes: the guest kernel is ALREADY RUNNING by the time this is mounted.
curl --unix-socket "$SOCK" -i \
  -X PUT 'http://localhost/drives/rootfs' \
  -H 'Content-Type: application/json' \
  -d '{
        "drive_id": "rootfs",
        "path_on_host": "/var/lib/pandastack/vms/$VMID/rootfs.ext4",
        "is_root_device": true,
        "is_read_only": false
      }'

# There is no third request that introduces firmware. Point kernel_image_path
# at an OVMF build and you are handing a UEFI image to a loader that expects an
# ELF vmlinux, a bzImage, or (on aarch64) a PE kernel. It fails at parse time,
# which is the kindest failure mode available to it.

On x86_64 Firecracker loads an uncompressed ELF `vmlinux` (recommended) or a `bzImage`; on aarch64 it takes a PE-formatted kernel. It will also use the PVH direct-boot entry point if the kernel image carries the `XEN_ELFNOTE_PHYS32_ENTRY` note. Every one of those is a kernel-image format. None of them is a firmware format, and the loader has no code path that would execute one.

Windows, meanwhile, boots the way a physical PC boots, because that is what it was designed to be installed on. Firmware initialises the platform, finds an EFI system partition or a boot sector, and executes a Microsoft boot manager, which loads the kernel and a pile of boot-start drivers. Remove the firmware stage and you have not made Windows boot faster; you have removed the first instruction it was ever going to execute. The microVM comes up, finds something at `kernel_image_path` that is not a kernel, and declines.

Blocker two: nothing Windows Setup could boot from or see

Suppose you solved the firmware problem — ported CLOUDHV or OVMF to Firecracker's memory layout, taught the loader to run it. You would land immediately in the second wall, and it is the one people think `virtio-win` solves.

The virtio-win drivers are real, mature, signed, and widely deployed. They are also, historically, *PCI* virtio drivers: they bind to virtio devices that appear on a PCI bus with a PCI vendor and device ID, because that is how every other hypervisor presents virtio to Windows. Firecracker's default transport is virtio over MMIO, where devices are discovered from the kernel command line or a device tree rather than by walking a bus. Windows has no mechanism for enumerating virtio-MMIO devices and no driver that would bind to one if it did.

The `--enable-pci` developer preview makes that paragraph less absolute than it used to be, and it is worth being honest about that rather than repeating the old line. But it does not get you to a Windows guest, for three reasons. The bus carries virtio-block, virtio-net and virtio-pmem — not a Q35 chipset with an AHCI controller and a display adapter. There is no fallback storage device for Windows Setup to use while you install the storage driver, which is the exact chicken-and-egg the virtio-win ISO exists to break on other hypervisors. And upstream currently does not even deliver a hot-plug notification to the guest: the documented procedure is to `echo 1 > /sys/bus/pci/rescan`, which is a sentence about Linux.

Blocker three: the serial port is the entire graphics subsystem

A Firecracker guest's output device is `ttyS0`. That is not a reduced display, it is the absence of one — there is no VGA text mode, no framebuffer, no virtio-gpu, nothing for a graphical installer to render into. Our own guests boot with `console=ttyS0 reboot=k panic=1 pci=off`, and I would point out that a production platform shipping `pci=off` in its kernel command line is not one quietly planning to enumerate a PCI bus later.

Windows can do a surprising amount over a serial line — KDCOM kernel debugging is serial, and Server Core plus the Special Administration Console gets you a long way without a desktop. What it cannot do over a serial line is install itself, or run its recovery environment, or display the screen that tells you which driver it is missing. Linux has spent thirty years being comfortable with a machine whose only output is a UART. Windows has not, and no amount of unattended-install XML changes the fact that there is no display device present at all.

The supported guest list is a description of the boot path

Here is the cleanest way to see why this is permanent. Firecracker's FAQ says it supports Linux hosts and Linux guests, plus OSv. Its PVH documentation adds FreeBSD, which has had Firecracker support since 14.0 because FreeBSD enables the PVH direct-boot entry point by default. The kernel support policy names the specific guest kernel versions upstream validates in CI — 5.10, 6.1 and 6.18 at the time of writing, each with a published minimum end of support.

Look at what that set has in common. Linux, OSv and FreeBSD are all operating systems that can be loaded directly into memory and entered at a documented entry point, with no firmware in between. That is not three unrelated ports; it is one property, and the supported-guest list is simply the list of systems that have it. Windows does not have it and has never needed to, because Windows has always been installed onto machines that have firmware. A hypervisor whose entire boot design is "skip the firmware" and an operating system whose entire boot design is "the firmware loads me" do not meet in the middle.

Every omission on that list is why a microVM boots in milliseconds

It is tempting to read the device model as poverty. It is a budget. A VMM with no firmware, no PCI enumeration by default, no USB stack, no graphics adapter and no legacy chipset is a small Rust codebase with a correspondingly small attack surface — and the vCPU threads on the other side of that boundary are assumed to be running hostile code from the moment they start, which is the whole premise. There is less device emulation to fuzz because there are fewer devices. Upstream publishes a hard startup specification in `SPECIFICATION.md` and enforces it with integration tests on every merge; read it there rather than taking a number from a blog post, mine included.

You cannot keep that budget and also boot Windows. Supporting Windows means firmware, PCI with a real chipset, legacy storage emulation, a display device, probably a TPM, and the device-driver surface that comes with each. At the end of that project you have written QEMU. QEMU already exists, has had decades of work poured into it, runs Windows well, and is maintained by people who are extremely good at exactly this. Rebuilding it inside a VMM whose selling point is that it is not QEMU would be a strange way to spend a decade.

Firecracker's answer to "can it run Windows" is the same as its answer to "does it have a sound card": no, deliberately, and that is in the brochure.

So what do you actually use?

QEMU/KVM with OVMF and virtio-win — the standard answer

This is the one that works, and it is not a consolation prize: it is the path essentially everyone running Windows on Linux hosts takes, including every cloud that offers Windows instances on KVM. You give QEMU a Q35 machine, an OVMF firmware build, the Windows installation media, the virtio-win driver ISO so Setup can see the virtio disk, and a display device so Setup can draw on it. Windows 11 additionally wants a TPM 2.0, which `swtpm` provides, and at least two cores.

#!/usr/bin/env bash
# THE QEMU ANSWER. This is not a Firecracker command and has no Firecracker
# equivalent -- every flag below names something Firecracker deliberately
# does not have.
set -euo pipefail

IMG=windows-disk.raw
WIN_ISO=windows_server_x64_dvd.iso
VIRTIO_ISO=virtio-win.iso
OVMF=/usr/share/OVMF/OVMF.fd      # the firmware. The whole point.

qemu-img create -f raw "$IMG" 64G

# Windows 11 wants a TPM 2.0; swtpm emulates one.
mkdir -p /tmp/mytpm1
swtpm socket --tpm2 \
  --ctrl type=unixio,path=/tmp/swtpm-sock \
  --tpmstate dir=/tmp/mytpm1 \
  --flags startup-clear --daemon

qemu-system-x86_64 \
  -machine q35,accel=kvm \
  -cpu host -smp 4 -m 4G \
  -bios "$OVMF" \
  -cdrom "$WIN_ISO" \
  -drive file="$VIRTIO_ISO",index=0,media=cdrom \
  -drive if=none,id=root,file="$IMG" \
  -device virtio-blk-pci,drive=root,disable-legacy=on \
  -netdev user,id=mynet0 \
  -device virtio-net-pci,netdev=mynet0,disable-legacy=on \
  -vga std \
  -chardev socket,id=chrtpm,path=/tmp/swtpm-sock \
  -tpmdev emulator,id=tpm0,chardev=chrtpm \
  -device tpm-tis,tpmdev=tpm0

# During Setup: "Load driver" -> point it at the viostor directory on the
# virtio-win CD, or Windows will tell you there are no drives to install to.
# That step is the chicken-and-egg Firecracker has no way to break.

Describe the trade honestly to whoever asked. QEMU's device model is enormous next to Firecracker's, so the host-facing attack surface is much larger; boot takes firmware initialisation and bus enumeration before the guest kernel gets control; and a Windows guest's memory footprint and startup time are in a different category from a minimal Linux guest's. In exchange it works, it snapshots, it live-migrates, and it is boring — which is a compliment. Check the flags against your QEMU version's own documentation; the machine-type and firmware filenames in particular move around between distributions.

Cloud Hypervisor — closer in spirit, and it does support Windows

Cloud Hypervisor is the interesting middle. It shares a lot of ancestry and philosophy with Firecracker — Rust, KVM, modern virtio, a deliberately narrow feature set aimed at cloud workloads — and it made a different call on firmware. Its documentation states Windows guest support from release 0.10.0 onwards, via an EDK II-based UEFI firmware (`CLOUDHV.fd` on x86_64) passed in the `--kernel` option, with a Windows image that already has virtio drivers integrated. UEFI only; their docs say BIOS boot is not supported.

# Cloud Hypervisor booting a prepared Windows image. Note what goes into
# --kernel: a UEFI firmware blob, not a kernel. That single substitution is
# the thing Firecracker's boot-source API cannot express.
cloud-hypervisor \
  --kernel ./CLOUDHV.fd \
  --disk path=./windows-disk.raw,image_type=raw \
  --cpus boot=2,kvm_hyperv=on \
  --memory size=4G \
  --serial tty \
  --console off \
  --net tap=

# Two gotchas straight from their docs, not from me: kvm_hyperv=on is
# mandatory for Windows, and you still need QEMU at least once to perform
# the original installation onto the image. Check the current state of
# docs/windows.md in their repo before planning around any of this.

Two honest caveats. The installation step still goes through QEMU — Cloud Hypervisor runs the resulting image, it does not install Windows for you. And their own Windows documentation carries live warnings about specific configurations, TPM among them, so treat `docs/windows.md` in the Cloud Hypervisor repository as the source of truth for whatever version you pick up, rather than this paragraph or any other blog's summary of it.

Managed Windows — the boring answer that usually wins

If you need Windows seriously rather than incidentally, the cheapest engineering decision is usually to stop building virtualisation and rent it. Hyper-V on Windows Server, Azure Windows VMs, EC2 Windows instances, or GitHub-hosted Windows runners if the need is CI. The reason is less about hypervisors than about licensing: Windows guest licensing is a real constraint with real compliance surface, and managed providers have already solved it in a way that holds up under an audit. Rolling your own Windows fleet to save money frequently does not, once a licence specialist looks at it.

And while you are here: macOS and iOS

People who ask about Windows guests often want macOS builds next, so briefly: the answer there is also no, with the same shape and a completely different reason. The technical obstacles are surmountable; the licence is not. Apple's terms require macOS to run on Apple hardware, which rules out a Linux-host microVM regardless of what your hypervisor can emulate. The real answer is Apple hardware — a Mac mini in a rack, or one of the managed Mac CI providers — and it is a licensing conversation rather than an engineering one.

Two ways to not need a Windows guest at all

Before you build any of the above, check whether you need Windows running or just Windows artefacts, because those are very different projects.

• Cross-compilation. The MinGW-w64 target produces real Windows PE binaries from a Linux host, and for a lot of C, C++, Go and Rust it works cleanly — Go in particular treats `GOOS=windows` as unremarkable. The MSVC target is harder: it needs Microsoft's toolchain and its licensing, and the tooling that fetches the MSVC CRT and Windows SDK for cross-use lives in a grey area you should read the EULA about yourself. The honest limit: cross-compiling gives you a binary, not a test run. You have built for Windows without ever executing on Windows, and the bugs that matter are often in that gap — path separators, case sensitivity, file locking, DLL search order.
• Wine. Genuinely good, genuinely not a compatibility guarantee. It runs a great deal of Windows software on Linux and is a legitimate answer for smoke-testing a GUI binary or running a build tool that happens to ship only as a `.exe`. It is not an answer for validating that your software works on Windows, because when something fails under Wine you cannot easily tell whether you found your bug or Wine's. Treat a green Wine run as encouraging and a red one as unexplained.
• The third option nobody frames as an option: check whether your runtime is cross-platform already. This is by far the most common answer, and the most commonly missed.

What you need versus what to actually do

The `.NET only` row deserves the emphasis, because it is where most of the traffic to a question like this actually belongs. .NET stopped being a Windows story the better part of a decade ago. ASP.NET Core ships Kestrel, a cross-platform managed web server; the runtime, the SDK and the test tooling all run natively on Linux. If the reason you went looking for Windows microVMs is a C# service or a `dotnet test` run, you do not need a Windows guest, an OVMF build, or a licence — you need a Linux box with the .NET SDK on it.

# The .NET row, concretely: a real `dotnet test` inside a Linux Firecracker
# microVM. No Windows guest involved anywhere.
from pandastack import Sandbox

INSTALL = """set -eux
curl -fsSL https://dot.net/v1/dotnet-install.sh -o /tmp/dotnet-install.sh
bash /tmp/dotnet-install.sh --channel 8.0 --install-dir /opt/dotnet
"""

# ttl_seconds is an IDLE timeout, not a walltime budget -- the reaper measures
# time since last activity, so a long build does not get killed mid-flight.
with Sandbox.create(template="base", ttl_seconds=900) as sbx:
    sbx.exec("mkdir -p /work")
    sbx.filesystem.write("/work/install-dotnet.sh", INSTALL)

    # exec_stream honours timeout_seconds and gives you live output; one-shot
    # exec() has no server-side deadline today, so bound long work in the
    # shell with `timeout` instead of trusting a client-side kwarg.
    rc = sbx.exec_stream(
        "bash /work/install-dotnet.sh",
        on_stdout=print,
        on_stderr=print,
        timeout_seconds=600,
    )
    assert rc == 0, f"dotnet install failed: {rc}"

    sbx.exec("timeout 120 git clone --depth 1 https://github.com/acme/widget.git /work/src")

    code = sbx.exec_stream(
        "cd /work/src && PATH=/opt/dotnet:$PATH timeout 900 dotnet test --nologo",
        on_stdout=print,
        on_stderr=print,
        timeout_seconds=1200,
    )
    print("dotnet test exit code:", code)

Where PandaStack sits, stated plainly

PandaStack runs Linux Firecracker microVMs. Guest kernel 5.10, Ubuntu 24.04 userspace, virtio over MMIO, and `pci=off` in the guest command line. There are no Windows sandboxes, there is no Windows template, and there will not be one, for exactly the reasons above — we inherit Firecracker's boot path, and that boot path is the feature we are selling. If you need a Windows guest, we are not your platform and I would rather say so in a blog post than in a sales call.

What we do get from that constraint is the thing the constraint was for. Every create is a restore of a baked snapshot rather than a cold boot, which lands at a p50 of about 179 ms and a p99 of around 203 ms, with the `/snapshot/load` step itself around 49 ms; only the very first spawn of a template before its snapshot is baked pays a cold boot of roughly three seconds. Forking a running sandbox, memory and disk copy-on-write, is 400–750 ms on the same host and 1.2–3.5 s across hosts. None of that is reachable with a firmware phase in front of it. First-party templates are `base`, `code-interpreter`, `agent`, `browser` and `postgres-16`; `base` carries mise with Node, Python 3.12, Go and Bun pre-warmed, and anything else — the .NET SDK included — installs at deploy time.

The thing I would want you to take away is not the no. It is that the no is diagnostic. When a tool cannot do something, it is worth asking whether the gap is an unfinished feature or a load-bearing wall, because the two call for completely different responses. Firecracker's missing Windows support is a wall: it is the same decision as the millisecond boot, the small attack surface and the five-megabyte VMM overhead, viewed from a different angle. Firecracker for Linux workloads, QEMU or Cloud Hypervisor when you need a machine that looks like a PC, and a managed provider when you need Windows and would rather not become an expert in it. Three tools, three jobs, and no config flag that collapses them into one.