Server 2025 VMs unglaublich träge

[Falk R.]

Mal ein kleines Update zu trägen VMs.
Ich hatte am Wochenende bei einem Kunden Mega träge VMs, die immer langsamer geworden sind und zum Schluß gar nicht mehr benutzbar waren.
Uns war aufgefallen, das nur ein Host im Cluster betroffen war, da habe ich mich erinnert, dass es das Phänomen schon bei vSphere gab, aber nie so extrem. Lösung: C-States im Bios komplett deaktivieren, danach war alles wieder schnell. Teilweises deaktivieren oder nachträglich per Software, hilft manchmal auch nicht, als wer auf Nummer sicher gehen will, im BIOS komplett aus machen.
Eventuell hilft das dem einen oder anderen doch noch etwas.

 

[GMBauer]

Macht man das nicht immer, bevor man den PVE installiert? Bzw. warum sollte man es nicht...

 

[cwt]

Macht man das nicht immer, bevor man den PVE installiert? Bzw. warum sollte man es nicht...

Ist (zumindest mache ich das so) bei Inbetriebnahme eines Systems nach dem BIOS update immer die erste Amtshandlung. Bei 24/7 Produktivsystemen machen C-States m. E. auch keinen Sinn. Die paar Watt Einsparungen stehen in keinem Verhältnis zu möglichen auftretenden Problemen.

 

[Falk R.]

Macht man das nicht immer, bevor man den PVE installiert? Bzw. warum sollte man es nicht...

Naja, bei einem Host im Cluster wurde es vergessen und schon konnte man live die Probleme sehen.

 

[showiproute]

Ich habe bei mir einen deutlichen Performanceschub gemerkt, als ich das virtuelle TPM wieder entfernt hatte.
Keine Ahnung was Windows Server 2025 hier im Hintergrund macht, aber die Performance ist mehr als fühlbar.

Ergänzend wäre zu erwähnen, dass die TPM "Festplatten" auf performanten Enterprise SSDs liegen.

 

[mcherold93]

Also bei mir hat folgendes geholfen bei einer VM, die ich von Server 2019 auf Server 2025 aktualisiert habe:

1. OVMF (UEFI) - ist klar
2. Anzeige - VGA (Standard) mit 256MB Speicher (keinesfalls VirtIO - hat alles nur langsamer gemacht bei mir)
3. Maschinentyp auf q35 11.0+pve2
4. Controller auf SCSI VirtIO Single
5. Datenträger per SCSI anbinden, IO Thread aktivieren und bei Asynchrone IO IO Uring auswählen, ggf. noch SSD Emulation aktivieren
6. TPM Modul entfernen
7. Ballooning auf jeden Fall deaktivieren
8. CPU auf x86-64-v3 einstellen!
   Keinesfalls auf Host!
   Wenn du den Proxmox-Standard host nutzt, reicht Proxmox alle Sicherheitsfunktionen und CPU-Eigenschaften 1:1 an Windows weiter, sieht alle Hardwareschwachstellen und wirft dann die Software-Gegenmaßnahmen an, was extrem ausbremst, von daher größter Fehler, den man machen kann.
   Hab einen E5-2640 v4, so sollte er die wichtigsten Befehlssätze eigentlich nutzen können.
   Wer was moderneres hat, kann auch auf v4 gehen, wer was älteres hat auf v2.
9. VBS per Registry deaktivieren, sicher ist sicher.
10. Treiber von virtIO 0.1.302
11. Energieeinstellungen auf Höchstleistung
12. Uner Computereigenschaften -> Erweiterte Systemeinstellungen -> Erweitert -> Leistungseinstellungen -> auf "für optimale Leistung anpassen" stellen (nur Fensterinhalt beim Ziehen anzeigen hab ich aktiv gelassen)
    Fensterschatten deaktivieren brachte sofort eine spürbare Verbesserung.

Das alles ohen Neuinstallation und entgegen der Aussage, dass nachträgliches umstellen angeblich nicht klappt
Würde sagen die Perfomance ist wieder auf dem gleichen Niveau, wie vor dem Update.

 

[Bu66as]

Die 30% Systemunterbrechungen, die @richik75 gemessen hat, riechen für mich weniger nach VBS als nach den Windows-eigenen Software-Mitigations. Mit cpu: host sieht der Gast auf den alten Xeons (E5 v2 bis v4) die ganzen Spectre/MDS-Geschichten so wie sie sind und dreht seine Gegenmaßnahmen voll auf. Bei nem named Model wie x86-64-v2-AES ist das Featureset anders und manches fällt weg. Passt auch dazu, dass @Falk R. VBS nachweislich aus hatte und die Kiste trotzdem zäh war.

Ließe sich halbwegs schnell testen: SpeculationControl-Modul in der VM installieren und Get-SpeculationControlSettings mit host und mit x86-64-v2-AES gegeneinander laufen lassen. Wenn bei host reihenweise die Mitigations als aktiv rauskommen und beim anderen nicht, hat man den Verursacher schwarz auf weiß. Bin mir da nicht 100% sicher, aber das Muster (CPU-Last ohne echte Last, Eingaben häppchenweise) hab ich genau so schon bei alter Hardware gesehen.