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, und 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, und 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.

Bei einer wachsenden Zahl von Power-Usern lässt sich das nicht mit einer Fehlkonfiguration erklären, es tritt immer wieder in derselben Form auf. 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 und 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, und Linux-Gäste fühlen sich flott an. Innerhalb von Windows 11 bricht die Erfahrung dann 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, und 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 und ist zugleich irreführend, denn 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, weil die Performance trotz falsch aussehender Zahl vorhanden sein sollte. Hier ist sie es nicht. Die niedrigen Cinebench-Werte und die spürbare Trägheit im Alltag bestätigen, dass das Problem über Kosmetik hinausgeht. 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, und sie ist schon früher eingetreten. 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 und 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, und die sind 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. Damit haben sie der Performance möglicherweise selbst ein Bein gestellt.

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 und kvm=off entfernt, ohne eine Verbesserung zu sehen. Ab diesem Punkt wandert die Schuld weg von der Konfiguration.

Der Windows-11-24H2-Verdacht

Mehrere Berichte erwähnen dasselbe unangenehme Muster: Ältere Windows-Versionen verhalten sich einwandfrei, Linux-VMs verhalten sich einwandfrei, Windows 10 und Windows 11 23H2 ebenfalls, nur 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 ohne viel Aufsehen an, manchmal aber nicht, und 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. Es gibt keinen Kernel-Panic, keinen offensichtlichen Fehler und keinen einzelnen 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, was es weniger wie eine Lösung und mehr wie einen Würfelwurf wirken lässt.

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, also in einer leistungsstarken 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 und auch 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 und ein reproduzierbarer Testfall, den Proxmox, QEMU oder Microsoft nicht ignorieren können. Bis das passiert, lebt dieses Problem im schlimmsten aller Räume, nämlich real, schmerzhaft und gerade uneindeutig genug, dass jeder denkt, es sei die Schuld eines anderen.

Die Lektion daraus

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

Wenn Sie aber einen neuen High-End-Build planen, ist das einer jener Momente, in denen Early Adoption sich unauffällig 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, für manche Power-User aber absolut. Und bis die Community oder die Hersteller herausfinden, warum, ist der sicherste Workaround vielleicht der unbefriedigendste von allen: nicht upgraden.