Control over cluster placement
In an HA cluster the manager decides which node to restart a VM on after a failure. Without hints it may place two VMs that should be separated side by side — or split apart those that must stay close.
HA rules give you that control declaratively. The config lives in /etc/pve/ha/rules.cfg under /etc/pve, so it is distributed to every node automatically — the whole cluster shares one consistent rule set. You can also set them in the UI: Datacenter → HA → Rules.
Affinity, anti-affinity and node affinity
- Node affinity — positive (the default) keeps a resource on the listed nodes; negative makes it avoid them. It replaces the old HA groups and is feature-compatible with them.
- Resource affinity (positive) — keep selected VMs on the same node (e.g. an app close to its database).
- Resource anti-affinity (negative) — spread VMs across different nodes, so a single host failure doesn't take down a whole redundant service.
Classic anti-affinity uses: two domain controllers, a pair of load balancers, replica nodes of the same database — always on separate hardware.
Hard and soft constraints
Node affinity rules are non-strict by default: if none of the listed nodes is available, the VM still starts elsewhere — availability wins. When the dependency is hard (e.g. a license tied to specific hardware, or local storage), use a strict rule — then the manager limits placement, recovery and migration to the rule's nodes only. If none of those nodes is available, the resource is stopped.
Resource affinity, including anti-affinity, is strict. If the rule cannot be met, HA does not start the VM on a node that would break it: on failover it leaves the resource in recovery, and otherwise in an error state.
The failback flag (on by default) moves the resource only to a node-affinity node with a higher priority than the current one. Equal priorities (the default is 0) leave the VM where it is. It's the successor of the old nofailback from HA groups, moved onto the HA resource.
From HA groups to rules
- Automatic migration — once every cluster node is on 9.x, old HA groups are converted to node affinity rules and the group assignment moves into the rule's "resources" field.
- Start with anti-affinity for redundant pairs — the biggest reliability gain for minimal effort.
- Strict only for node affinity — that rule is soft by default, and too many hard rules block failover. Anti-affinity is strict and will not start the VM when the rule cannot be met.
Affinity rules work together with the Dynamic Load Balancer — automatic balancing always respects your node and resource affinity rules.
We'll design HA rules for your cluster
We'll set up affinity, anti-affinity and node affinity to maximise service reliability after your VMware migration — in line with your SLA requirements.
⚡ Free consultation → Proxmox 9 vs 8 differences