Welk virtualisatieplatform biedt de grootste meerwaarde in datacenters als bare-metal hardwarevirtualisatiesolution: Hyper-V of Esxi?

Transcriptie

1 Welk virtualisatieplatform biedt de grootste meerwaarde in datacenters als bare-metal hardwarevirtualisatiesolution: Hyper-V of Esxi? Promotor: Mh Johan De Gelas Onderzoeksvraag uitgevoerd door VAN ONSEM MATTHIAS Voor het behalen van de graad van Bachelor in de NEW MEDIA AND COMMUNICATION TECHNOLOGY HOWEST

2 Woord vooraf Virtualizatie is vandaag de dag niet meer weg te denken uit moderne datacenterinfrastructuren. Zowel scalability, onderhoudbaarheid, kost efficiëntie, enz. vormen sterke argumenten die tot een keuze naar virtualizatie leiden. In de datacenterwereld is bare metal virtualizatie dan ook vrijwel altijd aanwezig om zo efficiënt mogelijk met de beschikbare middelen om te springen. Doorheen de jaren zijn er dan ook heel wat platformen aanwezig. Zowel Cisco, Microsoft, Oracle en vele anderen concurreren nu hevig om het grootste deel in een steeds groter wordende markt. De bekendste platformen zijn wellicht Esxi (VMware) en Hyper-V (Microsoft) die samen ongeveer 8% van de markt in beslag nemen. Voor mijn bachelorproef onderzocht ik twee maanden lang de virtualizatieoplossingen Hyper-V en Esxi en hun specifieke kenmerken. Doorheen dit document zal je een aantal argumenten vinden die het maken van deze keuze gemakkelijker moet maken. Ik zal ook bij elk punt een aantal specifieke praktische situaties benaderen met daarbij een voorkeurssysteem. Het is dan ook de bedoeling dat je als lezer op het einde van het document een beter beeld krijgt over de verschillen en gelijkenissen van Hyper-V en VMware. Ik wil voor dit werk graag allereerst Pieter Schepens, Alexander Vervaet en Jan Demedts van het ICT-beleid van Don Boscocollege Zwijnaarde bedanken voor de middelen die zij mij ter beschikking stelden voor het uitvoeren van onderstaand onderzoek. Ook de vrijheid die zij mij schonken tijdens mijn stageperiode heeft de voortgang tot dit onderzoek sterk versneld. Tot slot wil ik graag mijn vriendin bedanken voor de steun en het vertrouwen in mij doorheen dit proces. 1

3 Inhoudsopgave Woord vooraf... 1 H1 Virtualisatie, een korte inleiding... 3 Inleiding... 3 Bare metal virtualisatie... 3 De huidige marktsituatie... 4 Esxi... 4 Hyper-V... 5 H2 Performance... 7 Inleiding... 7 Hardware... 7 Software en tools... 8 Resultaten... 8 Inleiding... 8 CPU performance... 8 Grafische performance de default situatie Grafische performance RemoteFX, PCI-passthrough en vsga Memory en Storage H3 Conclusie Inleiding Kostprijs Performance Algemene conclusie... 3 Bijlagen CPU-performance GPU-performance - default GPU-performance - RemoteFX Memory-performance Storage-performance SSD... 6 Storage-performance RAID

4 H1 Virtualisatie, een korte inleiding Inleiding Doorheen dit document zal een vergelijking worden gemaakt tussen de twee populairste bare metal virtualisatieplatformen op de markt, namelijk Hyper-V en Esxi. We zullen zowel performance, administratie en security bespreken aan de hand van duidelijke voorbeelden en tests. Deze resultaten worden geanalyseerd om zo tot een objectief besluit te kunnen komen over welk platform in welke situatie de voorkeur zal genieten. Let wel dat onze middelen qua hardware en beschikbare tools beperkt is waardoor de kwaliteit van dit onderzoek (vooral op vlak van performance) waarschijnlijk lager zal liggen dan onderzoeken die worden uitgevoerd door professionele bedrijven of universiteiten. Bare metal virtualisatie Wanneer we spreken over bare metal virtualisatie, bedoelen we een situatie waar we onze virtualisatielaag rechtstreeks op de hardware zal draaien. Virtualbox en VMware workstation zijn met andere woorden geen bare metal virtualisatiesystemen omdat we deze op een OS zoals Linux of Windows draaien. Hyper-V en Esxi worden dus rechtstreeks op de hardware geïnstalleerd. Een ander voorbeeld van bare metal virtualisatie is Citrix Xenserver. Deze manier van virtualisatie heeft als grote voordeel dat we rechtstreeks gebruik kunnen maken van de hardwaremiddelen zonder rekening te moeten houden met een eventueel Parent OS. Onze hypervisor zal hier alle hardware beheren en beperkte middelen beschikbaar stellen aan de VM s. Dit geeft als voordeel dat we meerdere systemen op dezelfde hardware kunnen draaien, wat onze hardware veel efficiënter maakt tov wanneer slechts één systeem de hele hardwareset gebruikt die hij zelden zal gebruiken. Figure 1 bare metal 3

5 De huidige marktsituatie Tot op heden zijn er slechts drie grote spelers aanwezig wanneer we de markt van bare metal virtualisatie bekijken, namelijk Esxi, Hyper-V en Citrix Xenserver. De marktaandelen van deze hypervisors zijn als volgt verdeeld: Marktsituatie % 13% 28% 56% Vmware Microsoft Citrix andere Aangezien Esxi (Vmware) en Hyper-V (Microsoft) samen een monsteraandeel bedragen, is het interessant dat deze twee systemen eens degelijk met elkaar vergelijken om zo te kunnen uitmaken in welke situaties welke hypervisor nu het best van pas komt. Esxi Vmware biedt al sinds 1998 hun hypervisor aan als bare metal virtualisatieoplossing. Esxi (vroeger Esx server genaamd) wordt tot op heden ook als trendzetter gezien wanneer we over virtualisatie spreken. Esxi bevat twee grote componenten die samen de virtualisatieoplossing omvatten, namelijk Esxi en Vsphere. Wanneer we spreken over Esxi, bedoelen we technisch gezien enkel de hypervisor of de virtualisatielaag die op de hardware draait. Dit wil zeggen dat Esxi op zich een bare metal virtualisatieoplossing is aangezien deze perfect in staat is hardware te virtualiseren en virtuele machines (VM s) op deze hardware te laten draaien. 4

6 We hebben echter nog nood aan een tweede component om deze hypervisor te beheren. Dit onderdeel wordt ingevuld door Vsphere of Vcenter. Deze management software kan zowel een client zijn die op een andere machine werd geïnstalleerd, of een webinterface die rechtstreeks zal draaien op onze Esxi host. Figure 2 Esxi Figure 3 Prijs Esxi Esxi en vsphere zijn heden niet meer gratis te verkrijgen. Als klant kan je echter wel nog een 6 dagen probeerversie installeren om te zien hoe de software precies werkt, maar daarna is een jaarlijkse licentie verplicht, het kostenmodel zit als volgt in mekaar: Een probeerversie bemachtigen vereist eveneens ook een bedrijfs een het invullen van een enquête. De laatste versie momenteel is de 6.. We zullen deze versie ook behandelen in onze vergelijking doorheen dit document. Hyper-V Microsoft wordt heden nog veel gezien als de nieuwe speler in virtualisatieland. Dit komt vooral omdat de eerste versie van Hyper-V pas in juni 28 werd geïntroduceerd in bepaalde Windows Server versies. Momenteel zit Hyper-V standaard verwerkt in elke Windows Server versie en eveneens in de consumentenversies van Windows (die worden niet gezien als bare metal). 5

7 Ook hier wordt de virtualisatieoplossing in twee delen opgesplitst: namelijk de hypervisor en de management tools. Wanneer we Hyper-V echter enablen op Windows Server, zien we dat Windows Server nog steeds aanwezig is voor management. Management kan echter ook vanop afstand worden gedaan via een Windows client met Hyper-V management tools enabled. Hyper-V heeft sinds 212 ook zijn eigen OS gekregen: namelijk Hyper-V server. Dit is een Windows distributie zonder GUI waar enkel de hypervisor op draait. Management moet hier zowiezo vanop afstand gebeuren. Het prijsmodel van Hyper-V is echter een stuk goedkoper dan Esxi. Enerzijds kunnen we Hyper-V server volledig gratis en onbeperkt downloaden, installeren en gebruiken. We moeten ons hier echter wel registreren met een Microsoft account. We zullen echter wel merken dat specifieke features zoals RemoteFX (zie grafische performance) niet beschikbaar zijn op deze gratis versie en we dus een licentie moeten kopen voor Windows Server. Deze licenties hebben een prijs per geïnstalleerde eenheid. We maken echter wel een onderscheid tussen fysieke eenheden (POSE s) en virtuele eenheden (VOSE s). de prijs per eenheid zit op de volgende manier in elkaar: Figure 4 Prijzen Hyper-V In de volgende vergelijking maken we gebruik van zowel Windows Server 216 TP4 (momenteel nog gratis) en Hyper-V server 216. Merk dat dit nog geen afgewerkte producten zijn en onderstaande resultaten dus kunnen afwijken van de definitieve release. 6

8 H2 Performance Inleiding In de discussie over welk virtualisatie de voorkeur verdient, wordt performance zeer vaak over het hoofd gezien. Performance is echter zeer belangrijk wanneer we kiezen naar de juiste oplossing. We willen namelijk dat onze VM s zo veel mogelijk van de fysieke middelen ter beschikking hebben om verwachte taken uit te voeren. Het is ook cruciaal dat deze middelen zo efficiënt mogelijk schalen wanneer meerdere VM s toegevoegd worden aan één fysieke eenheid. We kunnen performance opdelen in volgende grote factoren: De geheugenperformance (RAM) De storageperformance (disks) De CPU-performance De grafische performance Deze factoren zijn zeer situatie specifiek. Wanneer we bv. virtualisatie willen toepassen op webapplicaties, zullen we niet zo geïnteresseerd zijn in grafische kracht dan wanneer we bijvoorbeeld 3D willen renderen. Het is ook belangrijk dat we deze tests op meerdere soorten VM-opstellingen toepassen. Het kan namelijk zo zijn dat de performance niet goed zal schalen naarmate meerdere VM s worden toegevoegd. We zullen de tests dan ook uitvoeren wanneer slechts één VM aanwezig is, alsook wanneer twee VM s tegelijk actief staan om de schaling van de beschikbare middelen te testen. Hardware Voor we beginnen aan de effectieve tests, is het handig om eerst even de gebruikte hardware te bekijken. De volgende configuratie werd voornamelijk gebruikt: i7 377K 3.6Ghz CPU (met Corsair H8 liquid cooler) ASUS P8Z77-V Pro moederbord 4x4GB Corsair Vengeance DDR3 RAM 16Mhz ( ) Samsung 85 EVO 256GB SSD (TRIM enabled) MSI R9 39X 8GB Gddr5 OC (11Mhz clock, 6.1Ghz memory clock) Corsair HX15 modular PSU (8 PLUS Gold certified) Om disk performance te testen is het uiteraard aangewezen dat zowel magnetische HDD s als SSD s worden getest. Daarom werd voor deze specifieke test ook volgende configuratie gebruikt. 2x Xeon e Ghz CPU (in NUMA) 48GB 133Mhz RAM 8x Seagate 5GB HDD 72rpm (in hardware RAID1) 2x 86Wh PSU 7

9 Software en tools Er zijn heel wat performance testing tools aanwezig die gebruikt kunnen worden. Voor de volgende tests werden vooral volgende test suites gebruikt Passmark 8 3Dmark (Fire Strike) Deze tests werden uitgevoerd op de volgende configuraties Windows 1 op hardware 1x Windows 1 op Windows Server 216 TP4 2x Windows 1 op Windows Server 216 TP4 1x Windows 1 op Hyper-V Server 216 2x Windows 1 op Hyper-V Server 216 1x Windows 1 op Esxi 6. 2x Windows 1 op Esxi 6. Alvorens we deze testen bespreken zien we uiteraard dat dit redelijk consumentgerichte testen zijn. Dit wil zeggen dat deze testen zeker geen optimale serversituaties schetsen. Vele Server- en VM-gerichte benchmarktools zoals SiSoftware en VMwareMark vereisen echter ofwel licentie om mee te werken, of kunnen niet als objectieve tool gezien worden in de vergelijking die we momenteel behandelen. We zullen proberen deze testen zo algemeen mogelijk te benaderen zodat we toch een realistisch beeld kunnen schetsen van onze behandelde hypervisors. Resultaten Inleiding We onderscheiden onze resultaten in vier algemene categorieën: CPU performance GPU performance Memory performance Disk performance Bij elk van deze resultaten zal een analyse volgen die enerzijds zal toelichten waarom we tot deze resultaten komen en anderzijds op welke praktijksituaties deze resultaten een groot effect kunnen hebben. We zullen ook zien dat we sommige resultaten kunnen boosten door een aantal instellingen te herconfigureren in de hypervisor zelf. Deze instellingen zullen ook in detail besproken worden samen met een aantal opmerkingen en praktische situaties waar deze van toepassing zijn. CPU performance Om het concept CPU performance in virtualisatie beter te begrijpen, moeten we eerst kijken naar hoe de CPU-middelen worden doorgegeven aan onze VM s. We onderscheiden hier vier aparte virtualisatietechnieken van de CPU: partial, full, hardware assisted en paravirtualization. 8

10 Wanneer we spreken over partial virtualization, zal slechts de address space gevirtualizeerd worden. Dit wil zeggen dat ons OS niet volledig in een VM zal draaien en dus niet volledig wordt geïsoleerd. Om de address space te kunnen virtualiseren hebben we echter wel nood aan hardware die address-relocation of virtueel geheugen ondersteund. Full virtualization daarentegen biedt ons de mogelijkheid om het volledige OS zonder aanpassingen volledige virtueel te draaien. Hyper-V en Esxi zijn dus beiden voorbeelden van Full virtualization platformen aangezien de CPU volledig wordt gevirtualizeerd. Let wel dat Full virtualization zonder hardware assist redelijk wat overhead met zich meebrengt. Hardware assisted virtualization lost dit probleem grotendeels op. Hier zal de hardware ons grotendeels helpen met het isoleren van onze VM s, alsook om de performance overhead te minimaliseren. Hardware assisted virtualization is een vorm van full virtualization en wordt volledige gesupport in Hyper-V en Esxi. Zowel AMD als Intel komen met hun eigen branding voor deze technologie, namelijk Intel-VT (Virtualization Technology) en AMD-V. Naast deze drie vormen onderscheiden we ook nog Paravirtualization. Hier maken we gebruik van APIredirection. We passen als het ware het guest-os aan zodat deze speciale API s zal aanspreken van de Hypervisor. Deze API- of Systemcalls worden ook wel eens Hypercalls genoemd. Dit wil zeggen dat we niet verplicht zijn de hardware te virtualiseren, maar we wel nood hebben aan de source code van het guest- Figure 5 vcpu's OS aangezien we deze moeten hercompileren. Paravirtualization wordt niet ondersteund in Hyper-V en Esxi. 9

11 In dit document hebben we te maken met Hardware Assisted Virtualization met Intel-VT. We virtualiseren onze logische cores of threads dus tot vcpu s zoals hierboven snel werd geschetst. Let wel dat elke vcpu slechts een tijdsslot omvat van elke sequenciële thread. Dit wil zeggen dat wanneer we twee vcpu s op één thread draaien, in theorie de performance van elke vcpu op die thread met 5% gereduceerd wordt. Aan de andere kant wil dit ook zeggen dat SMT perfect te combineren valt met vcpu s, waardoor we in het geval van onze i7 CPU acht parallelle vcpu s kunnen toewijzen aan onze VM s aangezien deze quad core CPU hyperthreading ondersteunt. Let dus ook dat Intel hier heden (maart 216) een stapje voor heeft tov AMD aangezien de nog niet bestaande ZEN-architectuur de eerste AMD-CPU s zullen brengen die SMT ondersteunen. Voor onze tests definiëren we twee Windows 1 VM s die elk acht vcpu s ter beschikking hebben. Hieruit kunnen we zien hoeveel CPU-performance we effectief verliezen wanneer we één systeem virtueel draaien, alsook hoeveel performance loss we krijgen wanneer twee vcpu s op 1 sequenciële thread draaien. We doen dit voor zowel Hyper-V als Esxi en nemen dezelfde benchmark op een Windows 1 host die rechtstreeks op de hardware draait als marge. We kunnen volgende resultaten afleiden: CPU-performance Total Windows Server 216 TP4 Hyper-V server 216 Esxi 6. Hardware Let wel dat deze resultaten een groepering representeerd van verschillende resultaten, in de volgende bespreking zullen de resultaten te vinden op pagina 3 aan bod komen. Wat meteen opvalt is dat Esxi een stuk hoger ligt (ongeveer 1% tov Windows Server) bij vrijwel elke CPUtest. Deze benadering is consistent wanneer we schalen naar twee VM s. We kunnen hieruit al snel afleiden dat Hyper-V een hogere CPU-overhead met zich meebrengt dan Esxi wanneer we deze virtualiseren. We kunnen er al snel van uitgaan dat door de vele Windows Server processen en services die standaard draaiende zijn, onze vcpu standaard minder resources beschikbaar zullen hebben voor eigen gebruik. We 1

12 kunnen dit zeer mooi zien on onze single threaded test, waar slechts één vcpu belast zal worden. Enerzijds zien we dat één VM in Windows Server 216 slechter scoort dan wanneer we twee VM s te test synchroon laten uitvoeren. Omdat we dit verschil niet terugzien in onze Hyper-V server test, kunnen we er vanuit gaan dat deze test op één VM werd uitgevoerd op een thread die op dat moment gebruikt werd door de standaard Windows Processen van onze Hypervisor. In theorie levert het feit dat we hier Windows Server 216 draaien met GUI ook wat overhead mee tov een Server zonder GUI. In onze praktijksituatie is deze overhead echter te verwaarlozen aangezien we gebruik maken van een externe GPU (R9 39X) om onze grafische elementen te renderen. Het is echter wel aangewezen voor systemen zonder dedicated GPU, de GUI uit te schakelen. Dit zal niet alleen een groot verschil in CPU-performance geven, maar ook meer RAM beschikbaar stellen aangezien dit wordt gebruikt als VRAM door de CPU. De grootste verwondering lijkt hier toch het performanceverschil tussen Windows Server 216 met alle toeters en bellen aanwezig en de lightweight Hyper-V server die niet eens een GUI geïnstalleerd heeft staan. Deze testen werden meerdere keren uitgevoerd om tot een objectief resultaat te komen. We kunnen zien dat dit performanceverschil (ongeveer 33%) eveneens veel te groot is om nog te negeren of te wijten aan opstart- of updateprocessen. We moeten hier echter wel rekening houden met het feit dat Hyper-V een gratis tool is, terwijl Windows Server 216 een licentie vereist. We kunnen hieruit afleiden dat de hypervisor in Hyper-V server in grote mate onderdoet aan die van Windows Server 216. Deze redenering wordt nogmaals versterkt wanneer we de schaling van multithreaded performance vergelijken van één VM naar twee VM s. Tests zoals bijvoorbeeld compressie, encryptie en Extended Instructions (ook wel SIMD genaamd). Enerzijds zien we hier mooi het voordeel in performance bij het gebruiken van Hardware Accelerated Virtualization. Hoewel we in theorie 5% performance verliezen wanneer twee vcpu s aanwezig zijn op dezelfde thread, zien we dat onze performance slechts met 4% gereduceerd wordt in onze situatie. Anderzijds kunnen we ook stellen dat de schaling en proporties van Hyper-V server tov Windows Server hetzelfde zijn, met andere woorden onze performance schaalt in dezelfde mate, maar onze VM s krijgen in de eerste plaats minder CPU-performance toegekend. De multithreaded testen op zich vormen een zeer interessante factor bij het kiezen naar de juiste virtualizatiekeuze. We willen namelijk onze hardware zo efficiënt mogelijk benutten. Dit wil zeggen dat in een optimale situatie, we streven naar een situatie die mooi wordt uitgebeeld in onze multithreaded tests omdat we ons systeem dan als het ware ten volle benutten. We merken hier een zeer klein verschil tussen Esxi en Windows Server (slechts 5% in het voordeel van Esxi). Dit is enerzijds normaal, aangezien onze standaard Windows services en processen redelijk beperkt worden in aantal cores die worden gebruikt. Deze logica wordt eveneens versterkt wanneer we deze testen uitvoeren over meerdere VM s. Vooral bij de multithreaded tests zien we dat Windows Server bijna gelijk staat in performance met Esxi. Dit is hoogstwaarschijnlijk ook te wijten aan het feit dat de tijdssloten van elke vcpu steeds kleiner worden naarmate meer vcpu s actief staan op dezelfde fysieke sequenciële thread. Dit wil zeggen dat onze Windows services op Windows Server steeds minder CPU-tijd in beslag nemen aangezien meer vcpu s in de wachtrij staan. Daarmee kunnen we eveneens ook afleiden dat deze processen op zich niet zoveel overhead met zich meebrengen, maar dat bij de aanwezigheid van minder vcpu s ervoor zorgt dat de fysieke kracht van onze CPU minder efficiënt zal verdeeld worden. Dit maakt Hyper-V al een veel sterkere concurent dan de testen op het eerste moment doen blijken. Voor parallelle taken zoals webservers of het draaien van zeer veel VM s tegelijk. Het wordt echter ook al snel duidelijk dat onze lightweight 11

13 Hyper-V server hier bijna op de blacklist kan gezet worden. We zien namelijk dat we bij elke test ferm onder de Windows Server score zitten en dat deze relatie consistent is bij het schalen naar meerdere VM s. In conclusie kunnen we stellen dat Esxi als duidelijke winnaar uit de bus komt wanneer we spreken over CPU-performance. Dit komt vooral door de kleinere overhead van de lightweight Esxi tov Windows Server of Hyper-V server. We zien echter wel dat deze overhead minder merkbaar is naarmate we meerdere taken tegelijk verwerken. Dit wil zeggen dat we in de meeste praktijksituaties (waarin veel VM s een veelvoorkomende situatie is) we dit verschil nauwlijks nog zullen merken. Het is ook opmerkelijk dat Windows Server 216 met Hyper-V een zeer grote performancewinst haalt tov de gratis lightweight Hyper-V server. Vanuit onze tests waar we deze vertraging bij vrijwel elk onderdeel zien kunnen we afleiden dat de hypervisor er veel langer over doet de fysieke middelen beschikbaar te stellen aan onze VM s. Hoewel deze hypervisor gratis is, kunnen we deze niet aanraden voor een professionele omgeving waar het efficiënt gebruik van middelen cruciaal is voor de bedrijfsprocessen. Grafische performance de default situatie Wanneer we situaties bespreken waar grafische performance een grote rol speelt binnen het kader van virtualisatie, is onze lijst beperkt. Grafische performance is namelijk bedoeld voor zeer specifieke situaties die in vele gevallen zo zwaar zijn dat we deze niet willen virtualiseren uit angst voor een te grote performance loss of stabiliteit van ons systeem. Grafische elementen kunnen we meestal op de volgende manier renderen: Op de CPU Op een dedicated GPU of APU Het renderen van geavanceerde grafische elementen is op zich één van de meest complexe procedures die onze computer afhandelt. Het proces is namelijk niet alleen zeer belastend voor de hardware, maar het parallelliseren van dit proces is een zeer complex probleem die voor vele rendertechnieken grotendeels nog steeds onopgelost blijft (denk maar aan Raytracing). Om de parallelle rendertaken een flinke boost te geven, wordt vaak gebruik gemaakt van een dedicated GPU of APU (in ons geval is dit een R9 39X). Wat echter een groot nadeel vormt is dat veel van deze videokaarten een OS-specifieke driver nodig heeft om optimaal te kunnen functioneren aangezien we standaard API-calls gebruiken om de videokaart aan te spreken. In de volgende testen nemen we een kijkje hoe onze virtualisatiesystemen omgaan met grafische taken op de VM s. We moeten echter de volgende resultaten benaderen met de volgende kennis: onze Windows 1 client die rechtstreeks op de hardware draait maakt volledig gebruik van de R9 39X videokaart via de AMD Crimson driver (december 215). Deze videokaart is DirectX (versie 12. feature level 2), OpenGL (versie 4.4), Vulkan (heden nog niet beschikbaar) en Mantle (AMD) enabled. Dit wil zeggen dat de volgende tests die gebruik maken van de DirectX API zeer vlotte access zullen krijgen op de videokaart. We maken hier gebruik van zowel Passmark 8. die een aantal DirectX testen zullen uitvoeren, alsook 3Dmark (Firestrike test) die ons systeem zal onderwerpen aan een zeer intensieve test voor zowel VRAM, GPU en CPU. We stellen als eerste meteen een driverprobleem vast bij het zoeken naar drivers voor onze virtualisatiesystemen. Omdat onze R9 39X nog steeds een consumentgerichte GPU is die speciaal is gemaakt voor games, zijn er geen drivers beschikbaar voor zowel Windows Server, Hyper-V server en Esxi. Dit wil zeggen dat de kans erg klein is dat we de GPU kunnen virtualiseren voor meerdere VM s aangezien 12

14 dit proces zeer drivergebonden is. Wanneer we het probleem rond driversupport echter wat logisch bekijken, stoten we al snel op een interessante mogelijkheid binnen Hyper-V. Omdat Windows Server technisch gezien een serverlaag is die op een Windows NT kernel draait, kunnen we ervan uitgaan dat een normale Windows 1 driver hoogstwaarschijnlijk ook zal werken op Windows Server 216 (we moeten echter wel onthouden dat dit geen officiële support is). Deze theorie lijkt in de praktijk ook perfect te kloppen. Wanneer we de Crimson driver installeren op onze Windows Server zien we niet alleen dat de installatie perfect mogelijk is, maar wanneer we een grafische benchmark vergelijken met onze Windows 1 client merken we ook dat deze driver op exact dezelfde manier werkt. We moeten echter realistisch denken vooraleer we beginnen aan onze grafische testen. Doordat onze GPU officieel niet ondersteund wordt op Windows Server 216, is de kans uiteraard klein dat met de standaard instellingen deze kaart zal gebruikt worden voor grafische virtualisatie. We kunnen er dus vanuit gaan dat onze testresultaten, zelfs met de Crimson driver geïnstalleerd op onze Windows server dezelfde resultaten zullen opleveren als wanneer we geen enkele grafische driver installeren. Wanneer we onze grafische testen analyseren, zien we de volgende resultaten: 1 3D performance - Total Windows Server 216 TP4 Hyper-V server 216 Esxi 6. Hardware Zoals bij de CPU-benchmarks, omvat de totale score hier een groepering van alle onderliggende testen. In de volgende bespreking komen ongeveer alle testen op pagina 36 aan bod. Wat hier meteen opvalt is dat onze virtualisatie hier veel slechter presteert tov onze Windows 1 client die rechtstreeks op de hardware draait. We spreken hier namelijk van een factor 1 of meer. We kunnen er hier dan ook al snel vanuit gaan dat onze virtualisatiesystemen hier geen gebruik zullen maken van onze R9 39X voor het renderen, iets wat we ook hadden voorspeld. We gebruiken met andere woorden 13

15 onze CPU als GPU. Om onze vergelijking tussen Esxi en Hyper-V wat visueler voor te stellen, kunnen we beter kijken naar de grafieken zonder de Windows 1 client. 3D performance - Total Windows Server 216 TP4 Hyper-V server 216 Esxi 6. Wanneer we deze overzichtelijkere resultaten bekijken, zien we dat Windows Server en Esxi ongeveer gelijk scoren op praktrijksituaties. We hebben hier echter wel wat overhead bij het testen van 1 VM met 8 vcpu s, wat eveneens te danken is aan onze onderliggende Windows services en processen. Let wel dat het uitschakelen van de GUI op Windows Server deze overhead niet in merkbare mate zal verminderen, we renderen hier onze GUI nog steeds op de R9 39X. We merken ook dat Windows Server beter scoort naarmate onze DirectX versie nieuwer is. Dit geeft aan dat naarmate onze grafische applicaties gebruik maken van nieuwere Microsoft gebaseerde API s, Hyper-V op Windows Server interessanter wordt. We merken echter wel dat deze trend niet consistent is bij Hyper-V server, wat nogmaals doet vermoeden dat de hypervisor op Hyper-V server zeker niet dezelfde is als op Windows Server. We merken dat ook voor grafische toepassingen, Hyper-V server niet in de buurt komt van Windows Server en Esxi in het kader van performance. Let wel dat we hier zeer specifieke API-calls testen en we dus een praktijktest nodig hebben om de grafische performance effectief te gaan vergelijken. We kiezen hier voor 3Dmark. Deze DirectX gebaseerde test wordt namelijk veel gebruikt door gamers om hun grafische performance te testen. Hoewel de kans klein is dat we games in een virtuele omgeving gaan draaien, wil ik er wel even op wijzen dat games tot de zwaarste toepassingen behoren wanneer we spreken over API gebaseerd renderen. Deze test omvat ook een physics test, waar zowel CPU gerelateerde taken alsook grafische taken in één test worden uitgevoerd. We merken de volgende resultaten op: 14

16 3Dmark - total Windows Server 216 TP4 Esxi 6. We merken hier meteen op dat, hoewel Windows Server ongeveer hetzelfde scoort in passmark, we in een praktijksituatie toch iets lagere resultaten zien bij Windows Server. We zien dat dit grotendeels te danken is aan een kleine superieure framerate in de grafische testen. Wat we echter wel opmerken is dat Windows Server betere resultaten toont in de combinatietesten (zowel combined en physics test) waar we zowel grafisch renderen alsook fysica berekenen op dezelfde hardware (namelijk de CPU). Het feit dat we de vcpu s hier gebruiken voor grafische en fysica gerelateerde berekeningen wordt ook mooi getoond in de physics test, waar we toch de helft halen in kracht tov onze Windows 1 client. Desondanks kunnen we vaststellen dat voor dergelijke taken zoals simulaties en animaties, onze virtualisatieplatformen niet voldoen aan onze eisen. Op de testen zelf, merken we op dat we hier enkel de DirectX API gebruiken als tolk voor onze grafische hardware. We kunnen redeneren dat, aangezien DirectX een Microsoft product is, onze Hyper-V hypervisor een stap voor heeft op Esxi. We virtualiseren namelijk hardware waarvan de performancebaseline zeer API- en drivergebonden is. Dit merken we uiteraard bij videokaarten op zich ook, een driver- of API-update kan namelijk zeer grote performance-impact hebben (denk maar aan de overhead van DirectX 12 tov 11). Om onze platformen dus zo objectief mogelijk te testen, willen we uiteraard ook weten hoe de OpenGL API presteert in benchmarks. We kiezen hier voor furmark om OpenGL op te testen. Deze testsuite wordt namelijk het meest gebruikt om de stabiliteit te testen van GPU s. In theorie kunnen we de gemiddelde framerate van beide systemen vergelijken met elkaar om zo te weten welk platform de beste performance levert. In de praktijk zien we echter een heel ander verhaal. We merken namelijk dat onze testen niet eens willen starten op geen van onze drie hypervisors. 15

17 Figure 6 Error OpenGL Deze error spreekt zonder uitleg al boekdelen, uiteraard kunnen we ook al snel de reden van deze error achterhalen. Ook de GFX-benchmark die meerdere OpenGL-versies ondersteunt, geeft bij elke OpenGL versie dezelfde error terug. Doordat we hier gebruik maken van drivers voor virtuele hardware, is het uiteraard logisch dat niet elke API wordt ondersteund. Wat echter wel opvallend is, is dat hoewel OpenGL een opensource API is, deze toch in veel mindere mate wordt ondersteund dan DirectX, een closed source API van Microsoft. We kunnen hieruit ook concluderen dat grafische toepassingen in Linux gebaseerde systemen zeer slecht, tot zelfs niet zullen draaien onder zowel Hyper-V als Esxi omdat Linux bijna uitsluitend deze API gebruikt voor grafische toepassingen. Dit kan echter snel veranderen in de toekomst met Vulkan. Omdat zowel Vulkan en DirectX 12 min of meer gebasseerd zijn op de Mantle API van AMD, een API die zelfs opensource is, is de kans zelfs groot dat we in de toekomst niet meer zullen botsen op dit soort fouten. Dit zal uiteraard slechts zo zijn wanneer de applicatie in kwestie gebruik zal maken van deze API-versies. In conclusie kunnen we stellen dat met de standaard instellingen op beide virtualisatiesystemen, de grafische performance te betreuren is. Dit heeft uiteraard veel te maken met het feit dat onze huidige hardware veel meer potentieel toont op onze Windows 1 client. Deze conclusie kunnen we met andere woorden uitsluiten bij de doorsnee server hardware, waar er meestal geen sprake is van de aanwezigheid van een GPU of APU. We kunnen ook concluderen dat hier enkel Windows Server 216 en Esxi met elkaar kunnen concurreren, de performance van Hyper-V ligt namelijk een stuk lager en is zeker niet aan te raden voor grafische taken op API niveau. Merk ook dat we hier ook geen rekening hebben gehouden met speciale instellingen en mogelijkheden van onze virtualisatiesystemen. In de volgende sectie duiken we dieper in op de grafische virtualisatiemogelijkheden van elk platform. Grafische performance RemoteFX, PCI-passthrough en vsga We merken na wat onderzoek dat elk platform een aantal troeven tot zijn beschikking heeft om de grafische performance wat te verbeteren. Beide platformen bieden dan ook een oplossing aan voor verschillende specifieke situaties waarin we willen gebruik maken van virtualisatie. We moeten echter wel 16

18 letten op een aantal factoren vooraleer we deze troeven kunnen toepassen zoals bv. driversupport en hardwareconfiguratie. Zoals besproken in de vorige testen, merken we dat zowel Hyper-V als Esxi standaard geen grafische hardware virtualiseren. Dit is grotendeels logisch aangezien deze hardware zeer driver gebonden is en in de meeste gevallen zal worden aangesproken met een set API s. We kunnen in theorie onze hypervisor dus een eigen driver laten meegeven aan elke VM en deze een soort sandboxed omgeving geven op de onze hardware zelf. Dit proces wordt standaard al op verschillende soorten hardware toegepast (denk maar aan bv. storage) en geeft ons enerzijds de mogelijkheid om dezelfde hardware beschikbaar te stellen aan meerdere VM s. Anderzijds kunnen we in theorie onze grafische kracht controleren per VM aangezien onze hypervisor als het ware de rol van grafische hardware op zich neemt. Het virtualiseren van hardware op deze manier wordt ook wel eens een abstraction layer genoemd. In de praktijk is dit echter niet efficiënt. Hoewel de moderne server CPU tot op heden slechts één algemene ISA hanteert, zien we dat dit bij grafische hardware volledig anders verloopt. We zitten hier namelijk niet met een eenheid van architecturen (denk maar aan Maxwell, Pascal, Iris, GCN, Kepler, ). Ongeveer elke nieuwe generatie GPU s definieert als het ware een nieuwe taal die de hardware hanteert om bepaalde resultaten te bekomen. Dit wil zeggen dat om dit te kunnen virtualiseren, onze hypervisor al deze talen niet alleen moet kennen (dit gebeurt namelijk door de driver), maar ook een manier moet zoeken om deze hardware in een sanboxed environment beschikbaar te stellen aan de verschillende actieve VM s. Dit is niet alleen zeer complex te implementeren, maar ook zeker niet schaalbaar. Bij elke nieuwe GPU architectuur zou namelijk een nieuwe hypervisor update moeten worden geschreven, deze update moet daarnaast ook op elk ondersteund OS werken. Het zou dus niet alleen zeer kostelijk zijn dit systeem te implementeren, maar ook om te onderhouden. We kunnen onze virtualisatie echter wel uitvoeren op API niveau. Aangezien elke architectuur een groot aantal API-sets ondersteund (DirectX en OpenGL zijn meestal aanwezig) en renderen met hardware acceleration grotendeels wordt gedaan met deze API s, kunnen we alle API-calls op de grafische hardware opvangen op elke VM en deze op een efficiënte manier doorsturen naar onze GPU. Dit proces wordt ook wel eens API-redirection genoemd. Dit proces is niet alleen zeer modulair, aangezien we slechts een beperkte set API s moeten ondersteunen, maar geeft onze VM s ook een sandboxed environment aangezien renderapi s one-way zijn. Een ander voordeel is eveneens dat we vanop onze hypervisor de hardware gewoon verder kunnen gebruiken samen met de actieve VM s. Dit systeem is echter verre van perfect. Een groot probleem waarmee we kampen is het gebruik van VRAM, we moeten er namelijk voor zorgen dat we niet over onze GPU limiet gaan, dit zou anders resulteren tot crashes van de grafische applicaties. Een ander nadeel waarmee we kampen is dat we controle verliezen over onze performance. We sturen namelijk vanop onze hypervisor een API-call gewoon door naar onze GPU. Zowel Windows Server als Esxi komen beiden met een vorm van API-redirection. Wanneer we APIredirection bekijken in Windows Server, stoten we op een Remote Desktop Service genaamd RemoteFX. Let wel dat aangezien dit onder de RDS categorie valt, we deze feature niet kunnen installeren op de gratis Hyper-V server. Je zal dan ook merken dat we hier enkel Windows Server en Esxi bespreken. RemoteFX is in de eerste plaats een API-redirection tool, maar biedt ook een set slimme algoritmes aan waardoor thin clients niet alleen minder belast worden, maar ook een scherper en smoother beeld krijgen in hun RDP-connecties. Deze service ondersteund de volledige DirectX library bij het virtualiseren van 17

19 GPU s, plus een aantal specifieke OpenGL calls. Dit wil zeggen dat deze feature zeer interessant is wanneer we gebruik maken van DirectX applicaties, maar we beter applicaties die OpenGL gebruiken niet riskeren. Het wil ook zeggen dat elke GPU die DirectX enabled is met een driver voor onze Windows Server kan worden gebruikt voor onze VM s. Hoewel enkel de professionele GPU s van AMD (FirePro) en Nvidia (Quadro) officieel ondersteund worden voor Windows Server, hebben we eerder al gezien dat bijna elke Windows 1 ondersteunde GPU gebruikt kan worden. Dit geeft ons niet alleen de mogelijkheid om de R9 39X te gebruiken voor onze VM s, maar dit wil ook zeggen dat Windows Server hier een serieus beentje voor heeft op Esxi in het kader van GPUondersteuning. Na de Crimson driver geïnstalleerd te hebben, kunnen we deze kaart ook registreren in Hyper-V als RemoteFX enabled card. Let wel dat RemoteFX slechts één GPU per host ondersteund. Dit wil zeggen dat AMD Crossfire en Nvidia SLI niet mogelijk zijn binnen Hyper-V, maar ook twee GPU s die onafhankelijk van mekaar werken zijn niet toegelaten. Dit is enerzijds wel logisch aangezien onze VM s hier als het ware rechtstreeks werken op de driver in onze hypervisor. Wanneer we onze GPU geregistreerd hebben als RemoteFX adapter, kunnen we deze instantiëren op onze VM s. We worden hier ook gevraagd om een VRAM limiet in te stellen van maximaal 124MB. Dit zal er uiteraard deels voor zorgen dat twee VM s elkaar niet overlappen in VRAM gebruik. Let wel dat deze limiet niet automatisch zal schalen of rekening zal houden met andere actieve VM s. in onze situatie waar we 8GB GDDR5 VRAM ter beschikking hebben, wil dat zeggen dat wanneer acht VM s hun volledige 124MB in gebruik hebben, er applicaties zullen crashen aangezien onze hypervisor ook VRAM in gebruik heeft. Uiteraard zal onze hypervisor ook geen rekening houden met deze limieten en aangezien hij zelf geen limiet heeft gekregen, is het dan ook niet aangewezen grafische applicaties op de hypervisor zelf te draaien terwijl VM s gebruik maken van een remotefx adapter. We creëren in de volgende test twee situaties. Enerzijds herbekijken we een aantal grafische tests met een remotefx adapter op één VM om te zien hoeveel performance winst we nu eiglijk halen. Anderzijds zullen we deze testen ook schalen naar twee VM s om te zien hoe de grafische performance schaalt. We hebben hier namelijk geen directe relatie met het tijdsslotenmodel van de vcpu s. We krijgen de volgende resultaten te zien: 18

20 3D performance - Total No RemoteFX RemoteFX Hardware 3Dmark - total No RemoteFX RemoteFX Hardware Wat meteen opvalt is dat onze DirectX performance meteen een stuk dichter komt bij onze Windows 1 client (1-2%). Dit lijkt op zich vrij weinig en we zien inderdaad nog steeds een zeer hoge overhead tov de fysieke mogelijkheden van onze hardware. Wanneer we echter kijken naar de schaling over meerdere VM s, worden onze resultaten een stuk interessanter. Uiteraard zien we in vele situaties een performance drop tov onze configuratie met één VM, maar deze drop is echter veel te klein om ervan uit te gaan dat onze ene VM enkel door hypervisor overhead een relatief zwak resultaat behaalt. We zien zelfs een aantal situaties waarin onze performance zelfs stijgt bij de aanwezigheid van meerdere parallelle VM s. 19

21 Om deze situatie logisch te benaderen, kunnen we het proces analyseren die onze tests zullen uitvoeren om tot een resultaat te komen. Vele applicaties die gebruik maken van hardware accelerated rendering maken namelijk nog steeds gebruik van een standaard systeem. Hieronder kunnen we een grafische voorstelling zien om onze analyse visueel bij te staan: Figure 7 Gameloop We onderscheiden met andere woorden twee aparte processen. Enerzijds zullen we een bepaalde logica berekenen, deze CPU berekeningen zullen bv. bepalen waar bepaalde objecten zich bevinden, hoe ze geschaald zijn, in welke hoek onze camera zich bevindt, etc. Het is belangrijk dat dit om een CPU-intensief proces gaat en deze dus ook de vcpu gerelateerde regels zal volgen. In de tweede fase zullen we het beeld van de Gamelogic fase gaan renderen, dit proces bestaat erin dat we de renderapi s zullen aanspreken om een bepaald object te renderen op een bepaalde resolutie. Dit proces is dus deels CPU-intensief, maar zal grotendeels worden uitgevoerd door de GPU. We moeten er ook op letten dat dit proces in een sandboxed omgeving moet draaien, we willen bijvoorbeeld niet dat een beeld die wordt uitgevoerd door een VM rechtstreeks op ons scherm zal terecht komen. Onze hypervisor moet met andere woorden deze API-calls sturen zodat zijn eigen renderproces niet in de war komt. In conclusie kunnen we dus twee vaste delays onderscheiden. Enerzijds volgen we nog grotendeels het tijdsslotenmodel dat eerder werd besproken, dit wil zeggen dat theoretisch gezien onze framerate sterk zal afhangen van onze vcpu opstelling en niet zozeer van onze GPU. Omdat deze vcpu s dynamisch kunnen schalen door onze Hardware Accelerated Virtualisation, stellen we uiteraard een zeer efficiënte schaling vast bij vele testen omdat de gamelogic meestal slechts twee of drie threads in beslag zal nemen. We kunnen die ook goed zien in de physics test, waar we geen performance drop vaststellen wanneer we schalen naar meerdere VM s. Uiteraard hebben we bij het draaien van slechts één VM al te maken met een zeer grote overhead. Dit is op het eerste zicht niet erg logisch aangezien onze vcpu s dynamisch schalen. We kunnen echter wel vaststellen dat in vorige tests onze CPU overhead bijzonder hoog ligt bij 2

22 het draaien van slechts 1 VM. Hoewel dit zeker zal helpen in de performance drop, kunnen we dit uiteraard niet als enige oorzaak zien. We moeten ons echter wel bewust zijn van het feit dat een GPU zich redelijk autonoom gedraagt. Dit wil zeggen dat deze in staat is een volledig beeld te renderen zonder tussenkomst van extra code of de CPU in het algemeen. Dit wil zeggen dat als we nood hebben aan een soort synchronisatieproces op onze hypervisor om te voorkomen dat het renderproces van onze VM s in de weg zullen staan met onze hypervisor of andere VM s. Dit wil zeggen dat onze framerate eveneens sterk zal afhangen van de beslissingen die de hypervisor neemt, wat in de eerste plaats zeer negatief lijkt voor onze VM performance. Uiteraard wil dit ook zeggen dat onze VM s in complete isolatie kunnen bestaan tov elkaar en met onze hypervisor, wat wil zeggen dat de renderprocessen van zowel de VM s als de hypervisor elkaar niet zullen beïnvloeden, wat dus een zekere stabiliteit geeft. We zien dan ook dat we steeds efficiëntere resultaten krijgen naarmate we meer VM s gebruik laten maken van RemoteFX, wat eveneens veel efficiëntie zal geven in realistische praktijkscenario s. Deze scenario s zijn jammer genoeg redelijk gelimiteerd. Hoewel het handig is om een GPU te virtualiseren over meerdere VM s, hebben we weinig controle over hoe de middelen worden verdeeld. In vele praktrijksituaties waar hardware accelerated rendering nodig is, zien we dat het efficiënter is om praktisch alle middelen beschikbaar te stellen aan één proces, aangezien de kans redelijk klein is dat alle VM s constant moeten renderen. We stellen bijvoorbeeld een rendersituatie voor waar drie VM s aanwezig zijn die elk een verschillende rendertaak op zich nemen. Een groot deel van de situaties zal machine A bijvoorbeeld een taak op zich nemen, en na een periode machine B of C. Hoewel het efficiënter zou zijn wanneer we machine A alle middelen geven zodat deze de taak zo snel mogelijk kan vervolledigen, is deze bij RemoteFX beperkt tot een zeer limiterende set van middelen. Dit maakt het geheel onnodig traag. Het feit dat we ook maximaal slechts 124MB VRAM kunnen voorzien per VM sluit eveneens zeer intensieve taken uit. High memory assets en hoge resoluties zijn dus eveneens uitgesloten bij het gebruiken van RemoteFX. De grootste teleurstelling is uiteraard dat onze applicaties gelimiteerd zijn tot DirectX, bij het testen van meerdere OpenGL applicaties (blender, autocad, World of goo, GFX, ) stellen we crashes, freezes, etc vast of gewoon de tekortkoming van hardware accelerated rendering. Ook bij Linux systemen zoals Ubuntu zien we geen verschil in benchmarkresultaten wanneer we RemoteFX instellen. In een professionele omgeving (zoals bijvoorbeeld renderfarms) zien we dan ook dat er meestal gebruik wordt gemaakt van speciale drivers en API s (denk maar aan VRay en IRay) om zeer hoge kwaliteitsbeelden te renderen. Deze zullen uiteraard ook niet ondersteund worden in RemoteFX. DirectX lijkt echter wel zeer vlot te werken (met uitzondering van games). Aangezien deze technologie ook perfect werkt met RDP, kunnen we een situatie waar Photoshop werk wordt gedaan op thin clients als realistisch beschouwen. Dit wil zeggen dat we als systeembeheerder enkel moeten investeren in een één centrale locatie, wat serieus wat tijd en geld bespaart. Ook het feit dat we een consumenten GPU kunnen gebruiken is eveneens een zeer groot voordeel. Niet alleen omdat deze kaarten goedkoper zijn, maar deze zijn eveneens op vele vlakken performanter dan professionele kaarten wanneer API s zoals DirectX worden gebruikt. In het andere kamp biedt Esxi ook GPU virtualisatie aan met hun vsga technologie. vsga gebruikt de eerder vermelde abstraction layer. Uiteraard wil dit in de eerste plaats zeggen dat ondersteunde API-set 21

23 hier duidelijker breder zal zijn dan wat we zagen bij RemoteFX. We zullen dus met andere woorden meerdere soorten applicaties toegang kunnen geven tot onze GPU. Hierdoor zullen ook Linux systemen meer middelen ter beschikking krijgen, dus zijn we niet beperkt tot één bepaald systeem omdat deze als enige een API gebruikt. Aan de andere kant is de hardwaresupport bij Esxi zeer teleurstellend, slechts enkele professionele kaarten worden ondersteund. In de volgende lijst kunnen we een kleine opsomming zien: AMD FirePro S4X AMD FirePro S7 AMD FirePro S9 AMD FirePro S95 AMD FirePro W7 GRID K1 kaarten GRID K2 kaarten Tesla M6 Tesla M6 HD Graphics P47 We zien dat hier enkel workstation- en serverkaarten worden ondersteund. Uiteraard zijn deze kaarten ook een pak duurder dan onze R9 39X die we reeds gebruikten voor onze vorige tests. Het is ook belangrijk dat we opmerken dat de ondersteunde Nvidia GPU s allemaal GRID ondersteunen. GRID is een GPU virtualisatietechnologie ontwikkeld door Nvidia zelf. De kans is groot dat deze technologie die werd ontwikkeld door de GPU-fabrikant zelf, veel hogere performance en support zal genieten dan de algemene abstraction layer van VMware. Wanneer we deze abstraction layer technisch benaderen, stellen we enerzijds een aantal grote voordelen alsook nadelen vast tov de RemoteFX technologie. Het eerste grote voordeel is dat Esxi de verantwoordelijkheid voor vsga support veel zal leggen bij de GPU-vendor. Onze GPU fabrikant moet met andere woorden zelf vsga support injecteren in hun drivers. Deze zullen dan via een speciale driver in VMwaretools doorgevoerd worden naar de client. Dit wil zeggen dat onze beschikbare API-set dezelfde zal zijn die op de GPU wordt ondersteund, wat op zich een groot voordeel biedt over RemoteFX waar we grotendeels beperkt waren tot DirectX. We zien uiteraard ook snel de keerzijde van deze keuze hierboven wanneer we de beschikbare hardware voor deze technologie opsomden. Het beperkte aantal modellen is niet alleen veel duurder dan onze consumentenvarianten, maar zijn meestal ook zeer beperkt in kracht. We zien namelijk dat wanneer we de FirePro S95 vergelijken met onze R9 39X, onze consumentenkaart bijna drie keer zo snel (3.23 TFLOPS tov 8.6 TFLOPS) is in fysieke kracht terwijl deze slechts 25% van de prijs bedraagt. We moeten er hier echter wel bij melden dat het kiezen van een professionele workstation of serverkaart vele voordelen met zich meebrengt. Zo zien we bijvoorbeeld dat de S95 professionele zaken aanbiedt zoals ECC memory, extended support, low power consumption en speciale drivers voor zowel Windows Server, Esxi en Citrix Xenserver. Aan de andere kant kunnen we er ook vanuit gaan dat deze kaarten ook grotere performancewinst zullen bieden op RemoteFX aangezien deze technologie ook officieel ondersteund worden door de vendor. Omdat we geen GPU uit bovenstaande lijst ter beschikking hebben, kunnen we het performance verschil tussen hardware clients en vsga uiteraard niet testen. We kunnen enkel afgaan op speculaties en 22

24 testresultaten van derden. Deze resultaten zijn zeer beperkt. We vinden namelijk geen enkele objectieve vergelijking die ons de overhead toont van de virtualisatietechniek die Esxi hier hanteert. We zien echter aan de hand van gelezen opinies en testen uitmaken dat Hardware Acceleration vrij goed werkt op de meeste professionele workloads. Er zijn echter twee benchmarks die zeer interessante resultaten geven. De benchmarks in kwestie werden genomen door Gunnar Berger, CTO van Citrix s Desktop and Apps group. Zijn benchmarks vergelijken grotendeels de vsga technologie op Esxi tov Nvidia s GRID technologie op Xenserver in performance en grafische resultaten. Het is ook belangrijk om te weten dat deze benchmarks werden genomen eind 213. Dit wil enerzijds zeggen dat deze tests draaiden op een Esxi 5.5 host, wat dus een ouder systeem is dan wat we hier behandelen. Anderzijds kunnen we ook afleiden dat, aangezien Gunnar Berger pas in 214 bij Citrix aan de slag ging, we hier min of meer ook te maken hebben met een objectieve vergelijking. Voor deze testen voerde hij zowel de Heaven DirectX benchmark uit, alsook een CAD performance benchmark voor real time rendering, wat gebruik maakt van de OpenGL API. We kunnen de volgende eindresultaten waarnemen: vsga vs vgpu - CAD Vmware vsga Nvidia vgpu vsga vs vgpu - Heaven Vmware vsga Nvidia vgpu We kunnen al snel zien dat de virtualisatietechnieken van Nvidia hier zeer superieur zijn tov de deze in vsga. We zien dat we ook in het verloop van de benchmark stoten op heel wat grafische fragments en 23