Live Migration auf 7.2.4 CPU 100% FREEZE

Wir haben das Problem auch. Bei uns scheint ein Upgrade auf pve-qemu-kvm: 6.2.0-8 (aus pve-test, da sind aktuell keine anderen Upgrades drin im vgl. zum Nosub-Repo) geholfen zu haben.
 
  • Like
Reactions: fettfoen
Sourcenux said:
Wir haben das Problem auch. Bei uns scheint ein Upgrade auf pve-qemu-kvm: 6.2.0-8 (aus pve-test, da sind aktuell keine anderen Upgrades drin im vgl. zum Nosub-Repo) geholfen zu haben.
Click to expand...
Bindest du einfach das Test Repo ein und installiert dann die neuere "pve-qemu-kvm" über die bereits installierte?
 
Ja, Repo rein und apt update && apt dist-upgrade.


Edit: siehe nächster Post.
 
Last edited:
Moin,

wenn wir unsere Xeon(R) Gold 6126 Hosts mit dem Kernel pve-kernel-5.15.30-2-pve: 5.15.30-3 booten, dann funktioniert die Migration wieder in alle Richtungen. Wir haben ein Ticket bei proxmox und das dort kommuniziert, es könnte also eine Lösung geben.

Interessant ist die Info oben, dass pve-qemu-kvm auf testing _auch_ hilft... Irgendwie seltsam das alles.
 
pveadmin said:
Moin,

wenn wir unsere Xeon(R) Gold 6126 Hosts mit dem Kernel pve-kernel-5.15.30-2-pve: 5.15.30-3 booten, dann funktioniert die Migration wieder in alle Richtungen. Wir haben ein Ticket bei proxmox und das dort kommuniziert, es könnte also eine Lösung geben.

Interessant ist die Info oben, dass pve-qemu-kvm auf testing _auch_ hilft... Irgendwie seltsam das alles.
Click to expand...
spricht dafuer dass es vielleicht einfach zwei probleme mit aehnlichen symptomen sind. das pve-qemu-kvm paket behebt auf jeden fall einen bug in der interaktion von qemu und librbd, das in solchen setups zu reduzierter performance (bis hin zu blockierenden VMs) fuehren kann.
 
Hallo,

ich hab das Problem nun nach dem Update auf 7.2 auch nachvollziehen können. Migration von qemu-6.2 VMs auf "ältere" CPUs führen zu sehr langsamen bis komplett hängenden VMs bei 100% CPU der VM. Ich hatte noch 4 Hosts auf dem 5.13er Kernel bei denen der reboot noch offen war -> gleiches Problem. Auf einer Maschine mit alter CPU und 6.2er qemu habe ich ein downgrade auf pve-qemu-kvm 6.1.1-2 gemacht und danach eine noch laufende VM im qemu 6.1.1er Format von einem Host mit Skylake auf den alten Host mit Sandybridge migriert -> geht. Sobald pve-qemu-kvm auf 6.2 springt, ist das Problem da. Datastores sind rein NFS. Wenn ich einen Memtest (x86) boote auf der VM und dann migriere, klemmt es nicht. Testweise habe ich nun noch auf einem anderen Cluster das Problem nachgestellt. Gleicher PVE-Stand (7.2-4 Stand no-subscription 30.5. 12:30) und dort eine Maschine von Alt (Nehalem) nach Neu (Sandybridge) und wieder zurück migriert. Keine Probleme. Bei Cascade Lake -> Sandybridge friert mir die VM direkt wieder mit 100% CPU ein.

Das Verhalten hört sich exakt wie hier an:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831761

Nur das die CPU kein tsc_scale besitzt. Sowohl unter qemu 6.1 und qemu 6.2 wird in der VM der gleiche Set an CPU-Flags angezeigt. Nächster Test war dann: VM auf PVE 7.2-4 mit qemu 6.1.1 gestartet (Skylake) -> migriert nach PVE 7.2-4 mit qemu 6.2.8 (Sandybridge), VM läuft -> migriert nach PVE 7.2-4 qemu 6.2.8 Cascade Lake, VM läuft -> migriert nach PVE 7.2-4 qemu 6.2.8 Sandy Bridge (gleicher Host wie Schritt 2), VM ist tot.

Alktueller Stand: Kernel 5.13 funktioniert mit qemu 6.2.0-8 und Migration zwischen moderneren CPUs runter auf SandyBridge. Auf älteren Systemen (Sandybridge/Nehalem) funktioniert die Migration auch mit dem 5.15er Kernel.

Gruß,

Heiko.
 
Last edited:
  • Like
Reactions: fettfoen
Moin, ich habe hier ähnliche Probleme, seit dem letzten Update gibt es die gleichen Auswirkungen wie hier beschrieben und etwas extra. Der Cluster besteht aus insgesamt 8 Hosts, HA Group AMD 2x EPYC 7351p und 2x 7543, HA Group Intel 3x Xeon E52640 v4 1x E5-2637 v3, Storage kommt ausschließlich von einem externen CEPH Cluster. Die Crash Problematik scheint bis jetzt nur auf den AMD's aufzutreten, die VM CPU's sind auf EPYC beschränkt die Intel's auf SandyBridge und Migration hat damit vorher auch sauber funktioniert.

VM Migrieren, Linux VM's crashen entweder sofort, oder sind Stuck mit 100% CPU. Was mir mehr Sorgen bereitet, es sind auch VM's betroffen die überhaupt nicht migriert worden sind, die dann auf einmal auch Crashen. Bei einer Windows VM konnte ich zufällig sehen das sich die Uhrzeit auf +27h geändert hat, angehängter Screenshot ist von einer VM die überhaupt nicht angerührt wurde aber trotzdem gecrashed ist.

Hat jemand auch Probleme das VM's crashen die nicht migriert worden sind?

Viele Grüße

Matthias
 

Attachments

  • dev-crash2.PNG
    dev-crash2.PNG
    157.8 KB · Views: 16
Hallo,
wir haben genau das gleiche wie Matthias. Wir haben ziemlich ähnliche CPU's nur halt AMD 3970x anstatt die Epic, aber nutzen die gleichen Intel. Bei uns crashen hauptsächlich alle Linux Server auf dem Zielserver, sobald die Migration abgeschlossen ist. Bei kleinen vServer ist das eher nicht der Fall als bei grossen aktiven Systemen. Natürlich hat nach jedem Crash die restlichen Linux Server häufig auch noch ein Datenverlust. Die Windows vServer haben es bei uns bis jetzt ziemlich gut überlegt.
Es kam sogar vor, dass auch der Proxmox Server selbst einfach während dem laufenden Betrieb gecrashed ist. Memtest, HW Test ist alles I.O. Diese Systeme liefen jahrelang normalerweise problemlos.
Auch ist uns aufgefallen, dass manchmal ein extrem hoher IO delay von 40.0 auf der Host Maschine selbst anliegt. Tritt einfach plötzlich auf, vermuten aber dass es etwas mit dem Netzwerktraffic zu tun hat in Kombination zur Arbeitsspeicherauslastung.
Da scheint mir ein echt krasser Bug zu sein. Zudem sind mir die Blockingstates auf der Konsole von Proxmox aufgefallen.

Wir nutzen

Linux 5.15.35-1-pve #1 SMP PVE 5.15.35-3

PS. Bei der i440fx Version > 5.0 funktioniert bei allen Windows Server der Netzwerkadapter nicht mehr. Der wird im Gerätemanager gefunden, Treiber können installiert werden, aber in der Netzwerkumgebung sieht man einfach keinen Adapter.
 

Attachments

  • Proxmox Crash.png
    Proxmox Crash.png
    309.5 KB · Views: 15
  • blocking-state.jpg
    blocking-state.jpg
    563.8 KB · Views: 14
Last edited:
Habe mal Logs von der VM aus dem Screenshot angehängt, aus irgendeinem Grund hat die sich wieder beruhigt. Hatte auch keine hohe Last erzeugt (14 cores 7% Last = 1 vcpu dicht), laut Proxmox Webinterface lief auch der Guest Agent nicht mehr. Der SSH Login funktionierte zur Verwunderung und nach einem systemctl status qemu-guest-agent wurde auf einmal wieder gepollt, siehe guest-agent.txt
 

Attachments

  • guest-agent.txt
    726 bytes · Views: 5
  • dev.log
    113.7 KB · Views: 7
Interessant so ähnlich hier:
Von: "2x 16-Core Intel Xeon Gold 6130 bits"
Nach:
"2x 6-Core Intel Xeon E5-2643 v3 bits"
2x 14-Core Intel Xeon E5-2660 v4 bits"
Freeze.
Umgekehrt geht es einwandfrei.

pve-manager/7.2-3/c743d6c1 mit Kernel 5.15.35-1-pve

Nachtrag:
Intel Silver Serie gleiches Problem wie bei Gold
 
Last edited:
After the Update to pve-kernel-5.19 (see Link) on all systems off my cluster the live migration works without that problem.

The live migation were possible without that problem, but in some cases the VM hangs.

I write above that this works only after updating all machines. At the beginning i only update one machine to test and migration from one system with a old to new kernel and back. I'm not sure but i had seens then the orginal problem.

Makes sense when the prblem is in the kernel and is fixed now.
 
  • Like
Reactions: Crash1601
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back