Windows 11 auf Proxmox ist für manche Power-User kaputt – und die Community ist sich nicht einig, warum

Es gibt eine besondere Art von Frustration, die erst auftaucht, wenn man alles "richtig" gemacht hat.

Sie kaufen eine Flaggschiff-CPU. Dazu schnellen DDR5-Speicher, brandneuen NVMe-Storage, eine moderne GPU und eine saubere Proxmox-Installation. Auf dem Papier müsste das Ding brüllen. Linux-VMs fliegen. Die Benchmarks auf dem Host sehen perfekt aus. Die Temperaturen sind in Ordnung. Die Boost-Takte liegen an, wenn man sie braucht.

Dann bootet man eine frische Windows-11-VM, öffnet den Task-Manager, und plötzlich fühlt sich alles… falsch an.

Apps kriechen. Einfache UI-Aktionen ruckeln. Cinebench-Werte sehen aus, als kämen sie von einem Laptop aus dem letzten Jahrzehnt. Windows behauptet steif und fest, das Vielkern-Monster laufe mit verdächtig glatten 2,0 GHz – und egal wie viel man daran dreht, diese Zahl bewegt sich nicht.

Für eine wachsende Zahl von Power-Usern ist das keine Fehlkonfiguration. Es ist ein Muster. Und im Moment ist sich niemand wirklich einig, was da eigentlich kaputt ist.

Das Setup, das man eigentlich nicht vermasseln kann

Die betroffenen Systeme sehen sich alle ziemlich ähnlich: moderne Intel-CPUs mit Hybrid-Architektur, Proxmox als Hypervisor, Windows 11 als Gast. Oft mit GPU-Passthrough. Oft als High-End-Workstations aufgebaut, nicht als Homelab-Spielerei.

Auf der Host-Seite verhält sich alles genau wie erwartet. Die CPU-Boost-Takte erreichen 5 GHz und mehr. Der Festplattendurchsatz ist absurd schnell. GPU-Passthrough funktioniert. Die Netzwerk-Performance ist in Ordnung. Linux-Gäste fühlen sich flott an.

Innerhalb von Windows 11 bricht die Erfahrung jedoch zusammen.

Multi-Threaded-Benchmarks landen bei rund 3.000 Punkten, wo eigentlich 30.000 anstehen sollten. Schwergewichtige Apps brauchen Minuten zum Starten. Der Explorer zögert. Der Task-Manager zeigt fast keine CPU-Auslastung, während sich das System anfühlt, als würde es durch Schlamm waten.

Und ja, Windows meldet immer, dass ein Hypervisor vorhanden ist. Das überrascht nicht. Überraschend ist, wie konstant schlecht die Performance bleibt, egal was man ändert.

Die 2,0-GHz-Nebelkerze

Eines der ersten Dinge, die jedem auffallen, ist die Taktfrequenz.

Windows meldet, dass die CPU bei rund 1997 MHz an ihre Grenze stößt. Das sieht verdächtig aus. Ist aber auch irreführend. Unter KVM hat Windows keinen zuverlässigen Zugriff auf die Echtzeit-Frequenzskalierung und zeigt daher oft den TSC-Basistakt statt des tatsächlichen Boost-Verhaltens an.

Normalerweise wäre das egal. Selbst wenn die Zahl falsch aussieht, sollte die Performance trotzdem da sein.

Hier ist sie es nicht.

Die niedrigen Cinebench-Werte und die spürbare Trägheit im Alltag bestätigen, dass das nicht bloß kosmetisch ist. Irgendetwas hindert Windows aktiv daran, die CPU so zu nutzen, wie es sollte.

E-Cores, P-Cores und das Pinning-Kaninchenloch

Die erste große Theorie dreht sich um Intels Hybrid-Core-Layout.

Moderne i9-Chips mischen Performance-Cores und Efficiency-Cores, und Linux zählt sie nicht immer in einer sauberen, intuitiven Reihenfolge auf. Pinnt man die VM an die falschen logischen CPUs, kann eine schwergewichtige Windows-Last am Ende fast komplett auf den E-Cores landen.

Diese Erklärung klingt plausibel. Es ist schon früher passiert. Tools wie lscpu können durch Weglassen lügen, während hwloc eine ganz andere Topologie offenbart. Mehrere User waren überzeugt, dass genau das die Ursache sein müsse.

Nur haben viele der betroffenen Systeme ihre Hausaufgaben gemacht.

Sie haben die Core-Zuordnung mit lstopo verifiziert. Sie haben nur bestätigte P-Cores gepinnt. Sockets, Cores und Threads passten korrekt zusammen. Windows meldete die erwartete Topologie. Und trotzdem rührte sich bei der Performance nichts.

Wäre es nur schlechtes Pinning gewesen, hätte das Korrigieren der Affinität das Problem gelöst. Für viele hat es das nicht.

Hyper-V Enlightenments: Optimierung oder Falle?

Ein anderes Lager zeigt auf die Hyper-V Enlightenments.

Windows erwartet bestimmte Paravirtualisierungs-Hinweise, wenn es unter einem Hypervisor läuft. Dabei geht es nicht um Erkennung, sondern um Performance-Abkürzungen. Sie reduzieren VM-Exits, verbessern die Interrupt-Behandlung und halten Windows generell davon ab, dumme, teure Dinge zu tun.

Aus Verzweiflung haben viele User versucht, alle Hyper-V-Flags zu deaktivieren, KVM zu verstecken und die VM auf reine Bare-Metal-Anmutung herunterzustutzen, in der Hoffnung, Windows oder die GPU-Treiber auszutricksen.

Was sie stattdessen möglicherweise getan haben, ist der Performance ein Bein zu stellen.

Mehrere erfahrene Proxmox-User argumentieren, dass das Entfernen dieser Enlightenments, besonders in Kombination mit kvm=off, Windows effektiv in einen Worst-Case-Kompatibilitätspfad zwingt. Man hat zwar noch eine VM, aber ohne die Optimierungen, die sie nutzbar machen.

Diese Erklärung passt zu den Symptomen. Nur haben manche User alle empfohlenen Hyper-V-Flags wiederhergestellt, kvm=off entfernt – und trotzdem keine Verbesserung gesehen.

Ab diesem Punkt wandert die Schuld weg von der Konfiguration.

Der Windows-11-24H2-Verdacht

Hier wird es unangenehm.

Mehrere Berichte erwähnen dasselbe Muster: Ältere Windows-Versionen verhalten sich einwandfrei. Linux-VMs verhalten sich einwandfrei. Windows 10 verhält sich einwandfrei. Windows 11 23H2 verhält sich einwandfrei.

Windows 11 24H2 nicht.

Frische Installationen von 24H2 fühlen sich von Anfang an kaputt an. Ein Rollback auf ältere ISOs stellt auf demselben Proxmox-Host, mit derselben VM-Konfiguration, plötzlich wieder normale Performance her.

Das deutet stark auf eine Regression hin – entweder in Windows selbst oder darin, wie QEMU bestimmte CPU-Features gegenüber neueren Windows-Builds präsentiert.

Dafür gibt es Präzedenzfälle. Microsoft zieht die Virtualisierungs-Sicherheit stetig weiter an, fügt Schichten wie VBS und HVCI hinzu und nimmt tiefergreifende Scheduler-Änderungen vor. Meistens passen sich Hypervisoren still an. Manchmal aber nicht.

Im Moment sieht es so aus, als könnte dies einer dieser Fälle sein.

"Es ist Proxmox." "Nein, es ist QEMU." "Nein, es ist Windows."

Fragen Sie zehn Leute, was kaputt ist, und Sie bekommen drei selbstbewusste Antworten.

Manche argumentieren, Proxmox habe die jüngsten Windows-Änderungen noch nicht nachvollzogen. Andere bestehen darauf, dass Proxmox nur ein Wrapper ist und das Problem eindeutig in QEMU liegt. Eine dritte Gruppe zeigt auf Microsoft, das Annahmen durchdrückt, die außerhalb von Hyper-V nicht standhalten.

Was die Sache noch unübersichtlicher macht: Jede Erklärung klingt plausibel – und keine erklärt vollständig, warum identische Konfigurationen sich über verschiedene Windows-Builds hinweg so unterschiedlich verhalten.

Das Fehlen eines eindeutigen Beweises ist der Grund, warum dieses Problem so zermürbend wirkt. Kein Kernel-Panic. Kein offensichtlicher Fehler. Kein einzelner Schalter, der es für alle löst.

Nur langsames Windows, niedrige CPU-Auslastung und viele verschwendete Wochenenden.

Die "CPU-Typ"-Debatte, die nicht sterben will

Ein Workaround taucht immer wieder auf: kein cpu: host verwenden.

Manche User behaupten, das Umstellen auf ein generisches x86-64-v2- oder -v3-CPU-Modell – gefolgt von einer kompletten Neuinstallation von Windows – löse alles wie von Zauberhand. Die Theorie dahinter: Werden zu viele moderne CPU-Features exponiert, aktiviert Windows Verhaltensweisen, die unter KVM schlecht performen.

Das Problem? Etliche Leute haben genau das ausprobiert und keinerlei Veränderung gesehen.

Bei manchen Setups mag es funktionieren. Bei anderen eindeutig nicht. Das lässt es weniger wie eine Lösung wirken und mehr wie einen Würfelwurf.

Warum das mehr schmerzt als ein typischer Bug

Das ist kein Nischenproblem im Labor. Es geht um Workstation-Klasse-Maschinen, die für CAD, Rendering, Entwicklung und Kreativarbeit genutzt werden. Der ganze Sinn von Proxmox liegt hier in der Konsolidierung – eine leistungsstarke Box, die alles erledigt.

Wenn Windows in dieser Box plötzlich performt wie auf einer zehn Jahre alten CPU, bricht das gesamte Wertversprechen in sich zusammen.

Und weil die Linux-Gäste einwandfrei laufen, lässt sich kaum rechtfertigen, den Host komplett umzubauen, nur um Windows zufriedenzustellen.

Wo die Dinge aktuell stehen

Stand heute gibt es keine allgemein anerkannte Lösung.

Die zuverlässigste Abhilfe scheint zu sein, Windows 11 24H2 komplett zu meiden, bei älteren Builds zu bleiben oder auf Windows 10 zurückzufallen. Das ist nicht großartig. Es ist nicht zukunftssicher. Und es hilft niemandem, der schon mehrfach neu installiert hat, auf der Jagd nach Geistern.

Was fehlt, ist Koordination. Ein bestätigter Bug-Report. Ein reproduzierbarer Testfall, den Proxmox, QEMU oder Microsoft nicht ignorieren können.

Bis das passiert, lebt dieses Problem im schlimmsten aller Räume: real, schmerzhaft und gerade uneindeutig genug, dass jeder denkt, es sei die Schuld eines anderen.

Die leise Lektion daraus

Wenn Sie heute Windows 11 auf Proxmox betreiben und sich alles gut anfühlt, ist das großartig. Wirklich.

Aber wenn Sie einen neuen High-End-Build planen, ist das einer jener Momente, in denen Early Adoption sich leise rächt. Hybrid-CPUs, schnelllebige Windows-Releases und komplexe Virtualisierungs-Stacks spielen nicht immer gut zusammen – selbst wenn jedes Teil für sich perfekt funktioniert.

Im Moment ist "Windows 11 auf Proxmox" nicht für jeden kaputt.

Aber für manche Power-User ist es das absolut. Und bis die Community – oder die Hersteller – herausfinden, warum, ist der sicherste Workaround vielleicht der unbefriedigendste von allen: nicht upgraden.