Add sensors to detect memory pressure for VMs / LXCs

[freeDom-]

In Linux environments RAM used / free values are often relatively uninteresting. It would be more interesting to report the value of the available memory instead. A problem (probably why this is not even shown on the PVE UI) is that I do not think that Windows VM's could provide such a value. Another (OS independent) approach could be providing the pressure values (memory pressure stall, IO pressure stall, CPU pressure stall).

Background: Linux typically reserves almost everything it can get of the RAM and correctly shows it as RAM used. Nevertheless, one typically wants to detect if a VM requires more RAM, because it is under RAM pressure. Therefore, the RAM available value is more interesting, because it tells how much of the reserved RAM can be freed within short time by the OS and therefore is available for applications.

[mZ738]

Both pressure groups are in 5.3.0: six sensors per VM and container — CPU pressure, IO pressure, Memory pressure and their … stalled counterparts — each the share of the last ten seconds in which at least one task waited for that resource, or every task did. Proxmox reports them on a read the integration already makes, so they cost nothing extra. Diagnostic and disabled by default; enable the ones you want on the guest's device page. Memory used on host came along for VMs: what the guest costs the host, which is more than what it reports using.

One thing to know before you read them: for a container these are its own cgroup, so they are what the workload experiences — which is what you asked for. For a VM they are measured on the host for that VM's process, so they say the host is stalling for that VM rather than what the guest OS sees. That is also why they work for a Windows guest.

The available memory inside the guest I did not build, and I would rather say so than half-build it: the API has nothing for it. In a VM it would take agent/exec on /proc/meminfo — the integration running commands in your guests, with a privilege I do not want to ask anyone for — and a container has no equivalent at all; its mem is the cgroup's usage, cache included.

If you try it, I would like to know whether the values match what cat /proc/pressure/memory says inside one of your containers — mine are near zero, which is not much of a test.

[freeDom-]

I am more then happy if the pressure sensors are exposed in a future release, as it suits my monitoring purposes and is a common interface. Thats of course a way better solution than accessing the available memory.

[freeDom-]

If it helps I can check later what my LXCs report in /proc/pressure/memory

For one I got these values, but currently I cannot verify if they are plausible. Therefore I would need to put some pressure on the LXC:

some avg10=0.00 avg60=0.00 avg300=0.00 total=35474084
full avg10=0.00 avg60=0.00 avg300=0.00 total=34048185

[mZ738]

It is out already — 5.3.0, released a few minutes ago. The sensors are diagnostic and disabled by default, so enable the ones you want on the guest's device page.

Your numbers line up with what the sensor carries: Proxmox exposes exactly the avg10 values, so some avg10=0.00 is what you should see in Home Assistant at rest — which your paste already confirms for the idle case. total is not in the API, only the three averages, and of those Proxmox passes on the ten-second one alone.

If you want a real check, the thing to watch out for is the sampling window: the sensor is only as fresh as the polling interval, 60 seconds by default (30 is available under Advanced configuration). So either hold the pressure for longer than one interval, or force a read with homeassistant.update_entity on the sensor right after. Something like this inside the container, which will run into its memory limit rather than the host's:

apt install stress-ng
stress-ng --vm 2 --vm-bytes 90% --timeout 90s

and watch -n1 cat /proc/pressure/memory next to it. If the two disagree by more than the window explains, I would like to hear about it — a container reports these values as strings where a VM sends numbers, so a parsing surprise is not impossible.