VM Freez nach Migration

[Winet.maier]

Das betraf aber nur Rückwärtsmigration, i.e. von einer neueren Version zu einer älteren. Und es müsste QEMU 8.2 installiert gewesen sein, weil QEMU 9.0 hatte den Fix schon als es öffentlich ausgerollt wurde. Und das Feature muss im Gast aktiv sein und ist relativ neu in Linux, ich würde bezweifeln, dass es in CentOS 6 aktiv ist.

Das ist schon so, nur gingen die VM's, die gecrasht sind, eben auch nicht mehr zurück mit der Fehlermeldung: update the hypervisor. End of the Day bleiben viele Worte ein Haufen Arbeit und keine befriedigende Lösung und ein ungutes Gefühl.

 

[Winet.maier]

Wir dachten zuerst, dass das Problem mit dem Update aller Host's gelöst sei. Leider ein Trugschluss. Mir verrecken nach wie vor VM's mit Centos 6.x beim Migrieren. Langsam, aber sicher gehen uns hier die Ideen aus.

 

[Falk R.]

Siehst du irgendwelche Meldungen im Log? Was passiert wenn du per ssh auf einer solchen VM bist?
Hast du mal gecheckt ob bei den VMs der SCSI Timeout anders konfiguriert ist? Das kann zu RO Dateisystemen und somit Abstürzen führen.

 

[Winet.maier]

Siehst du irgendwelche Meldungen im Log? Was passiert wenn du per ssh auf einer solchen VM bist?
Hast du mal gecheckt ob bei den VMs der SCSI Timeout anders konfiguriert ist? Das kann zu RO Dateisystemen und somit Abstürzen führen.

Die SSH-Session stirbt genau in dem Moment, wo die VM's auf dem neuen Host freigegeben wird. Das mit dem SCSI muss ich mal schauen. Das grosse Problem ist, dass ja nur etwa 40% der VM's mit Centos 6.x betroffen sind und nach einem Stop und Start normal funktionieren. Es scheint wuch etwas mit dem Host zu tun zu haben, auf welchem sie gestartet wurden.

 

[Falk R.]

Habt ihr alle Bioseinstellunge gecheckt auf den Hosts? Ich hatte mal ähliche Probleme mit EsXi und da waren unterschiedliche Optionen bei CPU und Memory eingestellt.

 

[Winet.maier]

D

Habt ihr alle Bioseinstellunge gecheckt auf den Hosts? Ich hatte mal ähliche Probleme mit EsXi und da waren unterschiedliche Optionen bei CPU und Memory eingestellt.

Dagegen spricht, dass die Systeme seit zwei Jahren einwandfrei funktionieren. Und Du weisst ja, never touch a running system.

Was wir in letzter Zeit geändert haben, ist, dass wir die AMD Epic 32 Core durch 64 Core ersetzt haben. Das IPMI zeigt jedoch alles in Grün an.

 

[Falk R.]

Das IPMI kennt keine BIOS Einstellungen und gerade bei den AMD CPUs wurden einige neue Features erst mit dem 6.8er Kernel implementiert.
Natürlich lief das vorher mit älterem Kernel, ohne die neuen Features.

 

[Winet.maier]

Das IPMI kennt keine BIOS Einstellungen und gerade bei den AMD CPUs wurden einige neue Features erst mit dem 6.8er Kernel implementiert.
Natürlich lief das vorher mit älterem Kernel, ohne die neuen Features.

Ist mir auch klar. Habe nur mal die Versionen verglichen - und eben vorher gings ja auch mit 8.2.2 konnte ich in alle Richtungen migrieren und es hat immer funktioniert.

 

[Winet.Oldenbuerger]

Hallo zusammen,

Ich habe mich auch mal ein wenig mit dem Problem beschäftigt. Mittlerweile ist der Cluster aus 3 sehr identischen Nodes auf Proxmox
8.2.7 aktualisiert. Leider besteht noch immer eine nicht vorhersehbare Chance, das bestimmte VMs crashen, wenn sie live migriert werden.

Ich habe meine ersten Tests mit einer frischen CentOS-7-x86_64-DVD-2009 VM mit nichts anderem als einem guest-agent zur Minimal-Installation
gemacht. Dies mit der Absicht, CentOS 6.3 als altes OS auszuschliessen oder eben nicht.

• Beim ersten Erstellen der VM habe ich dazu die CPU x86-64-v3 gewählt. Das Migrieren dieser VM war problemlos möglich.
• Das Problem, das bei ungleichem Versionsstand der Nodes das Migrieren nicht möglich war, lag einzig an der Mainboard-Emulation
  • -machine type=pc-i440fx-9.0+pve0 vs -machine type=pc-i440fx-8.0+pve0
  • Grund: Unterschiede im kvm-Paket, das beim Update von Proxmox 8.2.2 auf Proxmox 8.2.7 einen Sprung von 8.x auf 9.x macht.
  • Default im GUI ist "latest", damit wird zum neuen Node hin Migration im Startkommando auf 9.0 gesetzt und kann nicht live zurück
  • Pinning auf 8.0 (der vmtl bis 8.2) löst das Problem
• Als nächsten Schritt habe ich die CPU auf kvm64 gestellt, da gefühlt ausschliesslich VMs mit dieser CPU Emulation crashen
• Die CentOS 7 VM wurde mit der kvm64 CPU hochgefahren und crashte beim ersten Migrationsversuch genauso, wie die bisherigen CentOS6.3
  • Details aus ps aux vor dem Migrieren: -cpu kvm64,enforce,+kvm_pv_eoi,+kvm_pv_unhalt,+lahf_lm,+sep
  • pc-i440fx-9.0 oder pc-i440fx-8.0 machen keinen Unterschied (Nodes zum Testzeitpunkt 2x 8.2.7 und 1x 8.2.2)
• Verhalten beim Crash wie schon beschrieben: VM wählen, Migrate, auf anderen Node -> Migration läuft, Im Summary wechselt der Text von "migrate" auf "started", einen "Update-Tick" des GUIs später CPU auf >100%, guest-agent not running und VM nicht mehr funktional.
• "Hard reset" via NoVNC startet die VM korrekt neu.
• Manchmal geht das Migrieren der VM auch gut.
• Es gibt keinen Logfile-Hinweis innerhalb der VM oder ausserhalb, die ich zu dem Crash finden konnte. Die Logs in der VM sahen genauso aus, als ob genau das passiert ist, was ich getan habe: Einen Hard-Reset einer laufenden VM durchführen. DIe Logs ausserhalb sahen genauso aus wie bei erfolgreich live-migrierten VMs.
• Herunterfahren der VM, Wechsel des CPU Types auf x86-64-v2-AES (weil die Mehrheit der VMs, die nicht kvm64 sind, auf dem Cluster so laufen), hochfahren und test-migrieren zwischen verschiedenen Nodes erzeugte bisher in einer Testmenge keinen einzigen Crash
• Da auch nach Abschluss der Updates auf 8.2.7 das Problem weiter besteht, ist der aktuelle Plan, alles von kvm64 auf x86-64-v3 umzustellen. Diese CPU hat nach einfachen Tests für die CentOS 6.3 VMs kein Problem dargestellt, auch wenn sie als Auswahl zum Zeitpunkt des Erstellens nicht existierte.

Das Vorgehen mit dem Wechsel des CPU Type wird zwar nach aktuellem Wissensstand die Symptome beheben, aber ist eigentlich keine Lösung, die das Problem an sich behebt.

 

[Winet.Oldenbuerger]

Hallo nochmal,

Ich möchte noch ein kurzes Feedback geben. Wir haben nun alle betroffenen VMs mit kvm64 CPU Type per Script*) heruntergefahren, CPU Type gewechselt und wieder hochgefahren.

Bislang trat damit das Problem nicht wieder auf. Auch wenn der tatsächliche Grund nicht wirklich eindeutig identifiziert werden konnte, scheint
die Lösung bisher ein guter Work-Around zu sein.

Ich hoffe das hilft später mal einem armen Techniker, der vor demselben Phänomen sitzt


*) >300 VMs in der GUI stoppen, umstellen und starten, und immer die Wartezeiten aussitzen, ist nicht wirklich schön, aber zum Glück gibt es ja die Proxmox API.