Wer sich ernsthaft mit moderner Virtualisierung auseinandersetzt, stößt früher oder später auf ein wiederkehrendes Problem: Virtuelle Maschinen bieten selten die gleiche Grafikleistung wie das direkt auf der Hardware installierte Betriebssystem.Während der Host-Desktop selbst in 4K flüssig laufen mag, kann der VM-Desktop ruckeln, mit Mausverzögerungen, Screen-Tearing oder Videos, die nicht so flüssig abgespielt werden, wie sie sollten.
Dieses Szenario wiederholt sich sowohl im häuslichen Umfeld als auch in Unternehmensplattformen, die KVM, Proxmox, VMware, Hyper-V oder die öffentliche Cloud nutzen.Und das Gefühl ist dasselbe: „Der Host funktioniert einwandfrei, aber die VM ist langsam... was mache ich falsch? Benötige ich eine dedizierte GPU, SR-IOV, einen Hypervisorwechsel oder einfach mehr reine CPU-Leistung?“
Grafikleistung in VMs: Was Sie wirklich erwarten können
Als Erstes müssen die Erwartungen angepasst werden: Die Virtualisierung von Desktops mit nahezu nativer 3D-Beschleunigung bleibt eine HerausforderungInsbesondere wenn Sie eine einzelne GPU zwischen einem Host und mehreren virtuellen Maschinen teilen möchten, ohne auf sehr teure oder komplexe Lösungen zurückgreifen zu müssen.
In einem typischen Fall mit Debian 12 als Host über KVM, Ryzen 7 PRO Laptop mit Radeon iGPU und 4K-DisplayDer physische Desktop funktioniert einwandfrei: Fenster lassen sich verzögerungsfrei verschieben, Webseiten laden schnell und 4K-YouTube-Videos werden flüssig wiedergegeben. Auf Linux-VMs mit virtio- oder SPICE-Grafik sinkt die Leistung jedoch: Bei ressourcenintensiven Webseiten und Online-Videos kommt es häufiger zu Verzögerungen, und die Darstellung ist nicht so flüssig wie beim Host..
Beim Testen verschiedener Konfigurationen (VirtIO-GPU-Treiber, SPICE, virgl, verschiedene Remote-Viewer wie virt-viewer, Windows-Clients usw.) wurde Folgendes beobachtet: Die Mauszeiger- und Gesamtreaktionsfähigkeit sind etwas verbessert, aber Bildrisse, Frame-Drops und ein deutliches Gefühl eines weniger "lebendigen" Desktops sind immer noch vorhanden.Dies veranlasst viele dazu, sofort über GPU-Passthrough nachzudenken. Oder sogar die Plattform zu wechseln.
Es ist wichtig zu verstehen, dass dies selbst in leistungsstarken Infrastrukturen der Fall ist. Die Virtualisierung verursacht einen geringen Mehraufwand für CPU, RAM und insbesondere für Festplatten-E/A und Grafikkarte.Bei herkömmlichen Serverlasten (Web, Datenbanken, Microservices) ist dieser Leistungsverlust akzeptabel; aber wenn man anfängt zu fragen Feine grafische Interaktivität, geringe Latenz und flüssige Videowiedergabe, jede Millisekunde zählt.
Virtuelle Maschinen vs. physische Server: Tatsächliche Auswirkungen auf die Leistung
Obwohl wir uns hier auf die Grafik konzentrieren, lohnt es sich, die Virtualisierung in einen Kontext zu setzen. Physische (Bare-Metal-)Server bleiben der Maßstab, wenn es um maximale Leistung und minimale Latenz geht.Insbesondere bei Hochleistungsdatenbanken, 3D-Rendering, KI oder Echtzeit-Streaming.
Typische Benchmark-Tests zeigen, dass eine gut konfigurierte VM auf KVM oder VMware in Bezug auf CPU und RAM nahezu die Leistung eines Bare-Metal-Systems erreicht: Es werden ungefähre Verluste von 5-8 % bei der CPU und 7-13 % beim Arbeitsspeicher erwartet.Die größte Lücke besteht im Bereich des Speichers. Die 4K-IOPS können um 17-25 % sinken, was kritisch ist, wenn Ihre Arbeitslast sehr speicherintensiv ist.
Diese Benachteiligung findet sich auch im Grafikdesign wieder, mit der Nuance, dass Die GPU teilt sich typischerweise Ressourcen mit mehreren VMs, und der Präsentationspfad (SPICE, VNC, RDP, das eigene Protokoll des Hypervisors usw.) führt zu Latenz und Komprimierung.Das Ergebnis: Das System ist „nicht unbrauchbar“, aber im Vergleich zum Hostsystem läuft es weniger reibungslos.
Deshalb gibt es Szenarien, in denen es sich lohnt, bei blankem Metall zu bleiben: große Transaktionsdatenbanken (Oracle, SQL Server Enterprise, SAP HANA), KI/ML-Engines mit leistungsstarken GPUs oder Spiele-/Streaming-Server bei sehr strengen Latenzanforderungen. In diesen Situationen wird der CPU-, Speicher-, E/A- und GPU-Overhead der Virtualisierungsschicht deutlich spürbarer.
Stattdessen Webanwendungen, Microservices, Entwicklungsumgebungen und virtuelle Büroarbeitsplätze —sogar ein Leichtgewichtiger Desktop in Ubuntu— Sie eignen sich hervorragend für VMs. Sie profitieren von Snapshots, hoher Verfügbarkeit und schneller Skalierung, und der geringfügige Leistungsverlust ist absolut akzeptabel.
CPU, RAM, Festplatte und Netzwerk: Welche Kennzahlen sind bei einer langsamen VM zu beachten?
Bevor wir die GPU beschuldigen, müssen wir bestätigen, dass Sie sind nicht durch CPU, Arbeitsspeicher, Festplatte oder Netzwerk eingeschränkt.Viele Probleme mit einem „langsamen Desktop“ sind in Wirklichkeit auf die Überlastung einer anderen Ressource zurückzuführen: Die CPU wartet auf ihre Ausführung, der Swap-Speicher ist stark ausgelastet oder die Festplatte ist am Limit.
In VMware vSphere durchläuft die CPU jeder vCPU beispielsweise vier Zustände: RUN (in Betrieb), WAIT (wartend/E/A oder Leerlauf), READY (in der Warteschlange ohne physische CPU) und COSTOP (Ko-Stopp in Multi-Core-VMs)Hohe READY- oder COSTOP-Werte sind klare Indikatoren für Engpässe und dafür, dass der Host überlastet ist.
Bei CPUs sind die wichtigsten Kennzahlen die Prozentsatz der anhaltenden Auslastung, MHz-Auslastung pro vCPU und Ready/COSTOP-ZählerWenn eine VM konstant zu 90–100 % ausgelastet ist oder sich mehr als 10 % der Zeit im Status „Bereit“ befindet, ist die Maschine überlastet. Das willkürliche Hinzufügen weiterer vCPUs hilft fast nie, wenn der Host bereits stark ausgelastet ist.
Zum Gedenken müssen wir über die Die globale Nutzung umfasst Paging/Swap und, auf Plattformen wie Azure oder Hyper-V, das Auslagern oder Speichern von Auslagerungsdateien auf sekundären Festplatten.Wenn diese Volumes viele Lese-/Schreibvorgänge aufweisen, ist das ein klares Zeichen dafür, dass der VM der Arbeitsspeicher ausgegangen ist.
Auf der Festplatte und im Netzwerk wird Folgendes beobachtet: durchschnittliche Lese-/Schreiblatenz, IOPS und NetzwerkbandbreiteAnhaltende Latenzen von mehr als 15-20 ms auf der Festplatte oder Ausfälle der Verfügbarkeit und Timeouts bei Remote-Speichern (Azure Storage, SAN usw.) beeinträchtigen die wahrgenommene Leistung auf dem Remote-Desktop direkt.
Ãœberwachungs- und Diagnosetools: von ESXTOP bis Azure Monitor
Führende Hersteller bieten ausgereifte Tools zur Analyse der Leistung einer virtuellen Maschine an. Einige Beispiele:
- VMware: vCenter und ESXTOP.
- Azure: Azure Monitor und PerfInsights.
- Hyper-V: Leistungsmonitor und PowerShell.
- KVM/Proxmox: Kombinationen wie top, htop, iostat, virt-top und die Weboberfläche selbst.
ESXTOP ist ein Klassiker für Echtzeitanalysen. Es ermöglicht Ihnen, alle paar Sekunden Metriken pro vCPU anzuzeigen, wie zum Beispiel: %USED, %RUN, %SYS, %WAIT, %IDLE, %RDY, %CSTP, %MLMTD und vieles mehr. Die Grundregel: Wenn %RDY oder %CSTP sprunghaft ansteigen, gibt es zu viele vCPUs oder zu viele VMs für den Host.
In Azure erhalten Sie durch die Aktivierung der Diagnose auf VM- und Speicherkontoebene Diagramme von CPU, Speicher, Festplatte und NetzwerkZusätzlich werden Kennzahlen zu Verfügbarkeit, Latenz, Drosselung und Speichertimeout-Fehlern erfasst. Diese Informationen helfen, zwischen einem Plattformproblem und einem Engpass auf Ihrer Seite aufgrund übermäßiger IOPS oder eines zu hohen Durchsatzes zu unterscheiden.
In Hyper-V ist die Arbeit aufgeteilt zwischen Hyper-V-Manager, Leistungsmonitor, Ressourcenmonitor und PowerShell-CmdletsSie können physische vs. logische Kerne, NUMA, VHDX-Festplatten, virtuelle Adapter, Festplattenwarteschlangen und vieles mehr untersuchen, um genau festzustellen, welches Teil nicht optimal funktioniert.
Abgesehen von den Herstellerangaben empfehlen viele Ratgeber die Verwendung von spezifische Stresstests: sysbench für die CPU, stress-ng und memtester für den Arbeitsspeicher, fio für die Festplatten-E/A, iperf3 oder netperf für das Netzwerk. Dies ermöglicht einen einfachen Vergleich von Bare-Metal-Systemen und virtuellen Maschinen und zeigt die Grenzen der einzelnen Hypervisoren auf.
GPU-Virtualisierung: SR-IOV, Passthrough und proprietäre Lösungen
Wenn der Flaschenhals eindeutig grafischer Natur ist (Screen Tearing, niedrige Bildrate, langsame Animationen, ruckelndes Video), ist es an der Zeit, sich die GPU-VirtualisierungHierbei handelt es sich um drei Hauptlösungsfamilien:
- GPU-Passthrough (PCI-Passthrough)Einer einzelnen VM wird eine vollständige Grafikkarte zugewiesen. Dies bietet nahezu native Leistung, jedoch mit offensichtlichen Einschränkungen: Die GPU steht dem Host und anderen VMs nicht mehr zur Verfügung, und in der Regel wird ein dedizierter Videoausgang für diese VM benötigt, was nicht ideal ist, wenn alles auf demselben Bildschirm angezeigt werden soll.
- GPU-Virtualisierung durch SR-IOV (Single Root I/O Virtualization)Es ermöglicht die Bereitstellung virtueller GPU-Funktionen (VFs) für verschiedene VMs. Die Idee ist sehr attraktiv: die gemeinsame Nutzung von Grafikhardware mit minimalem Overhead. Intel fördert diesen Ansatz bei seinen Xe2 iGPUs für Laptops (wie Lunar Lake) und bei Rechenzentrums-GPUs (Flex), während AMD und NVIDIA diese Funktion primär für andere Anwendungen reservieren. sehr teure Visitenkarten Hinzu kommt, dass es oft Lizenz- und Abonnementmodelle gibt, die für Privatanwender oder kleine Unternehmen nicht sehr benutzerfreundlich sind.
- SR‑IOVDiese Lösung Es ist für VMs nicht völlig transparent, erfordert spezifische Treiber, BIOS-/Firmware- und Hypervisor-Unterstützung und kann eigene Kompatibilitätsprobleme mit sich bringen.Es lohnt sich nicht immer, die gesamte Hardware aufzurüsten (zum Beispiel einen Laptop mit Intel Lunar Lake nur dafür zu kaufen), wenn der Rest des Arbeitsablaufs durch andere Faktoren weiterhin eingeschränkt bleibt. PC-Hardwareanalyse hilft bei der Entscheidungsfindung.
- Proprietäre GPU-VirtualisierungslösungenBeispiele hierfür sind NVIDIA RTX vWS, NVIDIA VGX und deren Nachfolger. Diese kombinieren spezielle Hardware (z. B. VGX K1/K2-Karten mit mehreren Kepler-GPUs, großen Mengen an GDDR5-Speicher und Tausenden von CUDA-Kernen) mit einem GPU-Hypervisor, der die Verteilung der Grafikleistung auf Dutzende virtueller Desktops ermöglicht.
Teilweise GPU-Technologien in Desktop-Umgebungen: virtio-gpu, virgl und SPICE
Für diejenigen, die KVM, QEMU, Proxmox oder ähnliches verwenden, verläuft die übliche Vorgehensweise wie folgt: Paravirtualisierte Grafikcontroller wie virtio-gpu, kombiniert mit Remote-Desktop-Protokollen wie SPICEAuf der Gastseite wird ein Treiber installiert, der dieses virtuelle Gerät "versteht" und eine gewisse grundlegende 2D/3D-Beschleunigung ermöglicht.
VirGL ist eine zusätzliche Schicht, die Übersetzt OpenGL-Aufrufe vom Gastsystem an die Host-GPUEine Anwendung innerhalb der VM nutzt somit indirekt die reale 3D-Beschleunigung. Theoretisch sollte dies die Grafikleistung des Desktops und der Anwendungen verbessern. In der Praxis tritt jedoch mitunter das Gegenteil ein. Ist die integrierte GPU des Hosts zu schwach oder die Implementierung nicht ausgereift, ist ein deutlicher Leistungsabfall spürbar.
Tatsächlich berichten viele Nutzer mit AMD-iGPUs (z. B. Renoir), dass beim Aktivieren von VirGL die Der VM-Desktop wird deutlich langsamer und ressourcenintensiver.So sehr, dass es sogar schlechter ist als die Verwendung von Virtio-GPU „ohne GPU“. Das heißt nicht, dass VirGL nutzlos ist, aber es hängt stark von der Kombination ab. Hardware + Treiber + VM-Grafiklast.
Bei Proxmox das Trio virtio-gpu + SPICE + virt-viewer Dies ist üblicherweise die minimale sinnvolle Konfiguration für einen grafischen Linux-Desktop. Sie ermöglicht einen ordentlichen Mauszeiger, die Anpassung der Fenstergröße und eine bessere Bildkomprimierung als einfaches VNC, aber dennoch… Erwarten Sie nicht die gleiche Benutzererfahrung wie mit der VMware ESXi-Remotekonsole oder VMRC., die nach jahrelanger Optimierung einen hohen Grad an Perfektion erreicht haben.
Deshalb sind viele Administratoren, die von ESXi kommen, überrascht, wenn sie Proxmox ausprobieren. Trotz eines sehr leistungsstarken Hypervisors, Das Gefühl der „Schnelligkeit“ des Remote-Desktops ist geringer Es sei denn, man nimmt viele Feineinstellungen vor oder verwendet eine dedizierte GPU.
Wann lohnt sich GPU-Passthrough und wann nicht?
GPU-Passthrough ist nach wie vor die leistungsstärkste Option für eine bestimmte VM. Im alltäglichen Desktop-Einsatz gibt es jedoch einige Nachteile. Zum Beispiel: Bedarf an einem weiteren Monitoreingang, Verlust der GPU für den Host, zusätzliche Komplikationen (IOMMU, Gruppen, BIOS, Treiber, Fehler beim Ruhezustand usw.)..
Wenn Ihr Ziel ist, dass Eine einzelne VM verfügt über volle 3D-Beschleunigung.Der Aufwand lohnt sich in der Regel. Projekte wie Looking Glass ermöglichen es, das VM-Image in den Host-Desktop „wieder einzubinden“, um zusätzliche Monitore zu vermeiden. Aber wenn Sie Folgendes möchten: mehrere Büro- oder Test-VMs mit guten GrundkenntnissenDie Übertragung einer GPU auf jedes Gerät ist nicht praktikabel.
Für leistungsstarke Desktop-Computer können Sie eine Hybridkombination in Betracht ziehen: Primäre GPU für den Host und Durchleitung einer zweiten, leistungsschwächeren GPU für eine bestimmte VMAuf diese Weise bleibt ein gut nutzbarer Host-Desktop erhalten, und die VM erhält eine grafische Umgebung, die der nativen sehr nahe kommt; Laptop-Analyse Es kann einen Überblick über Desktop-Alternativen im Vergleich zu Laptops bieten.
Bei Laptops wird die Sache komplizierter. Sie haben normalerweise eine einzelne iGPU (oder iGPU + dGPU, die eng mit der Firmware integriert ist)Bei begrenzten Ressourcen und ohne realistische Möglichkeit, eine weitere Grafikkarte einzubauen, ist Passthrough selten sinnvoll. Es ist sinnvoller, paravirtualisierte Optionen (virtio-gpu, SPICE, RDP) zu nutzen, um die Grafikanforderungen der VMs zu reduzieren.
Zusammenfassend Passthrough ist das richtige Werkzeug für einige wenige, sehr anspruchsvolle VMs.Bei Laboren mit vielen Rechnern oder leichten Desktop-PCs liegt der Fokus eher auf der Anpassung des Hypervisors, der Kontrolle des CPU/RAM/I/O-Overheads und der Auswahl des richtigen Remote-Desktop-Protokolls.
Hypervisoren, NUMA, dynamischer Speicher und andere Leistungsfaktoren
Abgesehen von der GPU, die Art und Weise, wie der Hypervisor verwaltet CPU, Arbeitsspeicher, Speicher und Netzwerk Es beeinflusst direkt die wahrgenommene Flüssigkeit des VM-Desktops. Hyper-V, KVM, VMware und andere verfolgen zwar etwas unterschiedliche Ansätze, basieren aber alle auf gemeinsamen Konzepten.
Die Hyper-V-Architektur basiert beispielsweise auf einer Hypervisor, der den Zugriff auf die Hardware steuert, eine Root-Partition mit dem Managementsystem und sekundäre Partitionen für die VMs.Unterstützt wird dies durch Technologien wie virtuelles NUMA, dynamischen Speicher, virtuelle Switches, Netzwerk-SR-IOV und Speicheroptimierungen wie ODX.
NUMA (Non-Uniform Memory Access) ist besonders wichtig bei Servern mit vielen Kernen. Wenn eine große VM schlecht auf physische NUMA-Knoten aufgeteilt ist, erhöht sich ihre Speicherlatenz. Die Leistung leidet, selbst wenn auf dem Papier ausreichend Ressourcen vorhanden zu sein scheinen. Idealerweise sollte die vNUMA-Topologie der VM mit der pNUMA-Topologie des Hosts übereinstimmen.
Dynamischer Speicher (in Hyper-V, Ballooning in anderen Hypervisoren) kann globalen RAM einsparen, aber Für latenzempfindliche Arbeitslasten wie Datenbanken oder Desktop-Computer mit vielen geöffneten Anwendungen ist es nicht optimal geeignet.In solchen Fällen ist es ratsam, einen festen Speicherbereich zuzuweisen, um Pausen zu vermeiden, wenn der Hypervisor beschließt, den gesamten RAM auf einmal freizugeben.
Die Lagerung ist mit Abstand der häufigste Engpass. Es wird empfohlen, Verwenden Sie VHDX-Festplatten mit fester Größe, trennen Sie System- und Datenfestplatten, entscheiden Sie sich für SSDs oder NVMe-Laufwerke der Enterprise-Klasse und vermeiden Sie RAID-Konfigurationen mit schlechtem Schreibverhalten (RAID 5/6) bei intensiven Arbeitslasten.Wo verfügbar, tragen Storage Spaces Direct- oder NVMe-Arrays dazu bei, die Latenzzeiten in einem akzeptablen Rahmen zu halten.
In einem Netzwerk ist es ratsam, Folgendes zu konfigurieren: Externe virtuelle Switches an schnellen Netzwerkkarten (wenn möglich 10 GbE), NIC-Teaming nutzen, SR-IOV für sehr hohe Netzwerklasten aktivieren und MTU und Offloads optimieren. Nur wenn die gesamte Netzwerkkette dies unterstützt. Eine mangelhafte Netzwerkkonfiguration kann dazu führen, dass ein Remote-Desktop, selbst mit einer guten GPU, schlechter als erwartet aussieht.
Stresstests und Anwendungsfälle: Wann ist eine virtuelle Maschine oder eine physische Anlage die richtige Wahl?
Um zu entscheiden, ob eine Grafik-Workload auf eine VM migriert oder auf physischen Datenträgern belassen werden soll, ist Folgendes wichtig: Tests mit Benchmarks und Stresstests Sie sollten die CPU-, RAM-, Festplatten- und Netzwerkauslastung messen. Wenn möglich, auch die GPU-Auslastung. Idealerweise sollte die „reale“ Anwendung mit derselben Anwendung in einer virtuellen Maschine verglichen werden.
Ein realistisches Muster könnte sein: Führen Sie sysbench oder Geekbench für die CPU, stress-ng oder memtester für den Arbeitsspeicher, fio für 4K-IOPS und Festplattenlatenz sowie iperf3 für die Netzwerkbandbreite aus.und einige grundlegende Grafik-Benchmarks (z. B. glxgears oder ein browserbasierter WebGL-Test) sowohl auf dem Host als auch auf der VM.
Wenn der Leistungsverlust innerhalb akzeptabler Grenzen liegt (zum Beispiel, Weniger als 10 % CPU-/RAM-Auslastung und ein Leistungsverlust von 15–20 % beim FestplattenspeicherWenn die Remote-Desktop-Verbindung für den vorgesehenen Zweck (Büroautomation, Administration, einfache Entwicklung) ausreichend reibungslos funktioniert, ist Virtualisierung eine durchaus sinnvolle Option.
Wenn die Anwendung hingegen stark auf Folgendes angewiesen ist GPU, geringe Latenz und hoher, dauerhafter E/A-Durchsatz Bei Anwendungen wie Rendering in Blender, aufwändigen CAD-Anwendungen, dem Training großer Modelle mit KI-Engines, Spielen usw. ist das Erlebnis in der Regel auf einem physischen Server mit dedizierter GPU oder auf einer professionellen GPU-Passthrough-/virtualisierten VM deutlich besser.
Der Schlüssel liegt darin, herauszufinden, welche Komponente (bereite CPU, unzureichender Arbeitsspeicher, gedrosselte E/A, fehlende echte GPU, langsames Netzwerk oder schlecht optimiertes Desktop-Protokoll) die jeweilige VM verlangsamt. Wenden Sie die einfachste und kostengünstigste Lösung für diesen Fall an.und die hohen Investitionen (dedizierte GPUs, SR-IOV, professionelle Hardware) für die Arbeitslasten aufzubewahren, bei denen sie wirklich einen Unterschied machen.