Re: [RFC PATCH-SERIES cluster/ha-manager/manager/proxmox v3 0/6] clamp load imbalance to unit interval

["Dominik Rusovac" <d.rusovac@proxmox.com>]

thx for testing and reviewing this series 

will resolve the nits 

On Tue May 12, 2026 at 1:25 PM CEST, Daniel Kral wrote:
> On Thu Apr 30, 2026 at 1:48 PM CEST, Dominik Rusovac wrote:
>> # TL;DR
>> clamp load imbalance to value between 0 and 1, and display the value as
>> percentage in HA Status panel of PVE UI.
>>
>> NOTE: This needs a version bump for proxmox-perl-rs, because the changes in
>> proxmox-resource-scheduling need to be propagated through those bindings.
>>
>> # Details
>> The currently used load imbalance value is given as the so-called coefficient of
>> variation (CV), a value that may exceed 1. As such, the CV value alone lacks
>> meaning. A CV value of 0.0 means no imbalance, but what does a value of, say,
>> 1.7 mean?
>>
>> Relative to the number of nodes in a cluster, it is possible to determine the
>> upper bound of the CV value [0][1]. By dividing the CV value by its upper
>> bound, the load imbalance can be represented as a value that varies between 0
>> and 1. Expressing the CV as a percentage makes the concept of load imbalance
>> easier to interpret.
>>
>> # Summary of Changes
>> This series:
>> - represents load imbalance as a value between 0 and 1;
>> - adds a maximum value of 1.0 for load scheduler options; and
>> - integrates the load imbalance value within the HA status endpoint;
>>   this is to provide feedback on the prevailing load imbalance in the PVE UI.
>>
>> # Refs
>> [0] https://repositorio.ipbeja.pt/server/api/core/bitstreams/8ed9a444-dbe0-402f-9d2f-90c5bf6e418c/content
>> [1] https://stats.stackexchange.com/questions/18621/maximum-value-of-coefficient-of-variation-for-bounded-data-set
>
> I'm running this patch series on my 3-node test cluster. I tested this
> by inducing a few imbalance spikes for a couple of rounds with some
> build jobs running and letting the cluster stay mostly idle for a while.
>
> Works good for me so far, which is to be expected since this should only
> be a mapping to the unit interval. It's also very helpful to be able to
> look at the most recent load imbalance, thanks for the series!
>
> Besides the two small nits, I wonder if we should change the default
> imbalance threshold value of 0.3 as with these patches applied the
> behavior of the load balancer changes and makes the trigger more
> insensitive by default.

good point. we should give this a thought and adjust it in a follow-up

>
> For example, for the smaller cluster sizes:
>
>     >>> [(0.3/math.sqrt(n-1), math.sqrt(n-1)) for n in range(2,10)]
>     [
>         (2, 0.3, 1.0),
>         (3, 0.21213203435596423, 1.4142135623730951),
>         (4, 0.17320508075688773, 1.7320508075688772),
>         (5, 0.15, 2.0),
>         (6, 0.13416407864998736, 2.23606797749979),
>         (7, 0.12247448713915891, 2.449489742783178),
>         (8, 0.11338934190276816, 2.6457513110645907),
>         (9, 0.10606601717798211, 2.8284271247461903)
>     ]
>
> Though this could be done as a follow-up to this series.
>
> Otherwise, consider the patches (with the nits resolved) as:
>
> Reviewed-by: Daniel Kral <d.kral@proxmox.com>
> Tested-by: Daniel Kral <d.kral@proxmox.com>