Reports as routable folder pages (fix untracked drop) (#826)
This commit is contained in:
@@ -0,0 +1,90 @@
|
||||
---
|
||||
title: report-amt-power-telemetry
|
||||
visibility: private
|
||||
---
|
||||
|
||||
# 🔌 Report: Intel AMT / vPro per-system power-telemetry feasibility (tsys1,3,4,5,9 + 6,7)
|
||||
|
||||
Status: PROPOSAL (v1, 2026-09-06). Ticket: #826. Hardware verified live via
|
||||
dmidecode 2026-09-06 (tsys9 not yet reachable — identification step included).
|
||||
|
||||
## Executive answers
|
||||
|
||||
**Does AMT provide power usage data? Can it be pulled from the BIOS?**
|
||||
**No — no Intel AMT version (9.x through current) exposes real-time watt
|
||||
telemetry, via BIOS or any API.** Intel's own forum answer is categorical:
|
||||
AMT provides power *control* (on/off/cycle/boot-once), not power
|
||||
*measurement*. The Redfish `Power`/`PowerConsumedWatts` resource is a
|
||||
server-BMC feature (iDRAC/iLO wired to PSU metering hardware), not an AMT
|
||||
feature. So AMT is worth enabling only for remote KVM/power-control, never
|
||||
for watts.
|
||||
|
||||
## Per-system table (hardware verified by dmidecode 2026-09-06)
|
||||
|
||||
| System | Platform (verified) | AMT/vPro? | Watts via mgmt? | Best watt source |
|
||||
|---|---|---|---|---|
|
||||
| pfv-tsys1 | OptiPlex 9020, i7-4770 (Haswell), Q87 | YES — AMT 9.1 (Dell spec confirms vPro/iAMT 9.x) | NO | Linux RAPL: PKG + DRAM |
|
||||
| pfv-tsys3 | Precision 7510 (mobile WS), Xeon E3-1535M v5 (Skylake-H), CM236 | YES — AMT 11.x (patch post-CVE-2017-5689!) | NO | Linux RAPL: PKG (DRAM domain often absent on mobile SKL — verify) |
|
||||
| pfv-tsys4 | Precision T1700, Xeon E3-1246 v3 (Haswell), C226 | **NO AMT** — CPU is vPro-capable but C226 has no AMT ME stack (Haswell vPro needs Q87); no BMC either | NO | Linux RAPL: PKG + DRAM |
|
||||
| pfv-tsys5 | Precision T7500, Xeon E5620 (Westmere), 5520 chipset | NO — server-class chipset, pre-vPro era; no BMC | NO | **Nothing software-readable: Westmere has NO RAPL** (Sandy Bridge introduced it). Metered PDU / smart plug only |
|
||||
| pfv-tsys6 | PowerEdge R610, 2x E5530, iDRAC6 | NO AMT (servers = BMC) | **YES via iDRAC6** | `racadm getconfig -g cfgServerPower -o cfgServerActualPowerConsumption`; ipmitool sensor "System Level" (watts often x10). DCMI partial/absent on old firmware |
|
||||
| pfv-tsys7 | PowerEdge R620, 2x E5-2630 v2 (Ivy Bridge-EP), iDRAC7 | NO AMT (BMC) | **YES via iDRAC7** (full DCMI) | `ipmitool dcmi power reading`; `racadm getsysinfo -c`; plus host-side RAPL PKG+DRAM |
|
||||
| tsys9 | unknown (2013-17 OptiPlex/Precision) | Identify first: `dmidecode -t system` + `lspci \| grep -i MEI` + MEBx (Ctrl+P) | if AMT: still NO watts | RAPL if Haswell or newer |
|
||||
|
||||
## Practical pull methods
|
||||
|
||||
- **AMT 9.x/10.x/11.x (tsys1, tsys3):** WSMAN/SOAP via `wsman` CLI or
|
||||
MeshCommander (port 16993 TLS) — power state, on/off, KVM, inventory. AMT
|
||||
11.6+ also speaks Redfish at `https://<host>:16992/redfish/v1/` but with no
|
||||
Power telemetry resource.
|
||||
- **Local MEI/HECI discovery:** `/dev/mei0`, `intelmetool` — tells you whether
|
||||
AMT firmware is present/provisioned (use this for tsys9 triage).
|
||||
- **RAPL readers:** `turbostat` (most complete; PKG/cores/DRAM), powercap
|
||||
sysfs `/sys/class/powercap/intel-rapl:*` (poll `energy_uj`, delta/t = W),
|
||||
`perf stat -e power/energy-pkg/`. node_exporter has NO built-in RAPL
|
||||
collector — deploy a small rapl exporter or scrape turbostat. Caveat: RAPL
|
||||
measures CPU package (+DRAM), not whole-wall draw (~60-75% of wall on
|
||||
desktops).
|
||||
|
||||
## RAPL coverage by CPU generation
|
||||
|
||||
- RAPL introduced Sandy Bridge (2011); **Westmere (E5620) and Nehalem (E5530)
|
||||
have none — tsys5 and tsys6 hosts cannot RAPL.**
|
||||
- Haswell adds DRAM domain: tsys1 (i7-4770) and tsys4 (E3-1246 v3) get
|
||||
PKG+PP0+DRAM.
|
||||
- Skylake-H (tsys3): PKG yes, DRAM typically absent on mobile.
|
||||
- Ivy Bridge-EP (tsys7): PKG+DRAM.
|
||||
|
||||
## Recommendations
|
||||
|
||||
1. Don't chase watts via AMT anywhere — the capability does not exist. Use
|
||||
AMT (tsys1, tsys3) only for remote KVM/power control; patch tsys3's AMT 11
|
||||
firmware for CVE-2017-5689 before enabling.
|
||||
2. Uniform host-side telemetry = RAPL exporter on tsys1, tsys3, tsys4, tsys7.
|
||||
3. Servers (tsys6, tsys7): pull BMC watts out-of-band (racadm/ipmitool DCMI);
|
||||
update iDRAC6 firmware on tsys6 if DCMI commands fail.
|
||||
4. tsys5 (T7500): budget a metered PDU or smart plug — no software path
|
||||
exists (fits the planned UPS re-cabling: put tsys5 on the metered leg).
|
||||
5. tsys9 RESOLVED (2026-09-06): OptiPlex 7080, i5-10500, live PVE 9.2.5 node
|
||||
(100.101.158.76 — runs pfv-netinfra-02 + k8s wnode-tsys9); RAPL present —
|
||||
include it in the RAPL exporter wave.
|
||||
6. UPS plan alignment: since only tsys6/7 (BMC) + RAPL hosts give per-node
|
||||
watts, keep the metered UPS leg feeding the gear you most need wall-watts
|
||||
for; per-node software telemetry covers the rest.
|
||||
|
||||
## Sources
|
||||
|
||||
- Intel Community — AMT and power usage monitoring: https://community.intel.com/t5/Intel-Business-Client-Software/AMT-and-power-usage-monitoring/td-p/853085
|
||||
- Intel Community — AMT Support Identification: https://community.intel.com/t5/Intel-vPro-Platform/Intel-AMT-Support-Identification/td-p/1275668
|
||||
- DMTF Redfish Telemetry DSP2051: https://www.dmtf.org/sites/default/files/standards/documents/DSP2051_1.1.0.pdf
|
||||
- OptiPlex 9020 spec (AMT 9.x): https://www.dell.com/support/manuals/en-us/optiplex-9020-desktop/opt9020sffom-v2/specifications
|
||||
- Precision 7510 spec sheet: https://i.dell.com/sites/csdocuments/Shared-Content_data-Sheets_Documents/en/us/Dell-Precision-15-7000-Series-7510-Spec-Sheet.pdf
|
||||
- ARK E3-1246 v3: https://www.intel.com/content/www/us/en/products/sku/80916/intel-xeon-processor-e31246-v3-8m-cache-3-50-ghz/specifications.html
|
||||
- ServerFault Dell power CLI: https://serverfault.com/questions/736068/how-do-i-get-the-power-consumption-of-a-dell-poweredge-server-on-the-cli
|
||||
- jonamiki racadm power capping: https://jonamiki.com/2014/10/18/power-control-and-capping-on-dell-servers-using-racadm/
|
||||
- Dell InfoHub power reporting: https://infohub.delltechnologies.com/en-us/p/server-power-consumption-reporting-and-management/
|
||||
- Launchpad RAPL domains: https://bugs.launchpad.net/bugs/1467014
|
||||
- Hackenberg et al. Haswell RAPL survey: https://tu-dresden.de/zih/forschung/ressourcen/dateien/projekte/firestarter/2015_hackenberg_hppac.pdf
|
||||
- kernel mei/iamt docs: https://docs.kernel.org/driver-api/mei/iamt.html
|
||||
|
||||
> **Docs live on Discourse — this repo is the executable source of truth.** Perf topic: https://community.turnsys.com/t/328
|
||||
@@ -0,0 +1,73 @@
|
||||
---
|
||||
title: report-moonlight-desktop
|
||||
visibility: private
|
||||
---
|
||||
|
||||
# 🖼️ 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: 2–4 cores sustained @1080p60 | HIGH + WebRTC stack ~1 core | MODERATE (framebuffer diff, no video encode) | LOW–MODERATE (Guacamole ~15–27%/core per 1–2 users) | LOW |
|
||||
| Latency @36 ms RTT | Best-in-class on direct path; 100–200 ms if misconfigured | Low | Moderate; fine for desktop, visible on video | Moderate–high (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 2–4 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
|
||||
|
||||
- Intel Xeon Quick Sync support: https://www.intel.com/content/www/us/en/support/articles/000034104/processors/intel-xeon-processors.html
|
||||
- Sunshine advanced usage (encoder cost): https://docs.lizardbyte.dev/projects/sunshine/v0.23.0/about/advanced_usage.html
|
||||
- Moonlight setup guide: https://github.com/moonlight-stream/moonlight-docs/wiki/Setup-Guide
|
||||
- Tailscale DERP 5 Mbps gotcha: https://cfreeman.cloud/breaking-the-5-mbps-barrier-streaming-moonlight-over-tailscale-with-full-bandwidth/
|
||||
- LizardByte latency discussion: https://github.com/orgs/LizardByte/discussions/17
|
||||
- LXC headless Sunshine/uinput: https://discuss.linuxcontainers.org/t/headless-wayland-container-streaming-via-sunshine-sway-libinput-not-finding-uinput-devices/18852
|
||||
- steam-headless uinput issue: https://github.com/Steam-Headless/docker-steam-headless/issues/191
|
||||
- Selkies-GStreamer: https://github.com/selkies-project/selkies
|
||||
- Kasm desktop images: https://hub.docker.com/r/kasmweb/desktop
|
||||
- linuxserver/docker-webtop: https://github.com/linuxserver/docker-webtop
|
||||
- LSIO docker-kasm: https://docs.linuxserver.io/images/docker-kasm/
|
||||
- Guacamole web-client slowness: https://stackoverflow.com/questions/77224933/apache-guacamole-much-slower-on-the-web-client-than-microsoft-desktop
|
||||
- guacd CPU benchmarks: https://lists.apache.org/thread/zdlsnn2br4gvtx09q6zqtxym6dwlrjwc
|
||||
- Cendio on browser remote desktop limits: https://www.cendio.com/blog/apache-guacamole-alternatives/
|
||||
|
||||
> **Docs live on Discourse — this repo is the executable source of truth.** Perf topic: https://community.turnsys.com/t/328
|
||||
Reference in New Issue
Block a user