Probleme mit CPU auslastung

[Falk R.]

Was ich schrieb: nested ist dann (m.W.) per default aus. Zudem ist es schlicht meine persönliche Erfahrung, daß "host" am ehesten Probleme macht bei Windows. Hab schon VMs gehabt, wo dann z.B. der Explorer in einer Crash-Schleife läuft. Warum auch immer. Ist halt Windows.

Das liegt niemals an der Option host. Host bedeutet ja nur, dass alle Features der CPU weiter gereicht werden, so wie bei ESXi oder HyperV per default.
Ich nutze seit vielen Jahren nur host bei meinen Kunden und bis auf das nested virt. Flag bei 2025 gab es noch nie Probleme damit. Wenn es Probleme gibt, dann immer aus anderen Gründen.

Was ich schrieb: DC + RDS auf derselben Maschine.

Ich glaube ganz unbedingt, daß dies schon ein paar so machen.

In #4 sieht man den Hostnamen: SRV-RDPDC. Fällt mir schwer, das anders zu interpretieren als DC + RDS (oder worauf soll RDP deuten).

DC kann auch dafür stehen, dass Datacenter Lizenzen verwendet werden.

 

[6equj5]

DC kann auch dafür stehen, dass Datacenter Lizenzen verwendet werden.

Könnte sein.

Ich nutze seit vielen Jahren nur host bei meinen Kunden und bis auf das nested virt. Flag bei 2025 gab es noch nie Probleme damit.

Erstaunlich.

Wenn es Probleme gibt, dann immer aus anderen Gründen.

Hier ist die Erfahrung halt gemischt. "cpu=named-model" hat durchweg CPU-Performanceprobleme gelöst gegenüber "host". Es geht ja nicht nur um VBS, sondern die S/W-Mitigations, welche Windows oft versucht. Die ziehen alles runter.
Daß die Instruction Sets gleich sind, wenn man das richtige Modell auswählt, sieht man ja mit CPU-Z.
Ist nur ein Vorschlag. Der TS kann es probieren, falls er jemals wieder hier reinschaut, oder auch nicht.

 

[boisbleu]

[SOLVED] Post in thread 'Windows 2025 Freeze seit PVE 9.2.2'

Jul 17, 2026

Und hier kommt der Bugreport: https://bugzilla.proxmox.com/show_bug.cgi?id=7825

• mariol

• 

Dürfte das selbe Thema sein.

Mit dem Update von heute Nacht kommen die Patches zu den Freezes (hoffentlich). Laut Bugreport muss dazu die Maschinenversion auf 11.0+pve2 gestellt werden. Wäre schön, wenn ein Betroffener das mal testen kann.

 

[Bu66as]

Das trifft dich direkt @Enigmaso, deine VM steht laut Screenshot noch auf pc-q35-11.0. Sobald du das Update von heute Nacht drauf hast, den Maschinentyp auf 11.0+pve2 ziehen und die VM komplett runterfahren und neu starten, nicht nur rebooten, sonst wird der neue Maschinentyp nicht übernommen.

Wenn du der Betroffene aus dem Bugreport bist: häng dein Ergebnis lieber dort dran, das hilft mehr. Dann kann man auch gleich sehen, ob nach dem Patch nur noch die Grundlast (VBS/Mitigations) übrig bleibt oder ob es dann läuft.

 

[aglandorf]

Wir haben das Problem mit 2 Build VM´s die seit 6 Wochen genau dieses verhalten zeigen. Die CPU spiked, das Netzwerk 'stirbt', der Guest Agent ist tot und die beiden VM´s sind zwischen 2~60 Minuten nicht mehr erreichbar bis die CPU runter kommt und dann kann man per Konsole oder RDP drauf.
1 der beiden VMs benutzt Docker Desktop, die andere nicht. Durch das umschalten des CPU Typ auf x86-64-v4 konnten wir die VM die NICHT Docker Desktop verwendet zum fliegen bringen, die andere ist weiterhin ein Problem. Egal wie wir versuchen die Nested Host Virtualisierung durchzureichen, es funktioniert nur mit HOST type CPU.

Im selben Zeitraum haben wir auch auf Proxmox 9.2.2 aktualisiert, ich komme mittlerweile nicht umhin zu denken das es damit was zu tun hat.
*Update*
Unser Cluster läuft noch auf Qemu 9.1.15 muss also dann auf jeden Fall jetzt noch mal aktualisiert werden auf Qemu 9.2.1

 

[6equj5]

Egal wie wir versuchen die Nested Host Virtualisierung durchzureichen, es funktioniert nur mit HOST type CPU.

Kann ich leider nur bestätigen, was WSL2 und Docker Desktop betrifft. Hab allerlei probiert.
Ich hab en Ryzen 7 255 und es geht (bisher) nur so:


Und der Host hat:

Linux 7.0.14-8-pve (2026-07-28T10:28Z)
pve-manager/9.2.5/20242970da7fbcef

Neueste Version. Also da kann ich Euch leider auch keine Hoffnung machen. Hab einiges probiert bei CPU Typ.
Das, was hier allerdings ist: kein Problem mit type=host. Keine Hänger, langsam o.ä. Ist aber "nur" 'n Home Lab auf NAS-H/W (womit ich mega zufrieden bin )...

 

[aglandorf]

Kann ich leider nur bestätigen, was WSL2 und Docker Desktop betrifft. Hab allerlei probiert.
Ich hab en Ryzen 7 255 und es geht (bisher) nur so:
View attachment 99230

Und der Host hat:

Linux 7.0.14-8-pve (2026-07-28T10:28Z)
pve-manager/9.2.5/20242970da7fbcef

Neueste Version. Also da kann ich Euch leider auch keine Hoffnung machen. Hab einiges probiert bei CPU Typ.
Das, was hier allerdings ist: kein Problem mit type=host. Keine Hänger, langsam o.ä. Ist aber "nur" 'n Home Lab auf NAS-H/W (womit ich mega zufrieden bin )...

Moin,

wir werden es mit nem Update versuchen um die Qemu-Server version von 9.1.15 auf 9.2.1 zu aktualisieren. Bzw. dann gleich komplett alles auf die aktuellste Version bringen. Unser kleiner Cluster hat 3 Nodes mit der gleichen Intel Xeon Gold 5415+ (Sapphire Rapids) CPU. Auf dem sind auch die beiden VM´s die Probleme bereitet haben, die eine VM konnten wir 'fixen' indem wir den CPU Typ geändert haben, aber die andere eben nicht wegen WSL+Docker Desktop....
Hab gestern und vorgestern in einer TestVM mit WSL und DockerDesktop hin und her getestet aber immer das gleiche, sobald sich der CPU Typ ändert ist WSL2 kaputt.

Naja, zumindes könnte https://bugzilla.proxmox.com/show_bug.cgi?id=7825 die Lösung sein, dann wärs mir eigentlich egal ob die VM auf Host Type CPU läuft oder nicht.

Wir gucken mal.