Begrenzt QEMU die Performance virtueller Maschinen unter Proxmox?
QEMU fügt jeder virtuellen Maschine unter Proxmox etwas Overhead hinzu, ist aber selten der Hauptgrund für eine schlecht performende Workload. Proxmox kombiniert QEMU mit KVM, sodass die meisten Prozessorbefehle des Gasts über die Virtualisierungsfunktionen des physischen Prozessors laufen können, statt vollständig in Software übersetzt zu werden.
Performance-Probleme werden häufiger durch ungeeignete virtuelle Hardware, langsamen Storage, übermäßige Ressourcenzuteilung, Speicherdruck oder schlechtes Netzwerkdesign verursacht. Mit den richtigen Einstellungen können viele virtuelle Maschinen unter Proxmox nahe an vergleichbare physische Systeme herankommen.
Wie wirkt sich QEMU auf die Performance aus?
QEMU erzeugt den virtuellen Computer, den das Gastbetriebssystem sieht. Es stellt virtuelle Prozessoren, Arbeitsspeicher, Storage-Controller, Netzwerkschnittstellen, Firmware und andere Geräte bereit.
KVM stellt unterhalb von QEMU die hardwarebeschleunigte Prozessorvirtualisierung bereit. Ist die KVM-Beschleunigung aktiv, können Prozessorbefehle des Gasts effizient über Intel VT-x oder AMD-V laufen. QEMU koordiniert weiterhin die virtuelle Maschine und verarbeitet die Aktivität, die mit virtuellen Geräten verbunden ist.
Das erzeugt Overhead, weil der Gast über virtuelle Hardware kommunizieren muss, bevor er das physische Storage-, Netzwerk- oder Grafikgerät erreicht. Wie viel Overhead entsteht, hängt stark vom virtuellen Gerätemodell ab.
Eine emulierte Netzwerkkarte versucht, das Verhalten physischer Hardware nachzubilden. Jede Interaktion muss zusätzliche Emulationslogik durchlaufen. Ein VirtIO-Gerät ist speziell für virtualisierte Systeme konzipiert und kommuniziert direkter mit dem Host. Proxmox beschreibt VirtIO-Networking als Lösung mit der besten Performance bei sehr geringem Prozessor-Overhead.
QEMU ist deshalb Teil des Performance-Pfads, aber Administratoren haben erheblichen Einfluss darauf, wie effizient dieser Pfad wird.
Nutzt eine Proxmox-VM Software-Emulation?
Eine normale virtuelle Maschine unter Proxmox sollte die KVM-Hardwarebeschleunigung nutzen.
QEMU kann ohne KVM per Software-Übersetzung laufen, aber dieser Modus ist wesentlich langsamer und vor allem nützlich, wenn eine andere Prozessorarchitektur als die des Hosts emuliert wird.
Ist die Hardware-Virtualisierung in der Server-Firmware deaktiviert, für das Betriebssystem nicht verfügbar oder durch einen äußeren Hypervisor verborgen, kann die virtuelle Maschine KVM möglicherweise nicht richtig nutzen. Das kann zu einem drastischen Performance-Verlust führen.
Administratoren sollten prüfen, ob die Virtualisierungserweiterungen aktiviert sind, bevor sie kleinere Performance-Anpassungen vornehmen. Das Ändern von Disk-Cache-Einstellungen gleicht fehlende Hardwarebeschleunigung nicht aus.
Spielt der virtuelle CPU-Typ eine Rolle?
Das gewählte CPU-Modell kann sowohl Performance als auch Kompatibilität beeinflussen.
Proxmox kann dem Gast ein standardisiertes Prozessormodell präsentieren. Das erlaubt es virtuellen Maschinen, zwischen Cluster-Knoten mit unterschiedlichen Generationen physischer Prozessoren zu migrieren. Der Nachteil ist, dass manche neueren Prozessorbefehle dem Gast verborgen bleiben können.
Wird der virtuelle CPU-Typ auf host gesetzt, werden die Fähigkeiten des physischen Host-Prozessors direkter freigelegt. Proxmox gibt an, dass der Gast dadurch eine exakte Übereinstimmung mit den CPU-Flags des Hosts erhält. Das kann die Performance für Workloads verbessern, die von neueren Befehlssätzen, Verschlüsselungserweiterungen oder speziellen Prozessorfunktionen profitieren.
Der Preis dafür ist reduzierte Migrationsflexibilität. Eine virtuelle Maschine mit dem CPU-Typ host kann möglicherweise nicht zu einem Knoten mit einem anderen oder älteren Prozessor migrieren.
Nutzen Sie den CPU-Typ host für performance-sensitive virtuelle Maschinen, die auf kompatibler Hardware bleiben. Nutzen Sie ein gemeinsames Cluster-CPU-Modell, wenn zuverlässige Live-Migration wichtiger ist als jeden verfügbaren Befehl freizulegen.
Mehr virtuelle Prozessoren hinzuzufügen macht eine VM nicht automatisch schneller. Jede virtuelle CPU wird zu einem planbaren Thread auf dem Proxmox-Host. Einer Anwendung mit wenig Threads sechzehn virtuelle Prozessoren zu geben, kann den Scheduling-Aufwand erhöhen, ohne die Performance zu verbessern.
Beginnen Sie mit der Anzahl, die die Anwendung nutzen kann, und erhöhen Sie sie erst, nachdem Sie die Prozessorauslastung gemessen haben.
Begrenzen virtuelle Disk-Einstellungen die Performance?
Die Disk-Konfiguration ist eine der häufigsten Ursachen für schlechte Performance virtueller Maschinen.
Proxmox unterstützt mehrere emulierte und paravirtualisierte Storage-Controller. Die aktuelle Dokumentation empfiehlt, VirtIO SCSI single zu verwenden und einen IO Thread auf angehängten Disks zu aktivieren, wenn Performance Priorität hat.
Ein IO Thread verlagert unterstützte Storage-Arbeit weg von QEMUs Haupt-Event-Loop. QEMU erklärt, dass zusätzliche IO Threads Arbeit auf separate Event-Loops verteilen können, was die Konkurrenz um den Haupt-Loop reduziert und Storage-Latenz sowie Jitter beim Gast potenziell verbessert.
Das zählt am meisten für stark ausgelastete Datenbankserver, Storage-Appliances und virtuelle Maschinen, die viele gleichzeitige Disk-Anfragen erzeugen. Ein leicht ausgelasteter Webserver zeigt möglicherweise kaum einen sichtbaren Unterschied.
Der zugrunde liegende Storage bleibt entscheidend. VirtIO kann ein langsames Festplatten-Array nicht wie schnellen Solid-State-Storage verhalten lassen. Proxmox hängt weiterhin von Latenz, Queue-Tiefe, Cache-Absicherung und Netzwerk-Performance des gewählten Storage-Backends ab.
Administratoren sollten den gesamten Storage-Pfad testen, einschließlich des Gast-Dateisystems, des virtuellen Controllers, der Proxmox-Storage-Schicht und der physischen Disks.
Spielt der Disk-Cache-Modus eine Rolle?
QEMU unterstützt mehrere Disk-Cache-Modi. Der gewählte Modus ändert, wie Daten durch den Page Cache des Hosts laufen und wann Schreibvorgänge als abgeschlossen gemeldet werden.
Write-Back-Caching kann starke Performance liefern, hängt aber von zuverlässigem Storage und Stromabsicherung ab. Ein plötzlicher Ausfall kann kürzlich bestätigte Schreibvorgänge gefährden, wenn sie den persistenten Storage noch nicht erreicht haben.
Direct- oder No-Cache-Konfigurationen können doppeltes Caching zwischen Gast und Host vermeiden, aber die Performance hängt von Workload und Storage-System ab. QEMU weist darauf hin, dass Cache- und asynchrone Ein-/Ausgabe-Einstellungen einen erheblichen Performance-Einfluss haben können.
Es gibt keine universell schnellste, sichere Einstellung. Eine Datenbank mit synchronen Schreibvorgängen hat andere Anforderungen als ein temporärer Build-Server.
Benchmarken Sie mit realistischen Workloads und stellen Sie sicher, dass die gewählte Konfiguration die von der Anwendung benötigten Persistenzgarantien einhält.
Erzeugt virtuelles Networking einen Engpass?
Virtuelles Networking bringt Verarbeitungs-Overhead mit sich, auch wenn VirtIO-Netzwerkadapter darauf ausgelegt sind, diesen Overhead gering zu halten.
Ein emulierter Adapter kann nützlich sein, wenn ein altes Betriebssystem ohne VirtIO-Treiber installiert wird. Er sollte normalerweise nicht die langfristige Wahl für einen modernen Linux- oder Windows-Gast bleiben.
Windows benötigt die passenden VirtIO-Treiber. Die meisten aktuellen Linux-Distributionen bringen VirtIO-Unterstützung bereits im Kernel mit.
Die Netzwerk-Performance hängt auch von Proxmox-Bridges, VLANs, Firewall-Regeln, physischen Netzwerkadaptern und vorgelagerten Switches ab. Eine virtuelle Maschine kann die Fähigkeiten der physischen Verbindung oder der Storage-Quelle, die die Daten liefert, nicht übertreffen.
Multiqueue-Networking kann den Durchsatz für stark ausgelastete virtuelle Maschinen verbessern, indem die Netzwerkverarbeitung mehrere Queues und Prozessorkerne nutzen kann. Es kann auch die Prozessorauslastung erhöhen, weshalb die Anzahl der Queues auf die Workload abgestimmt werden sollte, statt sie ungetestet auf den höchstmöglichen Wert zu setzen.
Verringert Speichervirtualisierung die Performance?
Der Arbeitsspeicher einer virtuellen Maschine muss zwischen virtuellen Gastadressen, physischen Gastadressen und physischem Host-Speicher übersetzt werden. Moderne Prozessoren beschleunigen diese Übersetzungen, aber speicherintensive Workloads können trotzdem Overhead erfahren.
Huge Pages können die Anzahl der Translation-Lookaside-Buffer-Misses reduzieren, indem sie größere Speicherbereiche mit weniger Einträgen abbilden. Die Linux-Kernel-Dokumentation weist darauf hin, dass Huge Pages erhebliche Virtualisierungsvorteile bringen können, selbst wenn nur eine Seite der Host-Gast-Kombination sie nutzt.
Huge Pages sind vor allem für große Datenbanken, Analytics-Systeme und andere Workloads mit umfangreichen Speicher-Working-Sets relevant. Sie reservieren oder verbrauchen Speicher in größeren Einheiten und können die Flexibilität verringern, wenn der Host unter Speicherdruck steht.
Memory Ballooning bietet einen anderen Kompromiss. Es erlaubt Proxmox, die Speichernutzung des Gasts anzupassen und bessere Nutzungsinformationen zu sammeln. Ballooning kann die Host-Auslastung verbessern, aber performance-sensitive Workloads profitieren im Allgemeinen von vorhersehbarer Speicherverfügbarkeit.
Vermeiden Sie aggressives Memory-Overcommitment bei Datenbanken und latenzsensiblen Services. Sobald der Host anfängt zu swappen, kann die daraus resultierende Storage-Aktivität jeden Gewinn durch CPU- oder VirtIO-Tuning zunichtemachen.
Kann Device-Passthrough den QEMU-Overhead entfernen?
PCI-Passthrough weist einer virtuellen Maschine ein physisches Gerät direkt zu. Das kann nahezu nativen Zugriff auf Grafikkarten, Netzwerkadapter, Storage-Controller und andere Hardware ermöglichen.
Passthrough reduziert die von QEMU übernommene Verarbeitung virtueller Geräte, schafft aber operative Einschränkungen. Die virtuelle Maschine wird von Hardware abhängig, die in einem bestimmten Knoten verbaut ist. Live-Migration und automatische High-Availability-Wiederherstellung werden schwieriger.
Passthrough erfordert außerdem geeignete IOMMU-Isolation und kompatible Hardware.
Nutzen Sie es, wenn die Workload wirklich direkten Gerätezugriff braucht. Für die meisten gewöhnlichen Server-Workloads ist es unnötig, da VirtIO dort bessere Portabilität und ausreichende Performance bietet.
Wie sollten Sie die QEMU-Performance messen?
Vergleichen Sie die Performance anhand von Tests auf Anwendungsebene, statt sich nur auf synthetische Benchmarks zu verlassen.
Eine Datenbank sollte mit ihrem erwarteten Transaktionsmuster getestet werden. Ein Dateiserver sollte mit realistischen Dateigrößen und gleichzeitigen Nutzern getestet werden. Eine Webanwendung sollte unter repräsentativen Anfragen gemessen werden.
Überwachen Sie während des Tests sowohl den Gast als auch den Proxmox-Host. Eine virtuelle Maschine mit hoher Disk-Latenz wartet möglicherweise auf den physischen Storage. Ein Gast, der ungenutzte Prozessorkapazität meldet, kann trotzdem verzögert sein, weil der Host überlastet ist.
Ändern Sie jeweils nur eine Einstellung. Wenn Sie CPU-Typ, Disk-Controller, Cache-Modus und Netzwerkadapter gleichzeitig austauschen, wird es schwierig zu erkennen, welche Anpassung geholfen oder ein neues Problem verursacht hat.
Begrenzt QEMU die Performance von Proxmox?
QEMU bringt unvermeidbaren Virtualisierungs-Overhead mit sich, hindert aber virtuelle Maschinen unter Proxmox normalerweise nicht daran, starke Performance zu liefern.
Schlechte Ergebnisse hängen häufiger mit emulierten Geräten, falschen CPU-Modellen, langsamem Storage, fehlenden IO Threads, Memory-Overcommitment oder übermäßiger Zuteilung virtueller Prozessoren zusammen.
Nutzen Sie KVM-Hardwarebeschleunigung, VirtIO-Netzwerkadapter, wo passend VirtIO SCSI single mit IO Threads und für die Workload ausgelegten Storage. Ziehen Sie das Host-CPU-Modell, Huge Pages und Device-Passthrough nur in Betracht, wenn ihr Performance-Vorteil den Verlust an Portabilität oder Flexibilität rechtfertigt.
QEMU ist in einer gut konfigurierten Proxmox-Umgebung selten der Haupt-Engpass. Das gesamte Infrastrukturdesign entscheidet darüber, ob die virtuelle Maschine gut performt.