windows bhyve template

As of April 23, 2026, Coppice can launch a real Windows guest from /ui/. The current artifact is windows-server-2025: a bhyve template imported from Microsoft’s official Windows Server 2025 evaluation VHDX and exposed through the demo portal as a host-side bhyve framebuffer console over VNC. It is honest about its current shape: usable from the portal, console-only, and not yet a pooled SSH guest.

What works now

The current path is live on honor:

That is enough to reach the Windows first-boot sequence, OOBE, and the lock screen from an ordinary browser tab. The guest does not need an in-guest VNC server for this path to work; bhyve’s own framebuffer is the console.

There is now a reproducible browser receipt for that path:

Why this media

The current repo uses Microsoft’s official Windows Server 2025 evaluation VHDX because it is the fastest honest route to a real guest:

That is why the repo carries benchmarks/rigs/windows-server-eval-bhyve-template.sh instead of only an installer-oriented ISO path.

The older benchmarks/rigs/windows11-eval-bhyve-template.sh still exists for a future GUI-install experiment, but the Server 2025 VHDX is the path that yields a reproducible image today.

Runtime shape

The relevant files are:

The launch path is:

browser -> /ui/ -> POST /sandboxes {templateID:"windows-server-2025"}
        -> BhyveBackend console-start
        -> host metadata {coppice_console_vnc_host, coppice_console_vnc_port}
        -> noVNC -> /vnc-proxy/:id/websockify -> 127.0.0.1:<port> on honor

This is intentionally different from the jail-backed desktop VNC path. There is no jail IP and no in-guest X server. The console is the bhyve framebuffer itself.

Reboots and operator controls

Windows first boot does not come up in one uninterrupted VNC session. It reboots. bhyve exits with status 0 in that case, which means “guest rebooted”, not “guest died”.

The current repo now handles that explicitly:

That is why a temporary browser console error like Connection closed (code: 1006) can still appear during the reboot boundary while the visible session later recovers and lands back on OOBE or the lock screen. The transport survived; the guest just cycled the framebuffer under it.

For input, the portal exposes:

Browsers will not pass a literal Ctrl + Alt + Del chord through to the page, so the button and Ctrl + Alt + End are the supported routes.

What it is not yet

This is still console-first Windows, not full parity with the FreeBSD bhyve pool:

  1. No shell or filesystem surface yet. Host-console bhyve guests do not expose /exec, websocket shells, files, or wasm tools. The backend returns a clear “host-console bhyve guest” error there on purpose.

  2. No guest-side network/bootstrap consumer yet. The substrate can already mount an msdosfs seed disk labeled COPPICECFG with coppice-instance.txt. What is still missing is the Windows startup task or service that reads that disk and applies hostname/static IP settings.

  3. No pooled SSH guest path yet. The warm/checkout/return fast path still assumes guest SSH readiness. That means Windows does not yet participate in the SIGSTOP/SIGCONT pool the way python-bhyve does.

  4. No in-guest RDP integration yet. The current working path is VNC-to-bhyve-framebuffer. If Windows RDP becomes worth carrying, it should be added as a second stage after guest bootstrap, not confused with the current console path.

Practical next steps

The remaining work is straightforward and specific:

  1. Install and enable OpenSSH Server inside the Windows guest, then trust the host pool key for the chosen login user.
  2. Add a Windows startup script or service that mounts and consumes the COPPICECFG seed disk.
  3. Promote the template from “host-console launchable” to “pool-warmable” once the SSH-ready path is real.
  4. Make the browser smoke reboot-aware enough to follow the OOBE reboot boundary intentionally instead of only asserting first-paint console recovery.

Until then, the honest claim is: Coppice can launch a real Windows guest from the demo portal today, and the working UI surface is the bhyve framebuffer console.