Community fork keeps SPICE Windows guest agent alive after Red Hat abandons upstream

A fork picks up an abandoned project

A community fork has taken over maintenance of the SPICE Windows guest agent after its upstream project was abandoned. The repository, hosted on GitHub as nefarius/vd_agent, reached the Hacker News front page under the title "I refuse to let SPICE die". According to the project's documentation, the code is a public mirror of the freedesktop.org spice/win32/vd_agent tree, and Red Hat — the original copyright holder — no longer maintains upstream SPICE.

The fork's goal is narrow and practical: keep the Windows agent compiling and installing cleanly on current guests, with Windows 11 virtual machines on Linux hosts named as the primary target.

What the Windows agent provides

The guest agent is the piece that makes a Windows VM feel integrated rather than like a remote screenshot. Per the repository, it provides client-side mouse mode without trapping the pointer, desktop resolution that follows the client window, clipboard sharing for text and images, and file transfer into the guest. It runs as a Windows service named spice-agent that starts vdagent.exe in each user session.

The tree also carries a multi-GPU mouse fix, commit d7405ee in vdagent/desktop_layout.cpp: when a real GPU is passed through to the guest alongside the SPICE display device, the agent previously lost mouse movement, and the fix resolves that.

Build, signing and release pipeline

The supported build path is MSYS2 with the UCRT64 toolchain and Autotools, which produces the x64 MSI installer. A CMake plus MSVC route remains available for local development but does not produce an installer. Build-time submodules for spice-protocol and spice-common are pinned to fixed commits, with an explicit warning not to bump them casually.

The release engineering is more rigorous than the project's abandoned origins might suggest:

• GitHub Actions builds the x64 MSI on a windows-2022 runner.
• Tagged releases must be signed. Signing goes through a SignRelay setup, the same flow the maintainer uses for the DsHidMini project, so the code-signing certificate never lands on the CI runner. Binaries and the MSI are signed in place and verified with Authenticode checks before publishing.
• Each release attaches the MSI and a SHA-256 checksum to a GitHub Release.
• The MSI keeps the historical WiX UpgradeCode so installing over an older package upgrades cleanly; related products are removed after InstallValidate so shared components get recopied instead of deleted by the old uninstaller.
• Version strings come from git describe, and published tags stay immutable — a failed signed release means moving the tag forward or cutting a new version, never reusing an MSI filename with different bytes.

Two scope changes accompany the fork: x86 MSI builds are no longer produced by the maintained pipeline, and Fedora cross-builds still exist but do not feed GitHub Releases. The license remains GPL-2.0-or-later, copyright stays with Red Hat and other upstream authors, and the fork claims no Red Hat or SPICE trademarks.

A hands-on validation checklist

Before a release ships, the maintainer verifies it against a Windows 11 guest on QEMU/KVM using the QXL or qxl-wddm-dod display device. The checklist covers clean installs and upgrades, service state, a live agent channel after reconnecting the viewer, two-way clipboard with text and a bitmap, file drops onto the desktop, dynamic resolution when the WDDM QXL driver is in use, and pointer tracking in a GPU passthrough configuration.

Why it matters

SPICE guest tooling is quietly load-bearing for Linux virtualization: without an agent that installs and runs on current Windows, virtual machines lose clipboard sharing, file transfer, dynamic resolution and comfortable mouse handling. Red Hat stepping back from upstream SPICE left a gap, and this fork fills it for one important component. It also models what a credible community takeover looks like — reproducible CI, signed artifacts with the key held off-runner, immutable published releases and documented validation. The open question is durability: the fork currently rests on one maintainer, and its pinned submodules mean the wider SPICE protocol stack still sits on upstream code that nobody is driving forward.