Re: [PATCH pve-ha-manager 2/2] fix #7974: env: pve2: set dynamic service mem value to host memory usage

[Michael Ryom <Michael@RyomHerold.dk>]

On 28/08/2026 14:32, Dominik Rusovac wrote:
> Make memory accounting in dynamic CRS consistent.
>
> Atm the imbalance value that triggers rebalancing is derived from the
> guests' host memory usage, which corresponds to the respective host-side
> cgroup footprints of the guests. However, the scheduler's decision
> procedure predicts the changes in imbalance caused by migration
> candidates based on memory usage (inside the guests). This discrepancy
> can lead to oscillating migrations, as described in detail in [0].
>
> For VMs, host memory usage is the relevant stat, as it better describes
> the actual cost of running on a node than memory usage. Host memory
> usage is not available for containers, so fall back to memory usage for
> containers.

Ran into the same issue independently while deliberately stress-testing
CRS with ha=dynamic on a two-node PVE 9.2.20 cluster (pve-ha-manager
5.2.5): a single dominant VM with an active balloon driver was accounted
with mem = 6.94 GiB while its host-side footprint was ~8.15 GiB (QEMU
RSS 7,950,016 KiB). The ~1.2 GiB difference is the same order of
magnitude as the balancer's trigger condition on a small cluster, and
contributed to the VM being migrated back and forth - five moves in 27
minutes on an otherwise idle cluster, matching the oscillation described
in the bug report.

Tested an equivalent change (memhost with fallback to mem) on the same
cluster: the predicted post-migration imbalance now matches the measured
state, where it was systematically off by ~1-2 percentage points before.

Tested-by: Michael Ryom <Michael@RyomHerold.dk>

One note: with the memory accounting fixed, the oscillation shrinks but
does not fully disappear here. With a dominant resource on two nodes,
sub-percent fluctuations of the node base loads (ZFS ARC, Ceph daemons,
the IO of a rebalance migration itself) are still enough to qualify a
motion - and, once carried out, its reverse - since the relative margin
provides almost no hysteresis in that regime. I am about to send a
series addressing that (plus the endless retry of failing rebalance
migrations); one patch in it overlaps with this one, which I will note
there so whichever lands first wins.