Re: [PATCH cluster 1/5] add functions to determine warning level for high token timeouts

[Friedrich Weber <f.weber@proxmox.com>]

On 30/03/2026 16:46, Michael Köppl wrote:
> High token timeouts can lead to stability problems in clusters. To
> inform users about the timeout in their current setup (or expected
> timeouts when adding nodes) and give recommendations regarding the token
> coefficient setting, introduce function to calculate the timeout as well
> as determine the warning / recommendation levels.
> 
> Signed-off-by: Michael Köppl <m.koeppl@proxmox.com>
> ---
> The timeouts are chosen according to Friedrich's description in [0].
> 
> [0] https://bugzilla.proxmox.com/show_bug.cgi?id=7398
> 
>  src/PVE/Corosync.pm | 50 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 50 insertions(+)
> 
> diff --git a/src/PVE/Corosync.pm b/src/PVE/Corosync.pm
> index aef0d31..41d4c6f 100644
> --- a/src/PVE/Corosync.pm
> +++ b/src/PVE/Corosync.pm
> @@ -534,4 +534,54 @@ sub resolve_hostname_like_corosync {
>      return $match_ip_and_version->($resolved_ip);
>  }
>  
> +sub calculate_total_timeout {

I think "total timeout" is a little too vague, especially because it's
also user-facing. I don't think totem/corosync have a term for "sum of
token and consensus timeout", and "sum of token and consensus timeout"
is a too long. Perhaps something like "recovery timeout" -- though not
perfect because "Recovery" is a specific state in the totem state
machine. Maybe "membership convergence timeout" (though that's a bit
long and obscure)?

> +    my ($totemcfg, $node_count) = @_;
> +
> +    my $token_timeout = $totemcfg->{token} // 3000;
> +    my $token_coefficient = $totemcfg->{token_coefficient} // 650;
> +
> +    my $expected_token_timeout = $token_timeout;
> +    if ($node_count > 2) {
> +        $expected_token_timeout += ($node_count - 2) * $token_coefficient;
> +    }
> +
> +    my $expected_consensus_timeout = $totemcfg->{consensus} // $expected_token_timeout * 1.2;
> +    return ($expected_token_timeout + $expected_consensus_timeout) / 1000.0;
> +}
> +
> +sub get_timeout_warning_level {
> +    my ($total_timeout_secs) = @_;
> +
> +    if ($total_timeout_secs > 50) {
> +        return 'change-strongly-recommended';

I realize I'm the source of these numbers :) But since >50 is actually
pretty bad already, if we phrase it as "strongly recommended" we can
probably go for a slightly lower number:

- > 45: change-strongly-recommended
- > 40: change recommended
- > 30: optimize

> +    } elsif ($total_timeout_secs > 40) {
> +        return 'change-recommended';
> +    } elsif ($total_timeout_secs > 30) {
> +        return 'optimize';
> +    }
> +
> +    return undef;
> +}
> +
> +sub get_timeout_warning {
> +    my ($total_timeout_secs) = @_;
> +
> +    my $level = get_timeout_warning_level($total_timeout_secs);
> +    return undef if !defined($level);
> +
> +    my $level_msg;
> +    if ($level eq 'change-strongly-recommended') {
> +        $level_msg = "Changing the token coefficient is strongly recommended";
> +    } elsif ($level eq 'change-recommended') {
> +        $level_msg = "Changing the token coefficient is recommended";
> +    } elsif ($level eq 'optimize') {
> +        $level_msg = "Token coefficient can be optimized";
> +    }
> +
> +    return
> +        "Sum of Corosync token and consensus timeout is ${total_timeout_secs}s. "
> +        . "$level_msg. "
> +        . "See https://pve.proxmox.com/pve-docs/chapter-pvecm.html#_changing_the_token_coefficient for details.";
> +}
> +
>  1;