Botspot bvm runs Windows 11 ARM on a Raspberry Pi

The gap bvm fills on ARM Linux boards

Running a full Windows 11 desktop on an ARM Linux machine is awkward, because the usual virtualization tooling around those boards is written for x86 hosts. Botspot bvm is a shell script that wraps QEMU and KVM so a Windows 11 ARM guest can be created on a Raspberry Pi 5 or any other ARM Linux system. The project describes itself as a user friendly, high performance Windows 11 Virtual Machine on ARM Linux, and the intended reader is a person who wants Windows on inexpensive ARM hardware for classroom sessions, software testing or occasional desktop work, and who does not want to hand-write a QEMU invocation or assemble a Windows image from scratch. The project's premise is that the guest operating system is the easy part of the job, while the chain of small steps around it is where people get stuck. That chain is what the script automates, and the setup walkthrough in the project documentation opens with a warning that there are no usual sticking points.

The main topic tags on the repository place the project in the ARM Linux, Raspberry Pi and Windows virtualization space, and the primary language is Shell. The whole implementation lives in a single script named bvm at the top level of the repository, alongside a COPYING file, a README.md and a resources directory that holds graphics such as the application icon. A repository that small is a useful signal about the intended shape of adoption: you clone it, read one script, and drive it through named subcommands rather than adopting a service with configuration surfaces of its own.

How KVM, passthrough and the connect mode carry the work

The performance story rests on hardware virtualization rather than instruction translation. The documentation states that because KVM is used, the guest runs with virtualization instead of emulation, which results in no significant speed difference compared to installing Windows directly. That is the central claim, and it is also the claim your own hardware has to support for the project to be more than a curiosity.

Around that core, bvm wires up the I/O paths people actually need. It uses network passthrough to the Linux network stack, so Ethernet and WiFi work out of the box. It uses audio passthrough into pipewire, pulseaudio or ALSA, so playback works without extra setup. It can hand any USB device directly to Windows. A shared folder exposes the Linux home directory to the guest, and the documentation points you at This PC in Windows and the `home` network share to reach it, with changes synchronized immediately. On the software side, Microsoft's built-in Prism emulator handles x86 and x64 applications, which the project contrasts with Wine, noting that Wine fails on everything but old, simple programs.

The `connect` mode is where most of the polish lives. The script boots the guest headless and then attaches a remote desktop client to it. Earlier versions used FreeRDP, but the project has since switched to Remmina, and a `connect-freerdp` command remains for people who prefer the older client. The connect path is documented as offering better audio, clipboard synchronization, file sharing, dynamic screen resizing and higher performance graphics.

A first Windows 11 guest in five commands

Getting the script is a clone and a help call. The help output is where the useful detail lives, since the usage notes direct you to read it and follow the instructions.

git clone https://github.com/Botspot/bvm
bvm/bvm help

An alternative route exists through Pi-Apps, which performs the same installation and makes uninstalling easier; the project states that bvm stays updated either way. Once the script is in place, a guest is created in discrete steps rather than one opaque command, and between each step you can change what happens, edit the config file, retry a step or do something else entirely.

The sequence below creates the config file, downloads Windows and drivers, bundles everything for first boot, runs the unattended installation, and finally starts the machine.

bvm/bvm new-vm ~/win11
bvm/bvm download ~/win11
bvm/bvm prepare ~/win11
bvm/bvm firstboot ~/win11
bvm/bvm boot ~/win11

The `new-vm` step writes a config file at `~/win11/bvm-config`, and the documentation asks you to read it. The `firstboot` step boots the Windows installer, installs Windows with some drivers, sets up a local user account and debloats the OS; you are told to let it finish automatically, and that the VM will shut down when the install completes. At that point you can delete the .iso files and the `unattended` folder from `~/win11` to reclaim storage.

For daily use, the project recommends skipping the direct `boot` path, because it is described as a little laggy and lacking features such as copy and paste transfer and a resizable screen. Booting headless and attaching separately is the better route:

bvm/bvm boot-nodisplay ~/win11

Then, from a second terminal, attach to the RDP service:

bvm/bvm connect ~/win11

Two maintenance commands round out the workflow: `bvm/bvm mount ~/win11` mounts the Windows main hard drive directly, which the documentation describes as useful for troubleshooting and further debloating, and `bvm/bvm expand ~/win11` grows that drive.

No graphics acceleration, so WebGL and 3D stay off the table

The project is explicit about its ceiling. Under what not to expect, it rules out a gaming rig: there is no graphics acceleration for now, so 3D features and WebGL do not work. The docs add that this could change once somebody works out virtualized graphics that talk to Vulkan, and point to notes further down the document.

That single limitation shapes how you should read the performance claims. The high graphics quality is described as snappy and quicker than you might expect, at least with the `connect` mode on Wayland on a Pi 5, but the examples given are Youtube and lightweight web games, which are somewhat playable without overclocking or extra tweaks. Video playback and simple browser content sit in a very different place from anything that needs a 3D pipeline or a WebGL context.

There is also a resource claim worth planning around: after installation and startup, the VM is said to use less than 1GB of RAM and minimal CPU when it is not in use, which leaves room for Linux applications on the host. Combined with the network and audio passthrough, this makes the design read like a companion machine rather than a desktop replacement, even though the Pi 5 is described as having become a much more capable desktop replacement in its own right.

How bvm differs from Wine and from hand-written QEMU

The README compares bvm against Wine directly, and it is worth keeping that comparison in proportion. Both routes exist to run Windows software on Linux. Wine translates calls rather than running a real Windows kernel, and the project states that it fails on everything but old, simple programs. bvm instead boots an actual Windows 11 ARM installation and leans on Microsoft's built-in Prism emulator for x86 and x64 binaries inside it, which is why the expectation is that all Windows applications should work. The trade-off is the obvious one: you are running a full operating system, so you need disk space, RAM and the patience to sit through an unattended installation.

The other comparison is against assembling a QEMU command line yourself. The dependency list installed on first run includes qemu-system-arm, qemu-system-gui, qemu-efi-aarch64, qemu-utils, seabios, ipxe-qemu, wimtools and remmina, plus remmina-plugin-rdp. Every one of those components has a matching argument in a manual invocation, and the choices bvm makes for you are visible: Remmina over FreeRDP for the connect client, the network share named `home`, the `~/win11/bvm-config` file, and the split new-vm, download, prepare and firstboot phases that let you inspect or retry each one.

That split-step approach is described as helping you learn how the tool works, adjust it, and build new features on top of it, which is a fair summary of why a single script can support a mount command for direct disk access and an expand command for growing the drive.

Bookworm backports, manual installs on Arch, and the first-run dependency list

First run installs a fixed set of packages:

git jq wget genisoimage qemu-utils qemu-system-arm qemu-system-gui qemu-efi-aarch64 remmina remmina-plugin-rdp nmap wget yad uuid-runtime seabios ipxe-qemu wimtools
#and either
wlfreerdp
#or
xfreerdp

The FreeRDP choice is tied to your desktop display setup, and the list is not cosmetic. On a non-standard distribution such as Arch you are expected to install those packages yourself, and the project makes an unusual offer here: Arch users are invited to change the `install_dependencies` function in the `bvm` script to install dependencies and send the change in a pull request. The stated reason is that the author does not use Arch.

On Debian Bookworm the script takes a different action, adding the `bookworm-backports` APT repository so that QEMU moves from version 7.2 to version 9.2. Version 7.2 does work, but the documentation says it lacks pipewire audio output support, which is a real constraint for anyone who wants the audio passthrough path. If you have a reason to avoid backports, the project asks you to open an issue explaining it, and says the behavior may change.

Two smaller installation touches are worth knowing about. The script creates icon symlinks under `~/.local/share/icons/hicolor/scalable/apps` so the desktop taskbar shows the right icons, including for QEMU and FreeRDP, and it adds a menu launcher at `~/.local/share/applications/bvm.desktop` in the Office category to run the GUI. It also symlinks itself to `~/.local/bin/bvm` so the command works from a terminal as `bvm`.

Licence, last push, and what to check before you upgrade

The repository is licensed under GPL-3.0, which is the usual shape for a shell script you are invited to patch and contribute back, and it is the license to check if you intend to redistribute a modified copy. The repository contains a COPYING file, and the default branch is main.

On maintenance, the facts are modest. The repository is not archived, and the last push was on 2026-08-02. The project publishes no GitHub releases, so there is no tagged upgrade path to follow and no changelog to read before pulling new commits. Every change arrives when you fetch the script, which means the config file and the sequence of subcommands can shift without a version marker. The project does state that bvm stays updated no matter whether it was installed by cloning or through Pi-Apps.

Three things are worth verifying before you commit a board to this. First, confirm that the QEMU version your distribution provides actually has the audio output support the connect mode depends on, because the backports path exists for a reason. Second, check that your desktop works with the connect client the project now defaults to, and switch to `connect-freerdp` if it does not. Third, read `~/win11/bvm-config` before you build anything on top of it, as the documentation asks, since the split-step flow only helps if you actually inspect the settings between phases.

Editorial conclusion

Adopt bvm if you need a throwaway Windows 11 ARM desktop on an ARM Linux board and would rather read a config file than assemble a QEMU command line, and skip it if 3D graphics, WebGL or a fully offline licensing workflow matter to you. Before you rely on it, confirm that your distribution either ships a new enough QEMU or is covered by the backports upgrade, that the connect mode's Remmina client handles your display setup, and that your hardware exposes the KVM device at all, since the last push was on 2026-08-02 and the project publishes no GitHub releases.

Frequently asked questions

Official sources

1. Botspot/bvm on GitHub
2. Issues
3. License: GPL-3.0
4. README