mirror of
https://github.com/adminsyspro/proxcenter-ui.git
synced 2026-04-25 14:35:56 +03:00
[GH-ISSUE #55] [Bug]: Affinity Rules #65
Labels
No labels
bug
enhancement
feature-request
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/proxcenter-ui#65
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @nothing-fr on GitHub (Mar 2, 2026).
Original GitHub issue: https://github.com/adminsyspro/proxcenter-ui/issues/55
Bug Description
Hello,
We are currently testing the solution and our initial impressions are very positive, however, we are encountering some issues with affinity rules.
Perhaps the problems we are encountering are simply due to a misunderstanding on our part. Is there any documentation available to provide Proxmox administrators with more guidance?
What's the difference between those two ? :
Orchestration > DRS > AffinityCLUSTER NAME > HAWhat is the best method to create affinity rules ?
Steps to Reproduce
Orchestration > DRS > Affinitythen create affinity rulesOrchestration > DRS > Affinitythen disable an existing affinity rule (it disappear)CLUSTER NAME > HAan error is occuring when creating a rule.Expected Behavior
Working affinity rules within ProxCenter
Actual Behavior
Orchestration > DRS > Affinity) do not seem to be taken into account and disappear when they are disabled...CLUSTER NAME > HAand creating a resource affinity rule, we get the following error:ProxCenter Version
acc3864Proxmox VE Version
9.1.5
Browser
Google Chrome Version 145.0.7632.116 (Build officiel) (64 bits)
Logs / Screenshots
No response
@adminsyspro commented on GitHub (Mar 2, 2026):
Hi, thanks for the detailed report and for testing ProxCenter!
Both bugs are now fixed
Bug 1: DRS Affinity rules disappear when disabled
This was a backend issue — toggling a rule's enabled/disabled state was sending a partial update that overwrote the entire rule record in the database, causing the rule to lose its connection ID and effectively vanish. The backend now properly merges only the changed fields onto the existing rule before saving.
Bug 2: HA Rules creation fails with
stateproperty errorThe PVE 9 API expects a
disableparameter (0or1), not astateproperty (enabled/disabled). This has been corrected in both the creation and update flows.About the difference between DRS Affinity and HA Rules
Good question — these serve different purposes:
For most users, DRS Affinity rules are the recommended approach as they offer more flexibility and work with ProxCenter's intelligent scheduling. HA rules are useful if you want PVE-native enforcement at the HA level.
Documentation covering all of this is currently being written.
@nothing-fr commented on GitHub (Mar 2, 2026):
Orchestration > DRS > Affinity: Disabling rule, do not make it disappear anymorebut still, doing nothing. My VMs in DRS Full Auto mode are on the same host:
Cluster > HA > Affinity Rules: Now everything works fine ! I can manage proxmox native rules.Another thing I don't understand, is the use of proxmox tags for the affinity rules :
Those names are not allowed in proxmox :
@adminsyspro commented on GitHub (Mar 2, 2026):
Thanks for the follow-up and the screenshots.
DRS Anti-Affinity not triggering migrations
You're right in the previous version, affinity rules were stored in the database but not wired into the DRS evaluation engine. The rules were displayed in the UI but the DRS had no awareness of them when generating recommendations.
This is now fixed: the DRS engine loads all affinity rules (both manual and tag-based) before each evaluation cycle, detects violations, and generates migration recommendations accordingly. Additionally,
enforce_affinityis now enabled by default, meaning the load-balancer will also respect your rules and never move a VM to a node that would violate an affinity or anti-affinity constraint.This fix will be included in the next release.
Tag names in Proxmox
Good catch on the confusion what you see in ProxCenter's UI (e.g.
Tag: affinity/web) is the display name of the auto-generated rule, not the actual tag to set in Proxmox.The tags to apply on your VMs in PVE are:
pxc_affinity_groupnamepxc_anti_affinity_groupnamepxc_pin_nodenamepxc_ignoreFor example, to keep two web servers apart, add the tag
pxc_anti_affinity_webto both VMs in the Proxmox UI. ProxCenter will automatically detect them and create the corresponding rule.These tags use only lowercase letters, digits, and underscores — which are all valid characters in PVE 8 and PVE 9.
We'll improve the UI to make this clearer (show the actual PVE tag alongside the rule name). Documentation is also on the way.
@nothing-fr commented on GitHub (Mar 3, 2026):
There was a little misunderstanding about that. Actually, I was copying and pasting tags, and there must have been some strange characters in them. When I retyped the tags, “pxc_anti_affinity_test” for example, it worked and appeared correctly in ProxCenter:
And it's now working :
But it was only a recommandation, it was not Automatic even with DRS in Full Auto., like this example :
Or maybe I'm missing something ? Do I have to wait 1h to check if DRS does it by itself ?
FYI, I also noticed that adding tags on VMs works (1), but deleting them does not (2):
@adminsyspro commented on GitHub (Mar 3, 2026):
Tag deletion fix
The tag deletion issue is now fixed. The bug occurred when removing the last tag from a VM: the frontend was sending
tags=(empty string) to Proxmox, which silently ignores an empty value. Proxmox requiresdelete=tagsto actually clear the field. This is corrected in the latest release.DRS Full Auto — how it works
Looking at your orchestrator logs, DRS Full Auto is working correctly:
The migration was automatically triggered ~39 seconds after the evaluation. The recommendation you saw in the UI was briefly in
pendingstate during that window — in Full Auto mode, the DRS engine approves and executes it on the next evaluation cycle (default: every few minutes), not instantly.So to answer your question: you don't need to wait 1 hour — in Full Auto mode, violations are resolved within one evaluation cycle after detection. The UI recommendation disappears once the migration completes and the next refresh runs.
@nothing-fr commented on GitHub (Mar 3, 2026):
The logs are OK because I clicked on the
execute allbutton and it was a simple case.However, if I let DRS do its thing, it doesn't seem to migrate anything... plus I'm seeing some strange behavior:
I have an anti-rule on three machines:
but I have four nodes... it seems to get confused and loop in the recommendations:
Clicking on one of the two does:
then disappears before reappearing...
Logs :
The ERR logs seem to appear when I click on one of the two recommendations.(screenshot above)
DRS still does not move virtual machines on its own... No operation is triggered on the Proxmox side :
@nothing-fr commented on GitHub (Mar 3, 2026):
I saw the latest update, it seems to fix the problem... now everything seems to be working correctly on our end, with the automatic movement of VMs!
Nice job ! 🥇