Files
KNELPerf/docs/report-moonlight-desktop.md
T
ic-builder c1a5f67651
ci / audit (push) Successful in 22s
Docs beautify pass: README + ARCHITECTURE to PhysicalPlant standard (#826)
Emoji headers, shields, mermaid loop diagram, contents TOC, module table,
quick start, docs index, cross-links. Pattern: pfv-bms README.

https://projects.knownelement.com/issues/826#note-10
2026-09-06 15:05:30 -05:00

4.8 KiB
Raw Blame History

🖼️ Report: replacing the KDE/xrdp VM with a containerized desktop served from k8s

Status: PROPOSAL (v1, 2026-09-06) — awaits founder ruling. Ticket: #826. Source research: web-surveyed 2026-09-06 (sources linked at the end).

Context constraints (verified)

  • Xeon E5-2630 v2 (pfv-tsys7 class) has no iGPU / no Quick Sync — hardware video encode is impossible on the current CPU-only nodes. Software x264 (or a future NVIDIA node's NVENC) is the only path.
  • Current access path is xrdp/KDE over Tailscale at ~36 ms RTT. Protocol choice matters less than encoder cost and whether the Tailscale path is direct vs DERP-relayed (DERP caps ~5 Mbps and adds latency — check tailscale netcheck before blaming the desktop stack).
  • The cluster is CPU-only today, mixed with production workloads, flux gitops — heavy sustained CPU encoding on shared nodes is an operational risk.

Comparison

Sunshine+Moonlight Selkies-GStreamer Kasm Workspaces Webtop / Guacamole Tuned xrdp (baseline)
Transport Moonlight protocol, H.264/265/AV1 WebRTC (browser) KasmVNC over WebSocket VNC/RDP → WebSocket RDP
GPU needed No (x264 soft mode) but costly No (x264 soft) No No No
CPU cost on old Xeon HIGH: 24 cores sustained @1080p60 HIGH + WebRTC stack ~1 core MODERATE (framebuffer diff, no video encode) LOWMODERATE (Guacamole ~1527%/core per 12 users) LOW
Latency @36 ms RTT Best-in-class on direct path; 100200 ms if misconfigured Low Moderate; fine for desktop, visible on video Moderatehigh (protocol translation + browser) Moderate (tuned RDP is decent)
Client Native Moonlight apps (excellent) — NOT browser Any browser Any browser Any browser Any RDP client
k8s fit Awkward: privileged pod + /dev/uinput hostDevice, dummy X Good (purpose-built for k8s) Heavy control plane for one desktop Trivial pod + PVC (webtop); Guacamole = small extra stack Stays a VM
Persistence StatefulSet + PVC PVC Disposable by design webtop PVC-backed Full VM (best)
GitOps friendliness Medium High Medium High N/A

Recommendation

  1. Now: keep the tuned xrdp/KDE VM as baseline; do NOT put Sunshine/Moonlight on CPU-only nodes — real-time x264 eats 24 cores next to production tenants.
  2. Migration path: deploy linuxserver/webtop (KasmVNC variant) as a PVC-backed StatefulSet on a CPU-only node behind the existing ingress (browser access; WAN via Tailscale). This is the containerized successor for desktop-class use at 36 ms RTT: cheapest CPU, unprivileged pod, clean flux fit.
  3. WAN/browser fallback for the existing RDP VM: small Apache Guacamole stack (guacd + guacamole), accepting it is slower than native RDP clients.
  4. When the NVIDIA node lands: revisit Selkies-GStreamer (most k8s-native low-latency option; NVENC removes the encoder cost) as the premium tier. Sunshine+Moonlight earns its complexity (privileged pod, /dev/uinput) only if gaming-grade latency on native clients becomes a hard requirement — then pin it to the GPU node only, never shared CPU nodes.

Rollout: tuned xrdp VM stays during migration → webtop StatefulSet UAT → retire VM after human UAT → Selkies on the future GPU node.

Sources

Docs live on Discourse — this repo is the executable source of truth. Perf topic: https://community.turnsys.com/t/328