Wie downgrade virtio 1.285 auf 1.271?

Das Problem ist nicht der fehlende Collector an sich, sondern dass deine Dashboard-Variable (die Instance-/Host-Auswahl) auf einer cs_-Metrik aufsetzt, die es nicht mehr gibt. Wenn die Template-Query wie label_values(windows_cs_hostname, instance) ist, kommt nach dem Wegfall nichts mehr zurück und das Panel ist leer.

Zieh die Variable einfach auf eine Metrik um, die immer da ist, z.B. label_values(up{job="windows"}, instance) oder alternativ windows_os_info / windows_cpu_info. Damit hängt deine Host-Liste nicht mehr an einem einzelnen Collector. Die alten windows_cs_*-Werte sind nicht weg, sondern verteilt: logische CPUs stecken jetzt in windows_cpu_info, der RAM in windows_memory_physical_total_bytes.

Die fertigen Community-Dashboards hinken da echt hinterher, da musst du durch und die Queries einmal durchgehen. Ich häng das Host-Up bei sowas grundsätzlich an up{job=...} statt an irgendeiner Collector-Metrik, dann bricht dir nicht bei jedem Exporter-Update das halbe Dashboard weg.
 
Soeben wieder eine der beiden VMs ausgefallen.
Die mit CPU=host hatte das Problem, die geänderte läuft bislang problemlos.
Nur eine Beobachtung und Feststellung, noch keine Erklärung.

Ich habe nun auch die soeben abgeschmierte VM auf die konservativere CPU umgebaut, und nested-virt abgeschaltet.

Nun wieder Beobachten. (Cache fasse ich erst beim nächsten Crash an, zwecks Nachvollziehbarkeit, wie besprochen).

Ahja: PVE-seitig sehe ich zu dem Zeitpunkt keine besonderen Vorkommnisse: Die Zacken in den Loads gehen erst hoch, als ich die VM neu gestartet habe. Die CPU-Load in der VM scheint vor/bei dem Crash hoch gegangen zu sein. Ich sichte noch ...

EDIT: was ich gestern vergessen habe zu erwähnen: bei der nun bislang OK laufenden VM habe ich auch NUMA=1 gesetzt, laut dem erwähnten Posting. Bei der soeben abgeschmierten habe ich es nun in der Eile vergessen ...
 
Last edited:
@sgw Das klingt fast so wie das Problem, welches ich hier ebenfalls angesprochen habe:
K

Thread 'Windows 2025 Freeze seit PVE 9.2.2'

Hallo Proxmox Forum,

wir haben aktuell eine Situation bei welchem nach einem Update auf Proxmox 9.2.2 (bzw. vermutlich Kernel 7.0 / QEMU 11) eine Windows 2025 VM spontan mit CPU 100% einfriert und nicht mehr reagiert.
Nach einer gewissen Zeit erholt sich diese allerdings und funktioniert wieder normal.
Dies passiert seit dem Update regelmäßig und passiert entweder direkt zum Start der VM oder unerwartet während des laufenden Betriebs.

In den Ereignislogs der VM selbst ist nichts zu sehen.
Im Anhang befindet sich die VM Konfiguration samt einem Auszug von gdb und strace während die VM...

Wir haben bei unserem Kunden ebenfalls mit host CPUs gearbeitet und VIrtIO 285.
Nachdem wir es auf VirtIO 271 und v86-64-v3 CPUs mit -nested-virt (redundant, da die x86-64 CPUs das sowieso nicht besitzen) gesetzt haben, laufen se seitdem stabil.

Es gab noch Beschwerden bezüglich höherer Latenz / langsamen Reaktionszeiten, aber das könnte auch ein unabhängiges Problem sein.

Die letzte Rückmeldung bzw. Antwort in diesem Thread steht noch aus, da unser Kunde noch nicht final das Ok gegeben hat...
Aber es sieht bisher gut aus.
 
  • Like
Reactions: sgw
Khensu said:
@sgw Das klingt fast so wie das Problem, welches ich hier ebenfalls angesprochen habe:
K

Thread 'Windows 2025 Freeze seit PVE 9.2.2'

Hallo Proxmox Forum,

wir haben aktuell eine Situation bei welchem nach einem Update auf Proxmox 9.2.2 (bzw. vermutlich Kernel 7.0 / QEMU 11) eine Windows 2025 VM spontan mit CPU 100% einfriert und nicht mehr reagiert.
Nach einer gewissen Zeit erholt sich diese allerdings und funktioniert wieder normal.
Dies passiert seit dem Update regelmäßig und passiert entweder direkt zum Start der VM oder unerwartet während des laufenden Betriebs.

In den Ereignislogs der VM selbst ist nichts zu sehen.
Im Anhang befindet sich die VM Konfiguration samt einem Auszug von gdb und strace während die VM...

Wir haben bei unserem Kunden ebenfalls mit host CPUs gearbeitet und VIrtIO 285.
Nachdem wir es auf VirtIO 271 und v86-64-v3 CPUs mit -nested-virt (redundant, da die x86-64 CPUs das sowieso nicht besitzen) gesetzt haben, laufen se seitdem stabil.

Es gab noch Beschwerden bezüglich höherer Latenz / langsamen Reaktionszeiten, aber das könnte auch ein unabhängiges Problem sein.

Die letzte Rückmeldung bzw. Antwort in diesem Thread steht noch aus, da unser Kunde noch nicht final das Ok gegeben hat...
Aber es sieht bisher gut aus.
Click to expand...

Ah, das klingt ja vielversprechend, danke fürs Feedback. Das macht Hoffnung für die 2. VM
:)

Der Kunde selbst meint, die VMs verhalten sich OK, aber ich werde da (nach etwas Beruhigungs-Zeit) noch mal nachhaken, ob die Performance akzeptabel ist. Ob unsere CPUs `nested-virt` könnten, keine Ahnung. Es sind welche vom Typ "Intel(R) Xeon(R) Silver 4215R CPU @ 3.20GHz".

Ich klick mal auf Senden und seh dann noch nach dem von Dir verlinkten Thread. Danke!
 
sgw said:
Ob unsere CPUs `nested-virt` könnten, keine Ahnung. Es sind welche vom Typ "Intel(R) Xeon(R) Silver 4215R CPU @ 3.20GHz".
Click to expand...
Die CPU kann das sicherlich. Aber ich meinte hier eher den x86-64-vX CPU Typ, diese haben die nested-virt flags standardmäßig nicht mit drin, daher braucht man Sie auch nicht manuell entfernen. Bei Host hingegen, welche alle Flags der CPU durchreicht, ist es notwendig.
 
Last edited:
Interessant, das kippt meinen host-Tipp von oben. Ich hatte ja geschrieben, geh wieder zurück auf host, aber wenn jetzt genau die host-VM abschmiert und die auf x86-64-v3 stabil läuft, dann nehm ich das zurück, dann ist der CPU-Typ doch der Hebel und nicht nur Performance-Kosmetik.

Zusammen mit dem, was @Khensu schreibt (das gleiche Problem, die gleiche Lösung) und dem "Freeze seit 9.2.2"-Thread, riecht das stark nach ner QEMU-11/Kernel-7.0-Regression mit der host-CPU, nicht Treiber, nicht Cache. Würd beide jetzt auf x86-64-v3 lassen und gar nicht mehr Richtung host gehen. Und das numa=1, das du bei der einen gesetzt und bei der gecrashten vergessen hast, würd ich nachziehen, dann sind beide gleich und du vergleichst sauber.

@Khensu hat übrigens recht: die x86-64-vX-Typen haben die nested-virt-Flags eh nicht drin, da bringt das manuelle Abschalten eh nix.
 
`numa=1` ist schon vorbereitet, wartet halt auf Neustart, sobald die User nach Hause gehen ;-)

Das mit NUMA leuchtet mir auch teils ein: vielleicht ist das deswegen unvorhersehbar, weil es mit dem Wechselspiel der circa 20-30 anderen VMs auf dem Node zu tun hat. Ein Fixieren auf die eine CPU schaltet quasi eine Fehlerquelle aus (die These leuchtet ein).

Bislang also läuft die gestern angepasste VM stabil durch. Wir warten erstmal ab hier. Wenn das so bleibt, gehe ich dann auf beiden VMs auf:

* x86-64-v3 (ist aktiv)
* numa=1 (auf der einen bereits aktiv, in der 2. VM noch nicht)
* nested-virt setze ich dann wieder auf den default, einfach nur, um sich weniger merken zu müssen (ich muss das ja dann auch deren Admin für neue VMs schulen)

Oh, passt auf: es gibt noch eine 3. VM, auch mit OS Win Server 2025, auf einem dritten Node (selbe pCPUs, selber Debian-Kernel am Host, selbes QEMU ... vielleicht ein paar Debian-Packages hinten, aber in etwa am gleichen Stand), die fährt mit cpu=host und hat diese Abstürze noch nicht gezeigt (Uptime 20 days, nur so als Beobachtung).

These 1: Ein Unterschied: VM3 - machine 10.0+pve1 .. VM1 und VM2 - machine 10.1. Das ist nun auch ein heißer Tip, oder?

These 2: ob dort drin die letzten Win-Updates sind, ist auch noch ein zu prüfendes Thema. Vermutlich eher nicht, siehe Uptime.

These 3: NUMA: Das würde dann für mich eher erwarten lassen, dass VM2 wieder in einen Absturz läuft (laut "Muster" morgen früh).
NUMA deswegen, weil es ein anderer Node ist, auf dem vielleicht weniger los ist und vielleicht deswegen weniger Bewegung drin ist (?).

Ich bin froh, wenn ich mit obigen Changes die Thematik lösen kann, aber eindeutig ist es nun wieder nicht.

Ist halt wohl auch die Kombination von Settings.

Spannend.

Ich hab jedenfalls vor, kommende Woche, wenn deren Admin/Developer wieder da ist, alle 3 Nodes auf letzten Stand zu patchen, inkl. Reboots in die aktuellen Debian-Kernel. Mal so als Basis.
 
  • Like
Reactions: Johannes S
Ja, These 1 ist für mich klar der heißeste von den dreien. VM3 ist eigentlich dein bester Beweis: läuft mit cpu=host und schmiert NICHT ab, einziger echter Unterschied ist der ältere Maschinentyp. Das verschiebt die Vermutung weg vom CPU-Typ hin zum pc-q35-10.1 bzw. der QEMU-11-Geschichte. Wenn host auf VM3 stabil läuft, kann host allein ja nicht der Übeltäter sein, dann hab ich mich in #28 zu früh festgelegt.

Würd das testen: eine Kiste auf pc-q35-10.0+pve1 pinnen (qm set <id> --machine pc-q35-10.0+pve1), sonst nix anfassen. Wenn die dann durchläuft, hast du's eingekreist.

Noch was: bevor du nächste Woche alle drei Nodes durchpatchst, sicher dir die VM3-Beobachtung als Referenz. Wenn überall gepatcht und alles auf einmal umgestellt ist, verlierst du genau den Vergleich, den du gerade hast.

These 3 mit NUMA ist eher ein Nebenschauplatz, das erklärt eher Jitter/Performance als nen harten Freeze.
 
Danke @Bu66as ... ich erzähl das dann mal dem Kunden und sehe zu, demnächst beide Problem-VMs entsprechend anzupassen.
Die Nodes kämen erst heute in einer Woche dran, bis dahin können wir noch einige Tage testen und beobachten.

Sollte es eine Wechselwirkung mit dem Kernel des/der Nodes haben, hier als Referenz: derzeit läuft auf allen 3 Nodes 7.0.2-6-pve.
Installiert und verfügbar wäre aber nach Reboot: 7.0.6-2-pve

Aber klar: Mein Fokus liegt nun auf machine in den 2 VMs. VM3 und die Nodes werden nicht angefasst, deckt sich mit meinem Verständnis und Plan.
optional retour auf cpu=host, eher erst nach ein paar Tagen Stabilität.

EDIT: 1. VM bereits geändert, 2. startet der Kunde dann abends entsprechend noch neu (ja, kein Warmstart, habe ich ihm erklärt). Wir sind gespannt ;-)
 
Last edited:
You must log in or register to reply here.
Top Bottom
Back