Cannot migrate VM, because HA resource vm is not allowed

Nemesiz

Renowned Member
Jan 16, 2009
812
91
93
Lithuania
Hello,

I'm not sure which update caused this issue, but using HA Affinity Rules I can't migrate a VM to another node.

In migration dialog I see: Cannot migrate VM, because HA resource vm:121 is not allowed on the selected target node.

Using console


Code:
# qm migrate 121 nmz-cl-1 --online
Requesting HA migration for VM 121 to node nmz-cl-1
cannot migrate resource 'vm:121' to node 'nmz-cl-1':

- resource 'vm:121' not allowed on target node 'nmz-cl-1'
command 'ha-manager migrate vm:121 nmz-cl-1' failed: exit code 2

Code:
node-affinity: ha-rule-8156bb0b-7c8c
        comment #2 server
        nodes nmz-cl-1:1,nmz-cl-2:2,nmz-cl-3:1
        resources vm:121,vm:124,vm:172,vm:175
        strict 0

Bug?
 
can you get the output of

Code:
pveversion -v
?
So we know what proxmox version you are on.
 
Could it be related to this? https://github.com/proxmox/pve-ha-manager/commit/dc200f10963fcb7ca81ea05246ce69bf03117629

Code:
# pveversion -v
proxmox-ve: 9.2.0 (running kernel: 7.0.12-1-pve)
pve-manager: 9.2.3 (running version: 9.2.3/d0fde103346cf89a)
proxmox-kernel-helper: 9.2.0
proxmox-kernel-7.0: 7.0.12-1
proxmox-kernel-7.0.12-1-pve-signed: 7.0.12-1
ceph: 19.2.4-pve1
ceph-fuse: 19.2.4-pve1
corosync: 3.1.10-pve2
criu: 4.1.1-1
ifupdown2: 3.3.0-1+pmx12
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.1
libproxmox-backup-qemu0: 2.0.2
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.1.1
libpve-apiclient-perl: 3.4.2
libpve-cluster-api-perl: 9.1.6
libpve-cluster-perl: 9.1.6
libpve-common-perl: 9.1.16
libpve-guest-common-perl: 6.0.4
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.6.6
libpve-notify-perl: 9.1.6
libpve-rs-perl: 0.15.3
libpve-storage-perl: 9.1.6
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 7.0.0-2
lxcfs: 7.0.0-pve1
novnc-pve: 1.7.0-1
proxmox-backup-client: 4.2.2-1
proxmox-backup-file-restore: 4.2.2-1
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.2.3
proxmox-kernel-helper: 9.2.0
proxmox-mail-forward: 1.0.3
proxmox-mini-journalreader: 1.6
proxmox-offline-mirror-helper: 0.7.4
proxmox-widget-toolkit: 5.2.5
pve-cluster: 9.1.6
pve-container: 6.1.10
pve-docs: 9.2.2
pve-edk2-firmware: 4.2025.05-2
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.4
pve-firmware: 3.18-4
pve-ha-manager: 5.2.4
pve-i18n: 3.9.0
pve-qemu-kvm: 11.0.0-4
pve-xtermjs: 6.0.0-1
qemu-server: 9.1.18
smartmontools: 7.5-pve2
spiceterm: 3.4.2
swtpm: 0.8.0+pve3
vncterm: 1.9.2
zfsutils-linux: 2.4.2-pve1
 
I am having the same issue.

The only way to migrate the VM's is to set the Priorities the same in Datacentet > HA > Affinity rules. Which defeats the purpose of having priorities in the first place.


root@PVE01:~# pveversion -v
proxmox-ve: 9.2.0 (running kernel: 7.0.2-6-pve)
pve-manager: 9.2.2 (running version: 9.2.2/b9984c6d90a4bd80)
proxmox-kernel-helper: 9.1.0+fde2
proxmox-kernel-7.0: 7.0.2-6
proxmox-kernel-7.0.2-6-pve-signed: 7.0.2-6
ceph: 19.2.4-pve1
ceph-fuse: 19.2.4-pve1
corosync: 3.1.10-pve2
criu: 4.1.1-1
frr-pythontools: 10.6.1-1+pve2
ifupdown2: 3.3.0-1+pmx12
intel-microcode: 3.20251111.1~deb13u1
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.1
libproxmox-backup-qemu0: 2.0.2
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.1.1
libpve-apiclient-perl: 3.4.2
libpve-cluster-api-perl: 9.1.5
libpve-cluster-perl: 9.1.5
libpve-common-perl: 9.1.12
libpve-guest-common-perl: 6.0.3
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.6.5
libpve-notify-perl: 9.1.5
libpve-rs-perl: 0.15.3
libpve-storage-perl: 9.1.5
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 7.0.0-2
lxcfs: 7.0.0-pve1
novnc-pve: 1.7.0-1
proxmox-backup-client: 4.2.0-1
proxmox-backup-file-restore: 4.2.0-1
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.2.3
proxmox-kernel-helper: 9.1.0+fde2
proxmox-mail-forward: 1.0.3
proxmox-mini-journalreader: 1.6
proxmox-offline-mirror-helper: 0.7.4
proxmox-widget-toolkit: 5.2.2
pve-cluster: 9.1.5
pve-container: 6.1.10
pve-docs: 9.2.1
pve-edk2-firmware: 4.2025.05-2
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.4
pve-firmware: 3.18-3
pve-ha-manager: 5.2.4
pve-i18n: 3.7.4
pve-qemu-kvm: 11.0.0-3
pve-xtermjs: 6.0.0-1
qemu-server: 9.1.15
smartmontools: 7.5-pve2
spiceterm: 3.4.2
swtpm: 0.8.0+pve3
vncterm: 1.9.2
zfsutils-linux: 2.4.2-pve1
 
Error message is not that user friendly, the root cause is: VM is bind to a HA rule.
If you move it, it would be migrated back due to the rule, and as this does not make sense, the action is blocked.
You need to change HA assigment for moving.
 
It require to be upgraded. In node shutdown VM should be moved to another node by HA rule priority but it stays blocked.
 
This kind of error usually indicates that the HA scheduler doesn't recognize nmz-cl-1 as a valid target right now, even if it's included in the affinity rule. Here are a few things you might to check:
1. Ensure that nmz-cl-1 is listed in the HA resource's allowed node list (you can find this in the ha-manager configuration).
2. Confirm that the node is online, has quorum, and isn’t in maintenance mode.
3. Look to see if another HA rule or group is overriding your affinity rule.
4. Check if the HA configuration is consistent across all nodes (using ha-manager status).

Could you also share the output of `ha-manager config` and `ha-manager status`? That would really help figure out whether this is a configuration issue or if there’s something that went wrong with the latest update.
 
VM could exist only in one HA rule. It should be a bug.

# ha-manager config
vm:100
state started

vm:101
state started

vm:104
state started

vm:106
state started

vm:108
state started

vm:112
state started

vm:113
state started

vm:121
state started

vm:124
state started

vm:127
state started

vm:132
state started

vm:133
state started

vm:134
state started

vm:139
state started

vm:140
state started

vm:170
state started

vm:171
state started

vm:172
state started

vm:173
state started

vm:174
state started

vm:175
state started

vm:176
state started

vm:177
state started

vm:201
state started

# ha-manager status
quorum OK
master nmz-cl-2 (active, Tue Jul 14 12:52:05 2026)
fencing armed (CRM watchdog active)
lrm nmz-cl-1 (active, watchdog active, Tue Jul 14 12:52:06 2026)
lrm nmz-cl-2 (active, watchdog active, Tue Jul 14 12:52:04 2026)
lrm nmz-cl-3 (active, watchdog active, Tue Jul 14 12:52:09 2026)
service vm:100 (nmz-cl-1, started)
service vm:101 (nmz-cl-1, started)
service vm:104 (nmz-cl-1, started)
service vm:106 (nmz-cl-1, started)
service vm:108 (nmz-cl-1, started)
service vm:112 (nmz-cl-3, started)
service vm:113 (nmz-cl-3, started)
service vm:121 (nmz-cl-2, started)
service vm:124 (nmz-cl-2, started)
service vm:127 (nmz-cl-3, started)
service vm:132 (nmz-cl-1, started)
service vm:133 (nmz-cl-1, started)
service vm:134 (nmz-cl-1, started)
service vm:139 (nmz-cl-3, started)
service vm:140 (nmz-cl-1, started)
service vm:170 (nmz-cl-1, started)
service vm:171 (nmz-cl-1, started)
service vm:172 (nmz-cl-2, started)
service vm:173 (nmz-cl-3, started)
service vm:174 (nmz-cl-1, started)
service vm:175 (nmz-cl-2, started)
service vm:176 (nmz-cl-3, started)
service vm:177 (nmz-cl-1, started)
service vm:201 (nmz-cl-3, started)

# cat /etc/pve/ha/rules.cfg
node-affinity: ha-rule-8b976496-5b49
comment #1 server
nodes nmz-cl-1:2,nmz-cl-2:1,nmz-cl-3:1
resources vm:100,vm:101,vm:104,vm:106,vm:108,vm:132,vm:133,vm:134,vm:140,vm:170,vm:171,vm:174,vm:177
strict 0

node-affinity: ha-rule-aa656d35-af0a
comment #3 server
nodes nmz-cl-1:1,nmz-cl-2:1,nmz-cl-3:2
resources vm:112,vm:113,vm:127,vm:139,vm:173,vm:176,vm:201
strict 0

node-affinity: ha-rule-8156bb0b-7c8c
comment #2 server
nodes nmz-cl-1:1,nmz-cl-2:2,nmz-cl-3:1
resources vm:121,vm:124,vm:172,vm:175
strict 0
 
VM could exist only in one HA rule. It should be a bug.
Thanks for providing the details. The HA configuration looks consistent — VM 121 exists only in one node-affinity rule, quorum is OK, and all nodes are active.


Since nmz-cl-1 is explicitly listed in ha-rule-8156bb0b-7c8c and strict 0 is set, the migration refusal seems unexpected. It may be related to HA rule evaluation after the update.


You could try reloading the HA configuration or temporarily removing and recreating the affinity rule to see if the state refreshes. If the issue persists, it would be worth checking the Proxmox version and opening a bug report with the HA logs (/var/log/pve-ha-crm.log and /var/log/pve-ha-lrm.log).