[SOLVED] VM langsam seit Umstellung auf host-cpu

P

philipp_h

New Member
Jan 14, 2025
5
0
1
Switzerland
Hallo Zusammen

Ich habe einen kleinen Proxmox-Server
2 x Intel XeonE5-2640 v4, 384Gb RAM, PVE 8.3.4

Darauf läuft eine Windows 11 VM (8 Cores, 16Gb RAM).
Aufgesetzt wurde die VM mit "x86-64-v2-AES" CPUs
Allerdings verlangt eine Software zwingend AVX, weshalb ich den CPU-Type auf "host" gestellt habe.

Seit der Umstellung läuft das System sehr langsam.
In der VM selber habe ich permanent >20% CPU last.
Proxmox selber meldet auf der VM eine Last von >40%

perf top meldet folgende Einträge rot:
Code: 
14.01% [kernel] [k] nested_vmx_vmexit
 5.53% [kernel] [k] vmx_l1d_flush

Habt ihr eine Idee, was ich umstellen kann, damit das System mit aktiviertem AVX wieder schneller läuft?

Vielen dank und freundliche Grüsse
Philipp
 
Last edited:
philipp_h said:
einen kleinen Proxmox-Server
2 x Intel XeonE5-2640 v4, 384Gb RAM, PVE 8.3.4
Click to expand...
Tetris und Pong sollten flüssig laufen. ;)

philipp_h said:
Finde es trotzdem komisch, dass die VM mit der Host-CPU solche Symptome zeigt.
Click to expand...
Auf jeden Fall.
Wie hast du die Kerne zugewiesen? Auf ein Socket oder 2? Windows mag eine bestimmte Kombi nicht sonderlich, keine Ahnung warum, aber unter bhyve konnte ichs ähnlich beobachten.

Gegen x86-64-v3 spricht aber auch nichts, wenn es klappt.
 
  • Like
Reactions: philipp_h and Johannes S
Der CPU Typ host sollte niemals soetwas verursachen. Mach mal 1 Sockel und 4 bis 8 Cores. Der Typ host sollte immer am schnellsten sein.
Hast du die C-States im BIOS deaktiviert?
 
  • Like
Reactions: philipp_h and Johannes S
mr44er said:
Tetris und Pong sollten flüssig laufen. ;)


Auf jeden Fall.
Wie hast du die Kerne zugewiesen? Auf ein Socket oder 2? Windows mag eine bestimmte Kombi nicht sonderlich, keine Ahnung warum, aber unter bhyve konnte ichs ähnlich beobachten.

Gegen x86-64-v3 spricht aber auch nichts, wenn es klappt.
Click to expand...

Die Kisten gibts gebraucht für kleines Geld ;)
Hab diverse Kombinationen durch, 1x 8-Cores, 2x 8-Cores, 1x 16-Cores...

Falk R. said:
Der CPU Typ host sollte niemals soetwas verursachen. Mach mal 1 Sockel und 4 bis 8 Cores. Der Typ host sollte immer am schnellsten sein.
Hast du die C-States im BIOS deaktiviert?
Click to expand...

Danke, die BIOS-Settings muss ich mal anschauen.

Hab zu Testzwecken eine zweite VM aufgezogen, die läuft einiges flüssiger als die andere VM.
Die Ursprüngliche VM läuft zwar etwas besser mit der v3-CPU, aber da ist doch ein spürbarer Unterschied zu der neuen Kiste.
Leider sehe ich aktuell keine "Messpunkte" die einen Hinweis geben könnten, warum das so ist.
 
Win11 und Server 2025 haben generell Probleme wenn du den default x86-64-v2-AES CPU Typ benutzt. Welches Feature da vermisst wird, weiß ich aber auch nicht. Daher installiere ich Server 2025 nur mit Typ Host, oder der dem Typ der ältesten CPU im Cluster z.B. Epyc-Rome bei den Zen2 CPUs.
Eventuell hat der Win11 Installer da irgendwelche Features abgeschaltet, wegen der eingeschränkten CPU und jetzt lahmt die Kiste. Ich würde einfach mit CPU Typ host einmal neu installieren, dann sollte alles flüssig laufen.
 
  • Like
Reactions: philipp_h and mr44er
Welche Virtio Treiber Version ist installiert - 0.1.248 oder höher?
Was läuft sonst so auf der Win VM?
Bitte auch mal die VM Config (Hardware / Optionen) posten
Läuft der Proxmox mit Festplatten oder SSDs?
 
Last edited:
  • Like
Reactions: philipp_h
virtio ist neuste Version (stable, 0.1.266), alles auf S-ATA SSDs

Ich komm nicht drauf, was an der VM falsch läuft.
Ich habe zwei weitere VMs mit den selben Settings/Software aufgesetzt ohne diese Probleme.

Werde die betroffene VM bei der nächsten Gelegenheit wohl komplett neu machen.

Danke für eure Inputs
 
Nachdem ich noch etwas rumgespielt habe, läuft es wohl darauf hinaus, dass die CPU einfach zu alt für Win11 24h2 ist.
Mit QEMU dazwischen läuft es einiges performanter.

Muss mal testen, ob ich ein ähnliches verhalten bei einer Desktop CPU der selben Generation feststellen kann.

Die Server 2022 laufen auch gut darauf, Server 2025 steht noch auf der Todo-Liste
 
Es kann mit der 266 laufen, aber generell wird hier im deutschsprachigen Forum empfohlen, die 248er zu benutzen und nicht die 266er. Es gibt leider zu viele Threads, wo der Fehler nachweisbar in der 266er steckte.
 
quanto11 said:
Ich welcher Konstellation zickt v266 wie Sau? Hier laufen knapp 100 VMs seit Dezember mit iscsi problemfrei.
Click to expand...
Hi, du kannst Glück haben, aber es gibt da einen Performancebug, der sogar zum einfrieren von VMs führen kann. Da dieser aber nur mit 6er Kerneln auftritt ist Redhat nicht so schnell mit dem einpflegen des Fixes, welcher schon von einem Unterstützer commited wurde. Redhat ist Stable ja noch auf 5er Kernel.
Wenn du viele VMs habe die keine sonderlich große Disklast erzeugen und dein Backendstorage schnell genug ist, merkst du nix von dem Bug. Bei Server 2025 nehme ich aus anderen Kompatibilitätsgründen auch die 0.1.266, aber bei Servern bis 2022 belasse ich es derzeit bei 0.1.248.
 
  • Like
Reactions: Johannes S
Habt ihr einen Link für mich, wo über dieses Problem diskutiert wird?

Ich hatte ein ähnliches Verhalten auf einem sehr langsamen ceph storage nachvollziehen können, welches auf HDDs basiert und die Queue für HDDs auf ein nicht auszuhaltendes Niveau anhebt, sodass das Ceph Volume im Windows einfriert und nicht mehr erreichbar ist.

Jedoch tritt kein ähnliches Problem bei einem schnellen Speicher auf, auch nicht bei sehr hoher IO Belastung.

B

Post in thread 'Redhat VirtIO developers would like to coordinate with Proxmox devs re: "[vioscsi] Reset to device ... system unresponsive"'

quanto11 said:
benyamin said:
Has anyone tried v266 with a Ceph backing...?
Click to expand...

yes, works flawlessly

the only thing i noticed with v266 is, that HDD backed Ceph with very high queue kills the specific volume and it because unresponsive and stuck forever. Best way to trigger that is having a Fileserver with deduplication, start a garbage collect, and now comes the most important part, having cache set to writeback. Setting Cache from writeback to none resolves my problem.

can't say for sure if this is related to v266, unfortunately can't test any other driver version at the moment.
Click to expand...

Great news..!
This...
  • Like
 
Last edited:
quanto11 said:
Habt ihr einen Link für mich, wo über dieses Problem diskutiert wird?

Ich hatte ein ähnliches Verhalten auf einem sehr langsamen ceph storage nachvollziehen können, welches auf HDDs basiert und die Queue für HDDs auf ein nicht auszuhaltendes Niveau anhebt, sodass das Ceph Volume im Windows einfriert und nicht mehr erreichbar ist.

Jedoch tritt kein ähnliches Problem bei einem schnellen Speicher auf, auch nicht bei sehr hoher IO Belastung.

B

Post in thread 'Redhat VirtIO developers would like to coordinate with Proxmox devs re: "[vioscsi] Reset to device ... system unresponsive"'

quanto11 said:
benyamin said:
Has anyone tried v266 with a Ceph backing...?
Click to expand...

yes, works flawlessly

the only thing i noticed with v266 is, that HDD backed Ceph with very high queue kills the specific volume and it because unresponsive and stuck forever. Best way to trigger that is having a Fileserver with deduplication, start a garbage collect, and now comes the most important part, having cache set to writeback. Setting Cache from writeback to none resolves my problem.

can't say for sure if this is related to v266, unfortunately can't test any other driver version at the moment.
Click to expand...

Great news..!
This...
  • Like
Click to expand...
Hi, den finde ich gerade nicht mehr, der Fix wurde ja schon letztes Jahr contributed. Eigentlich hatte RedHat ca. 2 Monate Zeit vor der Version 0.1.266, diesen Fix zu übernehmen. Bei RH tritt das mit KVM und Qemu nicht auf, da erst ab 6er Kernel. Mit dem 5er Kernel hat man aber wieder etwas weniger Performance (natürlich Workloadabhängig).

Ich habe den Thread komplett aus den Augen verloren, da es noch dauert bis die nächste Version kommt und es keine Garantie gibt, dass der Fix endlich drin ist.
Bei meinen produktiven Setups meiner Kunden, habe ich das Problem nie gesehen, aber ich baue neue Ceph Cluster schon eine ganze Weile NVMe only und wenn möglich mit 100G Netz.
 
You must log in or register to reply here.
Top Bottom