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