Overview

What runs on one M920q, how it is managed, and the memory ceiling behind both

A single Lenovo M920q runs the house: the smart home control plane, a one-node Kubernetes cluster, and the monitoring that watches both. Everything that follows comes back to that being one machine with 31Gi.

What shares the machine

That accounts for 27 of the 31Gi, less about 0.6GB of QEMU overhead the simple sum hides. What is left is a buffer, and it already has a claim on it further down.

The split that matters is not the memory but the placement: obs-01 is an LXC container on the hypervisor, not a pod in the cluster. It collects from the host, the hypervisor API, the network gear, the WAN probes and Home Assistant, and it holds the alerting — all from outside the cluster, so a cluster that is failing cannot take down the thing that would report it. Control and observation covers what that costs.

How it is managed

One repository holds most of it, and the directory a file sits in decides how it reaches the machine.

Only the upper path is a mechanism. The cluster converges on the repository whether or not anyone is watching. The lower one runs through a person, so nothing moves until someone decides it should, which makes the repository a record of intent there rather than a source of truth.

One layer is outside even that. The Proxmox host’s own configuration — storage, backup jobs, notifications — is in no repository at all. A change there is undetected and unrecorded, and the weekly image is the only copy of it.

Home Assistant is on neither path either. It is configured in its own interface, which is why nothing in this repository describes the state of the house.

The memory ceiling

Measured demand sits far below the allocation on both large rows: Home Assistant needs about 1.35GB of its 4GB, the cluster 4.7GB of its 18GB. Home Assistant could safely be cut to 3GB, and it is not, for two reasons. The gain would not change any decision — the buffer already clears the lower bound of what is planned for it. And the standing rule is that the house wins when something has to give, so taking memory back from it points the wrong way.

Reading those numbers took a detour worth repeating. From the hypervisor the Home Assistant VM looks 92% full, but most of that is page cache: KVM never hands back a page the guest has touched, so the host figure is a high-water mark rather than a requirement. Real demand only appears next to what the guest itself reports as available.

The buffer is about 4GB, and the camera stack planned next is estimated at 2–4GB. Those are close enough that adding it uses the headroom up, which is what makes the ceiling load-bearing rather than theoretical.

The order for giving memory back was fixed in advance rather than during an incident: the Hubble UI first — Cilium’s network-observability console, which the CLI can replace — then the retention window on the in-cluster Prometheus, then that Prometheus altogether, with the external one scraping directly in its place. All three cost visibility. None touch Home Assistant or a running workload.

Where to go next