On Thu Nov 20, 2025 at 6:53 PM CET, Thomas Lamprecht wrote: > Am 03.11.25 um 16:18 schrieb Daniel Kral: >> When a HA resource with positive affinity to other HA resources is moved >> to another node, the other HA resources in positive affinity are >> automatically moved to the same target node as well. >> >> If the HA resources have significant differences in migration time >> (more than the average HA Manager round of ~10 seconds) the already >> migrated HA resources in 'started' state will check for better node >> placements while the other(s) are still migrating. > > >> This search includes whether the positive resource affinity rules are >> held and will query where the other HA resources are. When HA resources >> are still migrating this will report that these are both on the source >> and target node, which is correct from a accounting standpoint, but will >> add equal weights on both nodes and might result in the already started >> HA resource to be migrated to the source node. > > So, just to confirm, this does not change the accounting part at all, or? > > Patch looks OK to me in general though, but would like to recheck with > a slightly fresher mind tomorrow, maybe we could have a quick chat too > for clearing this up.
Correct, the accounting part does not change at all, which is separate from the resource affinity logic here. Essentially, this part goes through a HA resource's positive affinitive HA resources (this is a bit of a mouthful) and counts on which nodes these put load on, so we can determine the common node these HA resources should converge to. Before this change, a "still" HA resource counted its current node, while a moving HA resource counted its source and its target node. This change limits the moving HA resource to only count its target node. This is only possible now as before we couldn't make a distinction what was the source and target node in use (this part was introduced in the granular accounting series). Hope this clears it up a bit, I haven't found a better word for "positive affinitive HA resources" yet.. If there's something I can add here to make it clearer for others too, I'd be happy to. > >> >> Therefore, only consider the target node for positive affinity during >> migration or relocation to prevent this from happening. >> >> As a side-effect, two test cases for positive resource affinity rules >> will result in a slightly quicker convergence to a steady state as these >> now will get the information about the common target node sooner. >> >> Signed-off-by: Daniel Kral <[email protected]> >> --- >> src/PVE/HA/Rules/ResourceAffinity.pm | 6 ++-- >> .../log.expect | 25 +++-------------- >> .../log.expect | 28 +++++++++---------- >> .../README | 3 -- >> .../log.expect | 28 +++---------------- >> 5 files changed, 26 insertions(+), 64 deletions(-) >> >> diff --git a/src/PVE/HA/Rules/ResourceAffinity.pm >> b/src/PVE/HA/Rules/ResourceAffinity.pm >> index 4f5ffca5..9303bafd 100644 >> --- a/src/PVE/HA/Rules/ResourceAffinity.pm >> +++ b/src/PVE/HA/Rules/ResourceAffinity.pm >> @@ -517,8 +517,10 @@ sub get_resource_affinity { >> for my $csid (keys $positive->%*) { >> my ($current_node, $target_node) = $get_used_service_nodes->($csid); >> >> - $together->{$current_node}++ if defined($current_node); >> - $together->{$target_node}++ if defined($target_node); >> + # consider only the target node for positive affinity to prevent >> already >> + # moved HA resources to move back to the source node (see #6801) >> + my $node = $target_node // $current_node; >> + $together->{$node}++ if defined($node); >> } >> >> for my $csid (keys $negative->%*) { _______________________________________________ pve-devel mailing list [email protected] https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
