ha Bug in 9.2.10?

[fertig]

Hallo zusammen,

ich teste aktuellin einem 2-Node-Stretch-Cluster unter Proxmox VE 9.2.10 und habe Problem mit einer HA Node-Affinity Rule

Folgende Rule ist konfiguriert:

node-affinity: preferred-pve-clt
        nodes pve-clt:100,pve-tci:50
        resources vm:100,vm:4002
        strict 0

Laut meinem Verständnis sollte strict 0 bedeuten, dass beide Nodes erlaubt sind und lediglich pve-clt bevorzugt wird.

Die VM ist als HA-Ressource registriert:

ha-manager config

vm:4002
        failback 1
        state started

Versuche ich nun eine HA-Migration auf den zweiten Node, erhalte ich:

ha-manager crm-command migrate vm:4002 pve-tci

cannot migrate resource 'vm:4002' to node 'pve-tci':
 
- resource 'vm:4002' not allowed on target node 'pve-tci'

qm migrate 4002 pve-tci --online

da dieser Aufruf intern über den HA-Manager geht.

Interessant ist:

• Deaktiviere ich die Rule, funktioniert die Migration sofort.
• Setze ich die Gewichte auf 100/100, funktioniert die Migration ebenfalls.
• Verwende ich 100/50, wird die VM nach kurzer Zeit sogar automatisch zurück auf den bevorzugten Node verschoben.
• Es existieren keine HA-Gruppen.
• Die Storages sind Shared Storage (shared 1) und auf beiden Nodes verfügbar.

Daher wirkt es auf mich so, als würde die Rule bei ungleichen Gewichtungen trotz strict 0 wie eine harte Node-Bindung behandelt werden.

Ist dieses Verhalten so beabsichtigt oder könnte das ein Bug in der Auswertung der neuen Node-Affinity Rules sein?

Versionen:

pve-manager: 9.2.10
pve-ha-manager: 5.2.5



LG
Christian

 

[Bu66as]

Das ist die Prioritäts-Semantik aus den alten HA-Gruppen, die bei den Node-Affinity-Rules 1:1 übernommen wurde. strict 0 heißt nur, dass Nodes außerhalb der Rule im Notfall noch erlaubt sind. Die Zahlen innerhalb der Rule bilden trotzdem Stufen: solange pve-clt mit 100 online ist, ist das die einzige aktive Stufe, pve-tci mit 50 ist Fallback-Ebene und gilt als "not allowed". Deshalb geht 100/100 (beide in derselben Stufe) und 100/50 eben nicht.

Das automatische Zurückschieben ist dann failback 1 an der Ressource, das war früher nofailback=0. Wenn du frei hin und her schieben und die VM auch drüben lassen willst: beide Nodes auf die gleiche Prio und failback 0 setzen. Unterschiedliche Prios nur, wenn du wirklich willst dass die VM von allein wieder heim wandert.

Ob der harte Reject bei einer manuellen Migration so gewollt ist, ist die andere Frage. Bei nem geplanten Node-Reboot ist das schon unschön, für sowas gibts zwar den Maintenance-Mode, aber intuitiv ist es nicht. Würd ich an deiner Stelle mal im Bugzilla als Verbesserungsvorschlag aufmachen und hier verlinken.

 

[fertig]

Ob der harte Reject bei einer manuellen Migration so gewollt ist, ist die andere Frage. Bei nem geplanten Node-Reboot ist das schon unschön, für sowas gibts zwar den Maintenance-Mode, aber intuitiv ist es nicht.

ok, da der node reboot den maintenance mode triggert funktioniert das (gerade getestet). VMs werden verschoben. Aber so ist das wirklich nicht intuitiv. Für mich war strict=1 immer ein "ich verbiete es Dir aber trotzdem", während strict=0 eben suggeriert hat "mach halt, im Zweifel schiebe ich es zurück".