From: "Daniel Kral" <d.kral@proxmox.com>
To: "Thomas Lamprecht" <t.lamprecht@proxmox.com>,
"Proxmox VE development discussion" <pve-devel@lists.proxmox.com>,
"Daniel Kral" <d.kral@proxmox.com>
Subject: Re: [pve-devel] [PATCH ha-manager 2/2] fix #6801: only consider target node during positive resource affinity migration
Date: Mon, 24 Nov 2025 10:11:27 +0100 [thread overview]
Message-ID: <DEGT4FQLQ1VR.MIKHHMA5FZMT@proxmox.com> (raw)
In-Reply-To: <1bf34a63-00ed-4a09-9c10-dfc166b9c256@proxmox.com>
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 <d.kral@proxmox.com>
>> ---
>> 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
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2025-11-24 9:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-03 15:17 [pve-devel] [PATCH ha-manager 0/2] fix #6801 Daniel Kral
2025-11-03 15:17 ` [pve-devel] [PATCH ha-manager 1/2] test: add delayed positive resource affinity migration test case Daniel Kral
2025-11-03 15:17 ` [pve-devel] [PATCH ha-manager 2/2] fix #6801: only consider target node during positive resource affinity migration Daniel Kral
2025-11-20 17:53 ` Thomas Lamprecht
2025-11-24 9:11 ` Daniel Kral [this message]
2025-11-18 16:49 ` [pve-devel] [PATCH ha-manager 0/2] fix #6801 Michael Köppl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DEGT4FQLQ1VR.MIKHHMA5FZMT@proxmox.com \
--to=d.kral@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=t.lamprecht@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox