Als je serieus aan de slag gaat met moderne virtualisatie, loop je vroeg of laat tegen een terugkerend probleem aan: Virtuele machines bieden zelden dezelfde grafische prestaties als het besturingssysteem dat direct op de hardware is geïnstalleerd.Hoewel het bureaublad van de hostcomputer zelfs in 4K soepel kan werken, kan het bureaublad van de virtuele machine haperen, met vertraging van de muis, schermscheuren of video's die niet zo vloeiend afspelen als zou moeten.
Dit scenario herhaalt zich zowel in huiselijke omgevingen als in Bedrijfsplatformen die gebruikmaken van KVM, Proxmox, VMware, Hyper-V of de publieke cloud.En het gevoel is steeds hetzelfde: "De host werkt perfect, maar de VM is traag... wat doe ik verkeerd? Heb ik een dedicated GPU, SR-IOV nodig, moet ik van hypervisor wisselen, of heb ik gewoon meer rekenkracht nodig?"
Grafische prestaties in virtuele machines: wat je er echt van kunt verwachten
Het eerste wat we moeten doen, is de verwachtingen bijstellen: Het virtualiseren van desktops met "bijna native" 3D-acceleratie blijft een uitdaging.Vooral handig als je één GPU wilt delen tussen een host en meerdere virtuele machines zonder je toevlucht te nemen tot zeer dure of complexe oplossingen.
In een typisch geval met Debian 12 als host via KVM, Ryzen 7 PRO-laptop met Radeon iGPU en 4K-scherm.De fysieke desktop werkt perfect: vensters verplaatsen gaat direct, websites laden snel en 4K YouTube speelt vloeiend af. Op Linux VM's met virtio of SPICE-graphics daalt de prestatie echter: Zware webpagina's en online video's ondervinden meer vertraging en de weergave is niet zo vloeiend als bij de hostingprovider..
Bij het testen van verschillende configuraties (VirtIO-GPU-stuurprogramma, SPICE, virgl, verschillende externe viewers zoals virt-viewer, Windows-clients, enz.) werd geconstateerd dat De muisaanwijzer en de algehele responsiviteit zijn enigszins verbeterd, maar tearing, haperingen en een duidelijk minder "levendig" bureaublad zijn nog steeds aanwezig.Dit leidt ertoe dat veel mensen meteen GPU-passthrough overwegen. Of zelfs overstappen naar een ander platform.
Het is belangrijk te begrijpen dat zelfs in krachtige infrastructuren, Virtualisatie brengt een kleine extra belasting met zich mee voor de CPU, het RAM-geheugen en met name de schijf-I/O en de grafische kaart.Bij traditionele serverbelastingen (web, databases, microservices) is die prestatievermindering acceptabel; maar wanneer je begint te vragen... Uitstekende grafische interactie, lage latentie en vloeiende video.Elke milliseconde telt.
Virtuele machines versus fysieke servers: de werkelijke impact op de prestaties
Hoewel we ons hier richten op grafische weergave, is het de moeite waard om virtualisatie in de juiste context te plaatsen. Fysieke (bare metal) servers blijven de maatstaf als je op zoek bent naar pure prestaties en minimale latentie.Met name in krachtige databases, 3D-rendering, AI of realtime streaming.
Uit typische benchmarktests blijkt dat een goed geconfigureerde VM op KVM of VMware qua CPU- en RAM-prestaties vrijwel gelijk is aan een fysieke server: Geschatte verliezen van 5-8% in de CPU en 7-13% in het geheugen.Het grootste probleem zit hem in de opslagcapaciteit. De 4K IOPS kan met 17-25% dalen, wat cruciaal is als uw workload veel schijfactiviteit vereist.
Deze strafmaatregel is ook terug te vinden in het grafisch ontwerp, met de nuance dat De GPU deelt doorgaans resources met meerdere virtuele machines, en het presentatiepad (SPICE, VNC, RDP, het eigen protocol van de hypervisor, enz.) voegt latentie en compressie toe.Het resultaat: het systeem is "niet onbruikbaar", maar vergeleken met de host voelt het minder soepel aan.
Daarom zijn er scenario's waarin het loont om bij bare metal te blijven: grote transactionele databases (Oracle, SQL Server Enterprise, SAP HANA), AI/ML-engines met krachtige GPU's of game-/streamingservers met zeer strenge latentie-eisen. In deze situaties wordt de overhead van de virtualisatielaag voor CPU, geheugen, I/O en GPU veel merkbaarder.
Plaats, webapplicaties, microservices, ontwikkelomgevingen en virtuele kantoordesktops —zelfs een lichtgewicht desktopomgeving in Ubuntu— Ze passen heel goed in virtuele machines. Ze profiteren van snapshots, hoge beschikbaarheid en snelle schaalbaarheid, en het lichte prestatieverlies is volkomen acceptabel.
CPU, RAM, schijf en netwerk: welke statistieken moet je bekijken bij een trage virtuele machine?
Voordat we de GPU de schuld geven, moeten we eerst bevestigen dat Je bent niet beperkt door CPU, geheugen, schijf of netwerk.Veel problemen met een "trage desktop" worden in werkelijkheid veroorzaakt door overbelasting van een andere bron: de CPU die op zijn beurt wacht, intensief swapgeheugen of de schijf die zijn limiet bereikt.
In VMware vSphere doorloopt de CPU van elke vCPU bijvoorbeeld vier toestanden: RUN (actief), WAIT (wachtend/I/O of inactief), READY (in de wachtrij zonder fysieke CPU) en COSTOP (co-stop in multi-core VM's)Hoge READY- of COSTOP-waarden zijn duidelijke indicatoren van concurrentie en dat de host overbelast is.
Voor CPU's zijn de belangrijkste meetwaarden de Percentage continu gebruik, MHz-gebruik per vCPU en Ready/COSTOP-tellersAls een virtuele machine constant voor 90-100% wordt gebruikt, of meer dan 10% van de tijd in de status 'gereed' is, dan heeft die machine het moeilijk. Het lukraak toevoegen van meer vCPU's helpt vrijwel nooit als de host al overbelast is.
Ter nagedachtenis moeten we waken over de Wereldwijd wordt het gebruikt voor paging/swap en, op platforms zoals Azure of Hyper-V, voor paging- of swapbestanden op secundaire schijven.Als die volumes veel lees- en schrijfbewerkingen vertonen, is dat een duidelijk teken dat de virtuele machine geen RAM-geheugen meer heeft.
Op de schijf en in het netwerk wordt het volgende waargenomen: gemiddelde lees-/schrijflatentie, IOPS en netwerkbandbreedteAanhoudende latentie van meer dan 15-20 ms op de schijf of beschikbaarheidsverlies en time-outs in externe opslag (Azure Storage, SAN, enz.) zijn directe vijanden van de waargenomen prestaties van het externe bureaublad.
Monitoring- en diagnostische tools: van ESXTOP tot Azure Monitor
Grote fabrikanten bieden goed ontwikkelde tools voor het analyseren van de prestaties van een virtuele machine. Enkele voorbeelden:
- VMware: vCenter en ESXTOP.
- Azure: Azure Monitor en PerfInsights.
- Hyper-V: Prestatiemonitor en PowerShell.
- KVM/Proxmox: combinaties zoals top, htop, iostat, virt-top en de webinterface zelf..
ESXTOP is een klassieker voor realtime-analyse. Hiermee kunt u elke paar seconden statistieken per vCPU bekijken, zoals... %GEBRUIKT, %UITGEVOERD, %SYS, %WACHTEN, %INACTIEF, %RDY, %CSTP, %MLMTD En nog veel meer. De basisregel: als %RDY of %CSTP piekt, heb je te veel vCPU's of te veel VM's voor de host.
In Azure biedt het inschakelen van diagnostiek op VM- en opslagaccountniveau grafieken van CPU, geheugen, schijf en netwerkSamen met statistieken over beschikbaarheid, latentie, throttling en time-outfouten bij opslag. Deze informatie helpt onderscheid te maken tussen een platformprobleem en een knelpunt aan uw kant als gevolg van te hoge IOPS of doorvoer.
In Hyper-V is het werk verdeeld over Hyper-V Manager, Performance Monitor, Resource Monitor en PowerShell-cmdletsJe kunt fysieke versus logische cores, NUMA, VHDX-schijven, virtuele adapters, schijfwachtrijen en nog veel meer inspecteren om te achterhalen welk onderdeel tekortschiet.
Naast de aanbevelingen van de fabrikant, raden veel handleidingen aan om het volgende te doen: specifieke stresstestsGebruik sysbench voor de CPU, stress-ng en memtester voor het RAM-geheugen, fio voor schijf-I/O, iperf3 of netperf voor het netwerk. Hiermee kun je eenvoudig de prestaties van een fysieke hardwareomgeving vergelijken met die van een virtuele machine en de beperkingen van elke hypervisor inzien.
GPU-virtualisatie: SR-IOV, passthrough en eigen oplossingen
Als het knelpunt duidelijk grafisch van aard is (screen tearing, lage framesnelheid, trage animaties, haperende video), is het tijd om naar de GPU-virtualisatieEr zijn hier drie hoofdcategorieën oplossingen:
- GPU-passthrough (PCI-passthrough)Een volledige grafische kaart wordt toegewezen aan één virtuele machine (VM). Dit biedt prestaties die bijna gelijk zijn aan die van een native VM, maar met duidelijke beperkingen: die GPU is dan niet meer beschikbaar voor de host en andere VM's, en je hebt doorgaans een aparte video-uitgang nodig voor die VM, wat niet ideaal is als je alles op hetzelfde scherm wilt weergeven.
- GPU-virtualisatie door middel van SR-IOV (Single Root I/O Virtualization)Het maakt het mogelijk om virtuele GPU-functies (VF's) beschikbaar te stellen aan verschillende virtuele machines. Het idee is zeer aantrekkelijk: het delen van grafische hardware met minimale overhead. Intel promoot deze aanpak in zijn Xe2 iGPU's voor laptops (zoals Lunar Lake) en in datacenter-GPU's (Flex), terwijl AMD en NVIDIA deze functie voornamelijk reserveren voor... zeer dure visitekaartjes waarbij bovendien vaak licentie- en abonnementsmodellen gelden die niet erg gebruiksvriendelijk zijn voor thuisgebruikers of kleine bedrijven.
- SR‑IOVDeze oplossing Het is niet volledig transparant voor virtuele machines, vereist specifieke stuurprogramma's, BIOS/firmware en hypervisorondersteuning, en kan eigen compatibiliteitsproblemen met zich meebrengen.Het is niet altijd de moeite waard om al je hardware te upgraden (bijvoorbeeld door alleen daarvoor een Intel Lunar Lake-laptop te kopen) als de rest van je workflow door andere factoren beperkt blijft. PC-hardwareanalyse Helpt bij het nemen van een beslissing.
- Eigen GPU-virtualisatieoplossingenDenk bijvoorbeeld aan NVIDIA RTX vWS, NVIDIA VGX of hun opvolgers. Deze combineren specifieke hardware (zoals VGX K1/K2-kaarten met meerdere Kepler GPU's, grote hoeveelheden GDDR5-geheugen en duizenden CUDA-cores) met een GPU-hypervisor die het mogelijk maakt de grafische rekenkracht te verdelen over tientallen virtuele desktops.
Gedeeltelijke GPU-technologieën in desktopomgevingen: virtio-gpu, virgl en SPICE
Voor gebruikers van KVM, QEMU, Proxmox of vergelijkbare systemen is de gebruikelijke procedure als volgt: Paravirtualiseerde grafische controllers zoals virtio-gpu, gecombineerd met protocollen voor externe bureaubladtoegang zoals SPICE.Aan de kant van de gast-VM wordt een driver geïnstalleerd die het virtuele apparaat "begrijpt" en een zekere mate van basis 2D/3D-acceleratie mogelijk maakt.
VirGL is een extra laag die Vertaalt OpenGL-aanroepen van de gast-GPU naar de host-GPU.Een applicatie binnen de virtuele machine maakt dus indirect gebruik van de daadwerkelijke 3D-acceleratie. Theoretisch zou dit de grafische prestaties van het bureaublad en de applicaties moeten verbeteren. In de praktijk gebeurt echter soms het tegenovergestelde. Als de geïntegreerde GPU van de host ondermaats is of de implementatie niet goed is uitgewerkt, is een aanzienlijke prestatiedaling merkbaar.
Sterker nog, veel gebruikers met AMD iGPU's (bijvoorbeeld Renoir) melden dat wanneer ze VirGL activeren, de Het bureaublad van de virtuele machine wordt aanzienlijk trager en zwaarder.Het is zelfs erger dan Virtio-GPU gebruiken "zonder GPU". Dit betekent niet dat VirGL nutteloos is, maar het hangt wel sterk af van de combinatie. hardware + stuurprogramma's + grafische belasting van de VM.
Bij Proxmox bestaat het trio uit drie personen. virtio-gpu + SPICE + virt-viewer Dit is doorgaans de minimale redelijke configuratie voor een grafische Linux-desktop. Het biedt een fatsoenlijke muisaanwijzer, de mogelijkheid om vensters te vergroten of verkleinen en een betere beeldcompressie dan een eenvoudige VNC-installatie, maar toch... Verwacht niet dezelfde ervaring als met de VMware ESXi-console op afstand of VMRC.die na jarenlange optimalisatie tot in de puntjes zijn afgewerkt.
Daarom zijn veel beheerders die van ESXi komen verrast als ze Proxmox proberen. Ondanks dat het een zeer krachtige hypervisor is, Het gevoel van "snelle" respons van de externe desktop is minder sterk. tenzij je veel fijnafstellingen doet of een aparte grafische kaart gebruikt.
Wanneer is GPU-passthrough de moeite waard en wanneer niet?
GPU-passthrough blijft de best presterende optie voor een specifieke virtuele machine. In alledaagse desktopgebruiksscenario's zijn er echter verschillende nadelen. Bijvoorbeeld: Behoefte aan een extra monitoringang, verlies van GPU voor de host, extra complicaties (IOMMU, groepen, BIOS, drivers, bugs met de slaapstand, enz.).
Als je doel is dat Een enkele virtuele machine beschikt over volledige 3D-acceleratie.De moeite is het meestal waard. Projecten zoals Looking Glass stellen je in staat om de VM-image opnieuw in de hostdesktop te "injecteren" om extra beeldschermen te vermijden. Maar als je iets anders wilt, is dat misschien niet de beste optie. meerdere virtuele machines voor kantoor of testen met een goede basisvaardigheidHet is niet haalbaar om naar elk apparaat een GPU over te plaatsen.
Voor krachtige desktopcomputers kunt u een hybride combinatie overwegen: De primaire GPU wordt gebruikt door de host en een tweede, minder krachtige GPU wordt doorgegeven aan een specifieke virtuele machine.Op deze manier behoudt u een zeer bruikbaar host-bureaublad en geeft u die virtuele machine een grafische omgeving die zeer dicht bij native ligt; een laptopanalyse Het kan een perspectief bieden op alternatieven voor desktops versus laptops.
Met laptops wordt het ingewikkelder. Ze hebben meestal een enkele iGPU (of iGPU + dGPU sterk geïntegreerd met de firmware)Met beperkte middelen en geen realistische mogelijkheid om een ​​extra grafische kaart te installeren, is passthrough zelden de moeite waard. Het is verstandiger om gebruik te maken van paravirtualisatieopties (virtio-gpu, SPICE, RDP) om de grafische eisen van de virtuele machines te verlagen.
Samengevat, Passthrough is de juiste oplossing voor een paar zeer veeleisende virtuele machines.Voor labs met veel machines of lichte desktops bent u meer geïnteresseerd in het aanpassen van de hypervisor, het beheersen van de CPU/RAM/I/O-belasting en het kiezen van het juiste protocol voor externe bureaubladverbindingen.
Hypervisors, NUMA, dynamisch geheugen en andere prestatiefactoren
Naast de GPU is de manier waarop de hypervisor het beheert van... CPU, geheugen, opslag en netwerk Het heeft direct invloed op de ervaren vloeiendheid van het bureaublad van de virtuele machine. Hyper-V, KVM, VMware en andere oplossingen hanteren enigszins verschillende filosofieën, maar ze delen allemaal gemeenschappelijke concepten.
De Hyper-V-architectuur is bijvoorbeeld gebaseerd op een een hypervisor die de toegang tot de hardware regelt, een rootpartitie met het beheersysteem en secundaire partities voor de virtuele machines.Dit wordt ondersteund door technologieën zoals virtuele NUMA, dynamisch geheugen, virtuele switches, netwerk-SR-IOV en opslagoptimalisaties zoals ODX.
NUMA (Non-Uniform Memory Access) is met name cruciaal in servers met veel cores. Als een grote virtuele machine slecht verdeeld is over de fysieke NUMA-nodes, neemt de geheugenlatentie toe. En de prestaties lijden eronder, zelfs als er op papier voldoende resources lijken te zijn. Idealiter zou de vNUMA-topologie van de VM moeten overeenkomen met de pNUMA-topologie van de host.
Dynamisch geheugen (in Hyper-V, ballooning in andere hypervisors) kan globaal RAM-geheugen besparen, maar Het is niet geschikt voor latency-gevoelige workloads zoals databases of desktops met veel open applicaties.In dergelijke gevallen is het raadzaam om vast geheugen toe te wijzen om pauzes te voorkomen wanneer de hypervisor besluit om al het RAM-geheugen in één keer vrij te maken.
Opslag is verreweg het meest voorkomende knelpunt. Het wordt aanbevolen Gebruik VHDX-schijven met een vaste grootte, aparte systeem- en dataschijven, kies voor SSD's of NVMe-schijven van enterprise-kwaliteit en vermijd RAID-configuraties met slechte schrijfprestaties (RAID 5/6) voor intensieve workloads.Waar mogelijk helpen Storage Spaces Direct of NVMe-arrays de latentie binnen acceptabele grenzen te houden.
Op een netwerk is het raadzaam om te configureren Externe virtuele switches op snelle netwerkkaarten (bij voorkeur 10 GbE), gebruik NIC-teaming, schakel SR-IOV in voor zeer zware netwerkbelastingen en optimaliseer de MTU en offloads. Alleen als de hele netwerkketen het ondersteunt. Een slechte netwerkconfiguratie kan ervoor zorgen dat een extern bureaublad, zelfs met een goede grafische kaart, slechter presteert dan verwacht.
Stresstesten en gebruiksscenario's: wanneer kies je voor een virtuele machine of een fysieke server?
Om te beslissen of een grafische workload naar een virtuele machine moet worden gemigreerd of op fysieke media moet blijven staan, is het belangrijk om rekening te houden met het volgende: Testen met benchmarks en stresstesttools Ze zouden het CPU-, RAM-, schijf- en netwerkgebruik moeten meten. En, indien mogelijk, ook het GPU-gebruik. Idealiter zou de "echte" applicatie vergeleken moeten worden met dezelfde applicatie die in een virtuele machine draait.
Een realistisch patroon zou kunnen zijn: Voer sysbench of Geekbench uit voor de CPU, stress-ng of memtester voor het RAM-geheugen, fio voor 4K IOPS en schijflatentie, en iperf3 voor de netwerkbandbreedte.en een aantal basis grafische benchmarks (bijv. glxgears of een browsergebaseerde WebGL-test) op zowel de host als de VM.
Als het prestatieverlies binnen acceptabele grenzen blijft (bijvoorbeeld, Minder dan 10% extra CPU/RAM en een verlies van 15-20% op de schijfAls de externe bureaubladverbinding soepel genoeg verloopt voor het beoogde gebruik (kantoorautomatisering, beheer, lichte ontwikkeling), is virtualisatie een prima optie.
Als de applicatie daarentegen sterk afhankelijk is van GPU, lage latentie en hoge, constante I/O-doorvoer. (Voor rendering in Blender, zware CAD-toepassingen, AI-engines die grote modellen trainen, games, enz.) is de ervaring meestal veel beter op een fysieke server met een dedicated GPU of op een professionele GPU-passthrough/gevirtualiseerde VM.
De sleutel is om te achterhalen welk onderdeel (voldoende CPU, onvoldoende RAM, beperkte I/O, gebrek aan een echte GPU, traag netwerk of slecht geoptimaliseerd desktopprotocol) de prestaties van elke virtuele machine vertraagt. Pas in dat geval de eenvoudigste en meest kosteneffectieve oplossing toe die mogelijk is.en reserveer de grote investeringen (speciale GPU's, SR-IOV, professionele hardware) voor de taken waar ze echt een verschil maken.