Windows-VMs langsam in Proxmox? Der CPU-Typ kann die Lösung sein
Wer ein Homelab betreibt oder virtuelle Maschinen auf Proxmox verwaltet, kennt langsame Windows-VMs als eines dieser nagenden Probleme, die es eigentlich gar nicht geben dürfte. Sie haben alles richtig gemacht: Ressourcen sind zugewiesen, die Disks sind in Ordnung, in den Logs steht nichts Seltsames. Und trotzdem schleppt sich Ihre VM dahin wie in Melasse festgeklebt. Kommt Ihnen das bekannt vor?
Es gibt eine Lösung, und sie versteckt sich gut sichtbar: die CPU-Typ-Einstellung.
Das Problem, vor dem niemand warnt
Ein Proxmox-Nutzer teilte kürzlich eine Geschichte, die bei vielen Anklang fand. Er hatte eine Weile mit miserabler Performance auf seiner Windows-VM gelebt, der Art, bei der schon das Öffnen des Startmenüs wie ein kleiner Akt des Mutes wirkt. Disk-Einstellungen, Treiber und sogar Registry-Tweaks hatte er doppelt gecheckt, ohne Erfolg.
Dann änderte er fast zufällig den CPU-Typ von "Host" auf ein bestimmtes emuliertes Modell, in seinem Fall AES-V2. Die Performance verbesserte sich nicht bloß, sie wurde 15-mal schneller. Das ist keine kleine Optimierung, sondern ein Unterschied wie Tag und Nacht, ausgelöst vom Umlegen eines virtuellen Schalters.
Moment, ist "Host" nicht die beste Option?
So wurde es uns allen erzählt: "Verwenden Sie 'Host' für maximale Performance." Für Linux-VMs oder in Cluster-Umgebungen mit Live-Migration hält dieser Rat auch stand. Bei Windows-VMs sieht die Sache anders aus.
Das Kernproblem liegt darin, wie Windows mit CPU-Schwachstellen umgeht. Übergeben Sie das vollständige Host-CPU-Feature-Set an die VM, was "Host" genau tut, nimmt Windows an, es laufe auf einem echten, physischen Prozessor, der möglicherweise nicht gegen Side-Channel-Schwachstellen wie Spectre oder Meltdown gepatcht ist.
Windows überkompensiert daraufhin und häuft software-basierte Mitigations an. Die sind ressourcenintensiv und zerstören, wie mehrere Nutzer bemerkten, CPU- und Disk-Performance. Selbst wenn Ihre Hardware technisch gepatcht ist, glaubt Windows das nicht und beaufsichtigt die CPU bei jedem Schritt.
Ein Proxmox-Nutzer erklärte es unverblümt: "Es verursacht Mitigations, die CPU-Zeit absolut demolieren und auch Speichermedien vernichten. Sie können leicht eine Disk haben, die ständig beschäftigt ist, während sie nichts tut." So schlimm ist es also.
Emulation zur Rettung
Wechselt man den CPU-Typ auf etwas wie AES-V2, AES-V3 oder AES-V4, filtert Proxmox problematische CPU-Flags heraus, unter anderem md_clear und flush_l1d. Genau diese Flags hängen oft mit den Performance-Einbrüchen zusammen.
Mit einem emulierten CPU-Modell bekommt das Gast-OS ein saubereres CPU-Profil, das die paranoide Sicherheitsschicht von Windows nicht alarmiert. Damit entfallen die unnötigen Mitigations, und die Reaktionsfähigkeit springt nach oben.
Ein Nutzer mit einem AMD Ryzen 5 PRO 4650G sah die Performance in die Höhe schießen, nachdem er von "Host" weggewechselt hatte. Ein anderer mit einem Mini-PC auf 5800H-Basis erzielte insgesamt bessere Ergebnisse mit x86-64-v2-AES.
Aber was ist mit der Kompatibilität?
Gute Frage. Bei emulierten CPU-Typen geht es um mehr als Performance, sie helfen auch bei Kompatibilität und Migration. Betreiben Sie etwa einen Proxmox-Cluster mit unterschiedlichen CPUs über die Nodes hinweg, macht die Wahl von AES-V2 Live-Migrationen zuverlässiger, weil alle VMs dieselben CPU-Features sehen, unabhängig von der physischen Hardware darunter.
Es gibt aber Vorbehalte. Wählen Sie einen CPU-Typ, den Ihre Hardware nicht vollständig unterstützt, laufen Sie in Stabilitätsprobleme. Ein Kommentator warnte, dass Epyc V4 auf einem Host ohne Ryzen 7000 Abstürze verursachte, sobald der Gast nicht unterstützte Anweisungen ausführen wollte.
Neuer ist also manchmal besser, aber das CPU-Modell muss zu Ihrer Host-Hardware passen.
Sollten Sie das tun?
Wenn Sie Windows-VMs auf Proxmox betreiben und träge Performance sehen, besonders auf Intel-Chips, rettet dieser Tweak womöglich Ihre Geduld. Unter Linux fahren Sie mit "Host" wahrscheinlich gut.
Eine schnelle Checkliste:
- Die VM ist Windows-basiert.
- Die Performance ist unerklärlich schlecht, mit CPU-Spitzen, hoher Disk-Nutzung und UI-Lag.
- Sie verwenden "Host" als CPU-Typ.
- Die Host-CPU ist von Intel, wobei AMD-Systeme nicht immun sind.
Stellen Sie den CPU-Typ auf AES-V2 oder x86-64-v2-AES und schauen Sie, was passiert. Gut möglich, dass es sich anfühlt, als hätten Sie Ihre VM von einer Kugel mit Kette befreit.
Warum steht das nicht im Wiki?
Das ist der frustrierende Teil. Obwohl das Problem echt ist und Nutzer seit Anfang 2025, wenn nicht früher, betrifft, erwähnt die offizielle Proxmox-Dokumentation es nicht. Stattdessen lebt es in verstreuten Forum-Threads, obskuren Blog-Posts und jetzt hier.
Ein Nutzer fasste es zusammen: "Solche Sachen sollten im Best-Practice/Wiki stehen, nicht nur in zufälligen Forum-Threads... Dies nirgendwo zu erwähnen, ist ärgerlich."
Damit hat er recht. Proxmox ist eine leistungsstarke Plattform mit einer leidenschaftlichen Community, und manchmal hat man das Gefühl, sich seine Streifen auf die harte Tour verdienen zu müssen.
Abschließende Gedanken
Läuft Ihre Windows-VM schleppend und haben Sie die üblichen Verdächtigen schon durch, dann schauen Sie sich den CPU-Typ an. "Host" gilt als Standard-Weisheit, doch wie diese wachsende Sammlung von Nutzererfahrungen zeigt, ist es nicht immer die beste Option.
Proxmox gibt Ihnen die Werkzeuge, um so ziemlich alles zu optimieren, nur liegen die besten Lösungen manchmal unter einem Haufen Annahmen begraben. Hier brauchte es eine zufällige Einstellungsänderung, um einen Performance-Durchbruch zu finden. Hoffentlich hilft dieser Text mehr Leuten, den Schmerz zu überspringen und direkt bei der Lösung zu landen. Denn niemand sollte eine 5-minütige Bootzeit erdulden müssen, nur um ein paar E-Mails zu checken.