- Shipped
- 30 Agosti 2026, 20:54 UTC
- Author
- Kamo
- Commit
- c7a6412
The blank white page was the VM out of memory. 16Gi of guest RAM with NO swap means "out of memory" goes straight to the OOM killer: applications die mid-work, and this time the whole guest became unresponsive — including the provisioning agent. That reaches further than the VM, because SecurityService preflights that agent before minting a KamoDesktop link, so a wedged VM turned every launch into a blank browser tab: the tab opens blank and only navigates once a link comes back, and no link ever came. More RAM is not available — k1m1 is already ~86% allocated, so the memory does not exist to give. A 64G swap file is, and it is the difference between "slow for a moment" and "your editor is gone". vm.swappiness=10, deliberately: this swap sits on a Longhorn volume replicated over the network, so it is much slower than local disk and must be a safety net rather than a routine tier. The default 60 would page out idle desktop applications to make room for cache, over the network, which is exactly the wrong trade here. The script refuses to build the file if the space is not there — filling the root filesystem to make swap would trade a memory problem for a disk-full one, which is worse and harder to undo. Verified idempotent by running it against the already-configured VM: it reported "already active at 64G" and changed nothing. Also adds KamoDesktopAccessFlapping. KamoDesktopAccessBroken needs ten UNBROKEN minutes of failure, and this outage never failed that long in one stretch — the agent answered some probes and not others — so access was badly broken for the person trying to use it while the alert stayed quiet. Intermittent is not fine; half a working desktop is a broken one.