Hypervisor gebaseerde x86 virtualisatie Xen en VMware ESX

Transcriptie

1 Hypervisor gebaseerde x86 virtualisatie Xen en VMware ESX Philip Dubois & Thomas De Ly Academiejaar Promotor: Lector J. De Gelas, Sizing Servers Lab Scriptie voorgedragen tot het behalen van de graad van Bachelor in de Multimedia en Communicatie Technologie

2 De auteur en promotor geven de toelating deze scriptie voor consultatie beschikbaar te stellen en delen ervan te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting uitdrukkelijk de bron te vermelden bij het aanhalen van resultaten uit deze scriptie. The author and promoter give the permission to use this thesis for consultation and to copy parts of it for personal use. Every other use is subject to the copyright laws, more specifically the source must be extensively specified when using from this thesis. Kortrijk, Mei 2008 De auteurs, Philip Dubois, Thomas De Ly

3 Woord vooraf Om onze opleiding Multimedia en Communicatie Technologie af te ronden, dienden wij een een projectmatige stage te volgen, en dit document is hiervan het resultaat. Wij kregen de kans om mee te draaien in het innovatieve Sizing Servers Lab, onder leiding van J. De Gelas, en gehuisvest in het Departement PIH van de Hogeschool West-Vlaanderen. Hier onderzochten wij de performantie impact van virtualisatie, toegespitst op de technologiën van VMware en Xen. Het werk werd verdeelt. Zo werkte Thomas rond VMware ESX en heeft hij de real world testopstelling uitgewerkt. Philip werkte met de Xen technologie en heeft het worst load testscenario opgezet. Philip Dubois, Thomas De Ly Kortrijk, juni 2008 Dankwoord Thomas Graag wens ik Johan De Gelas te bedanken voor deze leuke stage. Virtualisatie was iets nieuw voor mij, ook het werken met de vele (dure) servers was verrijkend. In het laaste jaar de kans krijgen om met uniek materiaal te werken is niet iedereen gegund. Het team in het Sizing Servers Lab heeft ons warm onthaald en de nodige begleiding gegeven. Af en toe een pot koffie, de nodige bijsturing en vooral het plezier doorheen de stage. Het was een leuke ervaring maar het belangrijkste is dat ik nu een heel andere manier van denken heb. Nieuwe technologieën onderzoeken, testen en daarvan een conclussie nemen het was allemaal vrij nieuw voor mij. Deze stage is dan ook een mooi slot van mijn MCT carriére. Ook Geert Hofman wens ik te bedanken voor het begrip en de begeleiding doorheen deze stage. Met Elisabeth van Dijk, onze interne stagecoatch, was het aangenaam samenwerken, ook de mede stagestudenten waren één voor één toffe kerels die maar al te graag eens brainstormden over verschillende theorieën. Verder wens ik mijn familie te bedanken voor de hulp en het vele verbeterwerk aan de thesis. En mijn vriendin, Charity Hochedez, voor het begrip en de steun tijdens de stageperiode. En last but not least wens ik Philip te bedanken voor de leuke samenwerking. Zijn nogal extreme open-source ingesteldheid heeft mij ook op bepaalde gebieden doen nadenken. Ook zijn kennis over linux Operating Systems (OSs) was voor mij heel leerrijk. ii

4 Philip Bij deze zou ik een paar mensen willen bedanken voor hun steun en hulp bij m n stage, en mijn MCT studies in het algemeen: M n partner in dit project, Thomas. Hoewel het niet altijd even makkelijk is om met zo n mierenneuker als ik samen te werken, gingen we dit project samen aan. De mensen van het Sizing Servers Lab. Zo bedank ik Johan De Gelas voor het aanbieden en ten volle steunen van dit uitdagend project. Johan volgde ons steeds vol enthousiasme op en wist de moed erin te houden. Af en toe diende hij er terecht de zweep eens bij te houden om ons op schema te houden. Werken met zo n bron van onuitputtelijke informatie is zeer aangenaam, en ik kijk dan ook uit naar een verdere samenwerking. Dan hebben we Tijl Deneut, die ons met alles in het lab vertrouwd maakte, en onze collega student, Aswin Coolsaet Windows Man, die er steeds weer was voor allerhande opzoekwerk en must-know tips ivm. Windows optimalisaties. Verder wil ik ook Elisabeth Van Dijk bedanken voor het steeds bijstaan bij allerhande softwareproblemen, en Tjerk Ameel voor het prachtige logo dat dit document siert. Tenslotte zijn er nog the programmers!, Dieter Vandroemme en Yves Wouters, voor de prachtige vapus testomgeving en het brengen van mijn koffie op gezette tijden. Mijn ouders, meer bepaald m n vader Harry Dubois en stiefmoeder Nora Vanden Berghe, alsook mijn zus Julie Nagels en mijn vriendin Elke Matthijs voor alle steun die ze steeds bieden en alle interesse naar mijn werk. Zo hebben m n ouders mij ook steeds gesteund in mijn studiekeuze, ook al moest ik dan op kot in dat verre land Kortrijk. Ook wil ik m n goeie maat, Nick Vannieuwenhoven, bedanken voor de grote interesse in dit project en het steeds weer doornemen van mijn tekst. Hij had vaak goede suggesties en ook hielp hij mij met bepaalde aspecten beter uit te diepen. En dan is er uiteraard nog Stijn Verslijcken, om mij aan deze stage te helpen door mijn naam aan Johan door te geven. iii

5 Inhoudsopgave 1 Inleiding Sizing Servers Lab Virtualisatie x86 Virtualisatietechnieken Hypervisor Ring deprivileging Binary Translation System Calls Toegang tot de chipset en I/O, interrupts en DMA Memory Management Paravirtualization Hardware Assisted Virtualization Eerste generatie Tweede generatie: Hardware Assisted Pages (HAP) Full Virtualization Xen Omschrijving Terminologie Architectuur Xen paravirtualization De hypervisor en het Privileged Domain CPU-tijd en scheduling Hypercalls Privileges en geheugenbeheer Drivermodel Virtuele netwerking Hardware Virtual Machines Praktisch gebruik van Xen Inleiding Installatie Vereisten om Xen te gebruiken iv

6 Inhoudsopgave Installatie van binaire pakketten Installatie vanaf de broncode Commerciële Xen opties Xen beheer met de Xen Manager Algemene xm opties Creëeren van een DomainU systeem Het beheer van een DomU Monitoren van DomUs Xen troubleshooting Netwerkproblemen De xend daemon wil niet opstarten VMware ESX VMware inleiding VMware ESX De console Architectuur van VMware ESX VMware ESX 3.5 nieuwigheden VMware ESX ontleding VMFS Onderdelen van een VM VMware tools Monitoring in VMware ESX VMware Infrastructure Client esxtop Andere VMware toepassingen VirtualCenter Agent : Consolidated Backup : Update Manager : VMware HA : VMotion : Storage VMotion : VMware DRS : Virtual Center Server : Maintenance en Standby Modes Maintenance Mode Standby Mode Praktisch gebruik van VMware ESX VMware ESX 3.5 installatie Aligneren VMware Infrastructure Client (VIC) Overzicht van de host v

7 Inhoudsopgave 6.4 Virtual Machine (VM) Toolbar Nieuwe Machine aanmaken Installatie VMware Tools Windows 2003 Server Sles Settings van de Virtuele machines Hardware Options Resources Troubleshooting KERNEL MOUNTING FAILED Problemen met de AMD Opteron 8356 CPU Benchmarks: Worst load scenario Inleiding Opzet Sysbench: Online Transaction Processing (OLTP) benchmark Algemeen sysbench testprotocol Xen benchmarks RAID configuratie - WriteBack vs. WriteThrough Xen Quad Opteron Xen Quad Opteron 8356 numa=on Xen Quad Xeon E Xen Quad Xeon E Xen Dual Opteron Xen Dual Xeon E Xen Quad Opteron VMware benchmarks Dual Opteron Conclusies Xen VMware tegenover Xen Benchmarks: Real world scenario Opstelling Testsoftware vapus Soorten tests Swingbench (charbench) Praktisch Test instellingen cpu s per virtuele machine cpu s per virtuele machine vi

8 Inhoudsopgave 8.5 VMware benchmarks dual vs 7330 quad quad vs 7350 quad VMware vs Xen Opteron 8356 vs Xeon Conclussies Xen vs VMware Algemene Conclusies 89 A Google Ganeti 91 A.1 Omschrijving A.2 Mogelijkheden A.3 Vergelijking traditionele HA & Ganeti A.4 Ganeti DRBD System Recovery A.5 Toekomst A.6 Meer informatie B OpenVZ 95 B.1 Omschrijving B.2 OpenVZ Virtualisatie B.2.1 OS Virtualisatie B.2.2 Netwerk Virtualisatie B.3 Resource Management B.4 Meer Informatie C Test Protocol 98 C.1 Virtuele machines : C.2 Fysieke Server C.3 Rapportering en monitoring D Resultaat tabellen 100 E Testconfiguraties 113 F Scripts 117 F.1 Linux sysbench scripts Woordenlijst 121 Bibliografie 124 Projectfiche en -samenvatting 126 Stageverslagen en planning 129 vii

9 Lijst van tabellen 4.1 Benodigde software voor het compileren van Xen Speciale console commando s overzicht van de gebruikte RAID configuratie D.1 Writeback performantie in sysbench D.2 Writethrough performantie in sysbench D.3 Xen Quad Opteron 8356 sysbench resultaten D.4 Xen Quad Opteron 8356 numa=on sysbench resultaten D.5 Xen Quad Xeon E7330 sysbench resultaten D.6 Xen Quad Xeon E7340 sysbench resultaten D.7 Xen Dual Opteron 8356 sysbench resultaten D.8 Xen Dual Xeon E7330 sysbench resultaten D.9 Xen Quad Opteron 8356 sysbench resultaten D.10 VMware ESX Dual Opteron 8356 sysbench resultaten D.11 VMware esx Dual Xeon E7330 Windows resultaten D.12 VMware esx Quad Xeon E7330 Windows resultaten D.13 VMware esx Quad Xeon E7350 Windows resultaten D.14 Xen Quad Xeon E7330 Windows resultaten E.1 Opteron 8356 testconfiguratie E.2 Xeon E7330 testconfiguratie E.3 Xeon E7340 testconfiguratie E.4 Xeon E7350 testconfiguratie viii

10 Lijst van figuren 1.1 Het Sizing Servers Team Verloop van het gebruik van virtualisatie in de loop der jaren Consolidatie door middel van virtualisatie Kernel en User Mode Ring deprivileging Binary Translation Binary Translated Code System Calls Problem Shadow Page Tables Hardware Assisted Virtualization Hardware Assisted Virtualization Hardware Assisted Pages. Ook wel Nested of Extended Page Tables genoemd Het logo van Xen Overzicht van de Xen architectuur Basisorganisatie van de Xen componenten Geheugenbeheer: Xen s pseudo-physical memory versus shadow pages Privilege ring model bij een 64-bit systeem Domain0 bevat de native en backend drivers, dewelke DomainU aanspreekt via diens frontend-drivers Xen driver model Netwerking binnen een Xen systeem Xen full virtualization dmv. QEMU De interactie met de xend daemon, via het xm commando VMware Performance in VIC VMware HA VMotion Storage VMotion DRS Installatie VMware ESX ix

11 Lijst van figuren 6.2 Partitionering VMware ESX VMware ESX startscherm Host overzicht in VIC VM overzicht in VIC Toolbar in VIC VMware virtual machine options VMware virtual machine options VMware virtual machine options QuadBarcelona CPU Snapshot disabeling access Schematische weergave van de Linux worst load testopstelling Sysbench: WriteBack versus WriteThrough resultaten Sysbench: Xen Quad Opteron Sysbench: Xen Quad Opteron 8356 numa=on Sysbench: Xen Quad Xeon E Sysbench: Xen Quad Xeon E Sysbench: Xen Dual Opteron Sysbench: Xen Dual Xeon E Sysbench: Xen Quad Opteron Sysbench: Quad Opteron 8356 en Quad Xeon E Power metingen bij de Opteron 8356 en Xeon 7330 (lager is beter) Sysbench native: CPU load bij Dual en Quad Opteron 8356 opstellingen Sysbench: Xen en VMware ESX op de dual Opteron Windows test opstelling Testopstelling vapus As Soon As Possible Continous Rate vapus Apus Webbenchmark Apus Database Benchmark Apus SlaveControlCenter SlaveGroup dual vs 7330 quad charbench dual vs 7330 quad CPU belasting charbench dual vs 7330 quad CRDBBenchmark dual vs 7330 quad CRWebHttpBenchmark quad vs 7350 quad charbench quad vs 7330 quad CPU belasting charbench Xen vs VMware OLTP Xen vs VMware WebBench vs 7330 WebBench vs 7330 BenchDB x

12 Lijst van figuren vs 7330 Oltp A.1 Opbouw van een Ganeti cluster A.2 Traditionele High Availability oplossing A.3 De Google Ganeti High Availability oplossing A.4 Schijf failover met Google Ganeti B.1 OpenVZ: container based virtualisatie xi

13 Hoofdstuk 1 Inleiding 1.1 Sizing Servers Lab Het lab waar wij de kans kregen om dit onderzoek uit te voeren is de eerste plaats waar onze resultaten toegepast zullen worden. Sizing Servers is een onderneming, gesubsidiëerd door de Vlaamse Overheid, die in contact staat met talloze Vlaamse KMO s. Algemeen kunnen we stellen dat de consumentenmarkt in de IT-wereld momenteel gecontroleerd wordt door voornamelijk Amerikaanse software-giganten. Proberen concurreren in deze markt is voor een KMO in ons Vlaanderen zo goed als nutteloos. Toch staan we op vlak van softwareontwikkeling zeker op de kaart, en dit het ontwikkelen van zeer specifieke en gespecialiseerde applicaties. Figuur 1.1: Het Sizing Servers Team. 1

14 Hoofdstuk 1. Inleiding Het sizen van deze applicaties is waar het lab zich, in de samenwerking met KMO s, in de eerste plaats op toespitst. Het analyseren van de toepassingen die de KMO s gebruiken, en op basis daarvan gebaseerd een gedetailleerd onderzoek naar de impact van bepaalde harden software onderzoeken. 1.2 Virtualisatie Virtualisatie is in deze groene tijden een hot topic geworden. Volgens een paper van het IDC 1 [13] zou het gebruik van virtualisatietechnologiën jaarlijks stijgen met zo n 47 %. Zo is een van de belangrijkste voordelen van virtualisatie consolidatie (fig. 1.3). Met consolidatie doelt men op het ten volle benutten van een fysieke server, door er een groot aantal Virtual Machines (VMs) op te plaatsen. Zodoende spaart men hardware, plaats en stroom uit. Figuur 1.2: Verloop van het gebruik van virtualisatie in de loop der jaren. In de meeste publicaties zijn de testscenario s vaak onrealistisch; men wil hun product uiteraard in een zo goed mogelijk daglicht plaatsen. Deze publicaties laten gewoonlijk een vergelijking zien tussen een native situatie, en een situatie waar het geheel gevirtualiseerd wordt uitgevoerd. Hier toont men echter steeds het resultaat in een situatie waar slechts een enkel VM draait. Van het feit uitgaande dat consolidatie de meest aangeworven toepassing is van hypervisor gebaseerde virtualisatie, is dit een zeer onrealistische testopstelling. Verder wordt er het vaakst getest met synthetische benchmarks, die vooral CPU intensief zijn. Maar puur rekenwerk is probleemloos te virtualiseren. De grootste virtualisatie overhead treedt echter op als er veel calls naar de hardware gemaakt worden en er veel interrupts gegenereerd 1 2

15 Hoofdstuk 1. Inleiding worden. Met andere woorden, als er veel op I/O apparaten wordt gesteund. Figuur 1.3: Consolidatie door middel van virtualisatie. Met dit onderzoek willen we de performantie impact van real world toepassingen van hypervisor gebaseerde virtualisatie, met Xen en VMware, profileren. Hiervoor moeten we eerst een goede kennis hebben van de gebruikte technologie (hoofdstukken 3 en 5), waarna we over gaan tot het benchmarken. Dit benchmarken wordt uitgevoerd aan de hand van twee testopstellingen; namelijk een worst load scenario (hoofdstuk 7) en een real world scenario (hoofdstuk 8). 3

16 Hoofdstuk 2 x86 Virtualisatietechnieken In dit hoofdstuk worden kort de virtualisatietechnieken met hypervisor toegelicht. Voor een uitgebreide uiteenzetting over virtualisatie, en de impact van hardware assisted virtualization, verwijzen we de lezer graag door naar het artikel van J. De Gelas [10]. 2.1 Hypervisor Om verschillende OSs op één fysieke machine te laten werken is er een extra software laag nodig, de hypervisor of Virtual Machine Monitor (VMM). Zijn belangrijkste rol is de toegang van virtuele OSs te regelen naar de onderliggende hardware. Op deze manier is het mogelijk om meerdere OSs virtueel te laten werken op één host systeem. Om precies te begrijpen wat een VMM doet moeten we eerst begrijpen hoe een modern OS werkt. De meeste OSs werken in twee modes: Kernel Mode(ring 0) kan bijna elke CPU instructie runnen, inclusief geprivilegieerde instructies die moeten omgaan met interrupts, geheugen management,... Dit is natuurlijk de mode waar de kernel van het OS in werkt. User Mode(ring 3) laat alleen instructies toe die nodig zijn om te rekenen of om data te verwerken. Applicaties werken altijd in deze modus en kunnen alleen gebruik maken van hardware door een system call uit te voeren (deze zal communiceren met de kernel). Het volledige kernel- en usermode systeem is gebaseerd op het feit dat het werkgeheugen ingedeeld is in pages. Vooraleer een geprivilegieerde instructie wordt uitgevoerd gaat de CPU eerst controleren of de page waar de instructie vandaan komt de juiste 2-bit code heeft. De meest geprivilegieerde instructies hebben zo een 00 code nodig. Deze 2-bit code laat vier levels toe met 11 als laagste level. De 2-bit code wordt veelal voorgesteld door vier ajuin ringen. Ring 0 is de meest geprivilegieerde laag, ring 1 minder en ring 3, waar de gebruiker zijn applicaties laat draaien, heeft geen rechten om hardware te beheren. 4

17 Hoofdstuk 2. x86 Virtualisatietechnieken Figuur 2.1: Kernel en User Mode. 2.2 Ring deprivileging Een techniek die voor alle software gebaseerde virtualisatie oplossingen wordt gebruikt is ring deprivileging. Hier wordt het OS verplaast naar een andere ring (bijvoorbeeld ring 1 ). Dit laat de Virtual Machine Monitor (VMM) toe om de toegang van het guest OS naar de hardware resources te controleren. Zo krijgt een guest OS geen directe controle over de hardware. Figuur 2.2: Ring deprivileging. Er is echter een groot probleem met ring deprivileging. Elke geprivilegieerde instructie uitgevoerd door een VM zorgt voor een trap, een fout, omdat deze VM in een lager geprivilegieerde ring werkt. De VMM vangt al deze traps op en emuleert de instructie zonder de integriteit van andere VMs in het gedrang te brengen. Om performantie redenen is geprobeerd om het aantal traps, en de tijd nodig om die af te handelen, te reduceren. Het probleem met een x86 CPU is dat bepaalde instructies uit ring 1 gewoon genegeerd worden. Hieruit volgt dat als een guest OS een interrupt uit probeert te schakelen, dewelke 5

18 Hoofdstuk 2. x86 Virtualisatietechnieken echter niet opgevangen wordt, en de VMM weet niet wat er gebeurt. Tot overmaat van ramp hebben x86 CPUs 17 van deze instructies die niet getrapped worden. Deze worden de x86 stealth instructions genoemd. 2.3 Binary Translation VMware is niet blijven wachten op een oplossing voor de x86 stealth instructions en begon te werken aan een eigen oplossing (anno 1999). Deze kwam er door Binary Translation, de binare code die de kernel van een guest OS genereert. Dit gebeurt on the flyën slaat de aangepaste x86 code op in een Translator Cache (TC). Gebruikersapplicaties (ring 3) worden door de VMware Binary Translator (BT) niet aangeraakt omdat deze code als safe wordt beschouwd. Dus worden gebruikersapplicaties onmiddelijk uitgevoerd alsof deze native werken. De kernel code die nu in ring 0 wordt uitgevoerd is een door de BT vertaalde Figuur 2.3: Binary Translation. code van het guest OS. In bepaalde omstandigheden wordt de BT gegenereerde code langer dan de originele code. Als een guest OS een geprivilegieerde instructie wenst uit te voeren zal de BT deze namelijk omvormen tot een veiligere usermode code. Deze veilige code zorgt ervoor dat de werking van andere VMs en de VMM zelf niet in het gedrang komt. Figuur 2.4: Binary Translated Code. 6

19 Hoofdstuk 2. x86 Virtualisatietechnieken VMware probeert ook de overhead van de BT zo laag mogelijk te houden door de instructiestroom niet te gaan optimaliseren maar deze wel in een cache te steken. Als er een loop is kan deze code dus snel weer opgevraagd worden en wordt de vertaling slechts eenmaal uitgevoerd. BT staat echter nog voor enkele uitdagingen: System Calls Een system call is het resultaat van een usermode applicatie die een service van de kernel vraagt. De x86 instructieset biedt een low-latency manier om de system calls te verwerken: SYSENTER (of SYSCALL) en SYSEXIT. Een system call zal de VMM en vooral de BT extra werk geven. Het probleem is dat een SYSENTER ( request the service of the kernel ) naar een page wordt gestuurd met privilege 0. Het verwacht daar een OS te vinden maar komt bij de VMM uit. Zodoende moet de VMM iedere system call emuleren, de code omvormen om vervolgens de controle over te laten aan de vertaalde kernel code, die in ring 1 draait. Eenmaal de binary translated code van het guest OS uitgevoerd is zal deze een SYSEXIT naar de user generen. Het guest OS werkt echter op een ander niveau en heeft dus niet de nodige privileges om SYSEXIT uit te voeren dus stuurt de CPU een fout naar ring 0, waar de VMM de call van de guest vertaalt. Figuur 2.5: System Calls Problem. Het is duidelijk dat system calls veel overhead veroorzaken. Deze kosten de VM tienmaal meer cycles dan een native machine Toegang tot de chipset en I/O, interrupts en DMA Een groot probleem voor elke vorm van virtualisatie is I/O. Als de host machine niet genoeg CPU kracht heeft dan kan je CPU s met meer cores plaatsen. Maar de geheugen bandbreedte, de chipset en de storage HBA zijn in de meeste gevallen gedeeld door alle VMs en een stuk moeilijker te upgraden. In tegenstelling tot de CPU is de meeste hardware van een VM geëmuleerd. Dit betekent dat elke toegang tot de driver van virtuele hardware moet omgevormd worden door BT naar de echte driver. 7

20 Hoofdstuk 2. x86 Virtualisatietechnieken Zo moeten moderne fysieke servers samen werken met een in VMware ESX geëmuleerde chipset, een negen jaar oude BX chipset en de HBA, een oude Bus Logic of LSI card. Dit betekent ook dat nieuwe features in het guest OS, voor verbetering van performantie, met de hardware niet gebruikt kunnen worden Memory Management Een OS gebruikt page tables om virtuele memory pages te vertalen in fysieke geheugen adressen. Alle moderne x86 procesoren ondersteunen virueel geheugen in de hardware. De vertaling van virueel tot fysieke adressen wordt uitgevoerd door de Memory Management Unit (MMU). Het adres wordt opgeslaan in het CR3 register (hardware page table pointer) en de meest gebruikte onderdelen van de page table worden gecached in de Translation Lookaside Buffer (TLB). Het is duidelijk dat een guest OS geen toegang mag hebben tot de echte page tables. In plaats hiervan ziet een guest OS page tables op een geëmuleerde MMU. De echte pages zijn verborgen voor het guest OS en worden beheerd door de VMM. Er wordt gebruik gemaakt van shadow page tables, die de virtuele adressen van het guest OS vertalen naar fysieke pages. Telkens een guest OS zijn page mapping aanpast, zal de MMU de shadow page tables aan- Figuur 2.6: Shadow Page Tables. passen. Dit kost echter veel CPU cycles, drie tot 400 maal meer dan in een native situatie. Het resultaat is dat met geheugen intensieve applicaties, in een gevirtualiseerde omgeving, het grootste verlies te vinden is bij het werkgeheugen beheer. 2.4 Paravirtualization Paravirtualisatie is een virtualisatietechniek die een software interface aan VMs voorstelt, gelijkaardig (maar niet identiek) aan de onderliggende hardware, waar het guest OS zich bewust is van het feit dat het gevirtualiseerd wordt. Deze virtualisatietechniek vereist dat de het guest OS gewijzigd dient te worden om in deze virtuele context te draaien. Deze aanpassing dient echter enkel op kernel niveau te gebeuren, zodat usermode applicaties onaangeroerd blij- 8

21 Hoofdstuk 2. x86 Virtualisatietechnieken ven. Paravirtualisatie laat hierdoor toe dat de VMM eenvoudig blijft, als we deze vergelijken tegenover een hypervisor die op Binary Translation steunt. Het, in dit document besproken, Xen maakt gebruik van paravirtualisatie. In hoofdstuk 3 vindt de lezer een uitgebreide uiteenzetting terug over de architectuur van Xen. 2.5 Hardware Assisted Virtualization Eerste generatie Ook hardware producenten zijn begonnen met het produceren van hardware met features om virtualisatie technieken te vereenvoudigen. Vruchten hiervan zijn onder andere Intel Virtualization Technology (Intel VT) en AMD s AMD Virtualization (AMD-V). Hardware Virtualisatie is geen verbeterde versie van BT of paravirtualisatie. Het eerste idee was om het probleem met de x86 stealth instructions op te lossen. Dit betekent dat hardware virtualisatie probeert om alle excepties en geprivilegieerde instructies op te vangen, door het afdwingen van een overgang van de guest naar de VMM, die een VMexit wordt genoemd. Het grote Figuur 2.7: Hardware Assisted Virtualization. voordeel is dat het guest OS werkt op zijn normaal privilege niveau (ring 0), de VMM werd verplaatst naar een nieuwe ring op een nog hoger niveau (ring -1 of Root Mode). System calls gaan niet meer automatisch resulteren in VMM tussenkomsten, zolang het geen kritieke instructies zijn. Hierdoor kan het guest OS kernel services bieden aan de applicaties. Deze vorm van virtualisatie zou de overhead moeten reduceren tot een minimum. Maar desondanks de implementatie in hardware, is voor elke overgang van VM naar de VMM (VMexit) en terug (VMentry) een relatief groot aantal CPU cycles nodig. Afhankelijk van de interne CPU architectuur en het soort van operatie (VMexit, VMentry, VMread,...) kunnen deze acties honderden tot duizenden CPU cycles in beslag nemen. Enkele oplossingen voor dit probleem zijn al uitgewerkt. Zo werd het aantal cycles nodig voor VMM overgangen gereduceerd alsook het aantal VMM events. Deze eerste generatie hardware virtualisatie is in die mate verbetert dat het werd opgenomen in VMware ESX en Xen om op 64bit guest OSs toe te passen. 9

22 Hoofdstuk 2. x86 Virtualisatietechnieken Figuur 2.8: Hardware Assisted Virtualization Tweede generatie: Hardware Assisted Pages (HAP) Bij Binary Translation werd al verduidelijkt dat de MMU gebruik maakt van de TLB om om de mapping van virtuele naar fysieke geheugenadress in op te slaan. Tevens werd kort uitgelegd dat voor virtualisatie een shadow page table nodig is om fysieke geheugen adressen te linken aan virtuele geheugen addressen. Het probleem dat binary translation ervaart met deze shadow page tables willen AMD en Intel gaan oplossen met Hardware Assisted Pages (HAP). De oplossing bestaat eruit om een extra kolom in de TLB te creëren; namelijk de Address Space Identifier (ASID). Hierdoor is er een directe link tussen fysieke en virtuele geheugen adressering. Een bijkomend voordeel Figuur 2.9: Hardware Assisted Pages. Ook wel Nested of Extended Page Tables genoemd. is dat een VM de TLB inhoud van een andere VM niet wist, op voorwaarde dat de TLB groot genoeg is natuurlijk. Volgens AMD biedt deze technologie 23 % winst. HAP heeft vooral zijn voordelen als er meerdere virtuele CPUs zijn per VM. Hierdoor zijn er meer synchronisaties met de page tables en worden die ook frequenter vernieuwd. Er zijn echter nadelen aan Nested/Extended Page Tables, zo is het opzoeken van een fysiek adres veel complexer geworden. Telkens er iets moet opgezocht worden in de TLB moet er gezocht worden in zowel guest mapping als VMM mapping. 10

23 Hoofdstuk 2. x86 Virtualisatietechnieken Een tweede nadeel is de standaardisatie. De implementaties van AMD (Nested Page Tables) en Intel (Extended Page tables) zijn niet onderling compatibel. Dit betekent dat softwareontwikkelaars aparte modules moeten ontwikkelen voor de producten van beide fabrikanten. Dit is weer extra code die moet worden opgenomen in de softwarepakketten. 2.6 Full Virtualization Bij deze vorm van virtualisatie heeft het guest OS een volledig virtueel platform: virtuele BIOS, virtuele hardware en virtueel geheugen beheer. Op deze manier is het guest OS zich er niet van bewust dat het in een gevirtualiseerd omgeving draait en zijn er geen extra aanpassingen nodig om de aangeleverde hardware te kunnen gebruiken. Deze vorm van virtualisatie heeft het grote voordeel dat de VM volledig ontkoppeld is van de onderliggende hardware. VMware claimt gebruik te maken van full virtualization door middel van binary translation. Dit is grotendeels juist, echter na installatie van de VMware tools wordt bijvoorbeeld gebruik gemaakt van de geparavirtualiseerde vmxnet netwerkadapter. 11

24 Hoofdstuk 3 Xen Dit hoofdstuk is een uitbreiding op de thesis van S. Verslycken [15], onze voorganger in het Sizing Servers Lab, die het eerste onderzoek naar Xen virtualisatie voor Sizing Servers deed. Verdere informatie komt uit de boeken van Williams & Garcia [17] en von Hagen [16]. De Xen architectuur wordt kort toegelicht in Xen Architecture Overview [18]. Voor een diepgaande uiteenzetting van de Xen VMM verwijzen we de lezer graag door naar Xen and the Art of Virtualization [7] en het boek dat geschreven werd door Chisnall [9]. Figuur 3.1: Het logo van Xen. 3.1 Omschrijving Xen is een open source Virtual Machine Monitor (VMM) die oorspronkelijk ontwikkeld werd voor de Intel IA32 (x86 en x86-64) hardware architectuur. Tegenwoordig is er ook support voor de Intel IA64 Itanium, alsook de IBM PowerPC. Xen werd ontwikkeld met als doel de huidige hypervisor gebaseerde virtualisatie oplossingen te overtreffen in prestaties. De grootste belofte, die steeds maar weer naar boven komt, is dat deze VMM een near-native performantie kan aanbieden voor VMs. Men tracht dit te bewerkstelligen door te steunen op paravirtualisatie (zie 2.4 en 3.3.1). Het Xen project is vrij innovatief en het ontwikkelingsprocess gaat in sneltreinvaart vooruit. Doordat er nauw wordt samengewerkt met partners, zoals bijvoorbeeld Intel en AMD, kan men als één van de eersten nieuwe technologieën implementeren. Eén van de nieuwste hardware technieken die Xen al ondersteund is bijvoorbeeld 12

25 Hoofdstuk 3. Xen HAP (sectie 2.5.2), dewelke momenteel geïntegreerd is in de nieuwste Opteron (codename Barcelona ) processoren van AMD. Xen is ontstaan als academisch onderzoeksproject aan de University of Cambridge in 2003 onder leiding van Ian Pratt. Men zag het commerciële potentieel in van dit project met als gevolg de oprichting van XenSource 1 in Dit bedrijf werd opgericht door het originele team dat Xen ontwikkelde, waaronder Ian Pratt en Moshe Bar, en heeft vestigingen in Cambridge (UK), Palo Alto (CA, USA) en Redmond (WA, USA). Dit team is nog steeds verantwoordelijk voor het grootste gedeelte van de ontwikkeling van dit virtualisatieplatform, in samenwerking met partners als Intel, AMD, Novell en Redhat. De broncode is gelicenseerd onder de GNU General Public Licence (GNU GPL) en is ter download beschikbaar op Xen.org. In oktober 2007 werd XenSource overgenomen door Citrix 2, welke vooral gekend is in de desktop-virtualisatie markt. Hoezeer XenSource s overname door Citrix de toekomst van Xen zal beïnvloeden is nog onduidelijk. Er is echter al een samenwerking opgezet tussen Citrix en Microsoft, voor het ontwikkelen van een compatibiliteitslaag tussen de producten van beide fabrikanten, respectievelijk Xen en Hyper-V 3. Zo zal het mogelijk zijn om Windows Server 2008 geparavirtualiseerd boven de Xen VMM te draaien. Doordat Xen Open Source Software (OSS) is, gelicenseerd onder de GNU General Public Licence (GNU GPL) versie 2, kan elke softwareproducent de technologie implementeren, zolang deze implementatie ook voldoet aan de eisen van de GNU GPLv2 licentie. Grote spelers op de commerciële open source markt, zoals Novell en Redhat, waren er al vroeg bij om de Xen technologie te implementeren en hebben ook grote bijdragen terug geleverd aan de Xen codebase. 3.2 Terminologie Xen gebruikt een ietwat afwijkende terminologie. Hierna volgt een overzicht van de gebruikte termen, zodoende verwarring te vermijden tijdens het verder verloop van dit document. Domain Een synoniem voor Virtual Machine (VM). Privileged Domain (Dom0) Het domain van waaruit Xen beheerd wordt. Dit is de VM waar de xend daemon draait en de native device drivers (zie 3.3.6) aanwezig zijn. Het systeem is gelimiteerd tot één Privileged Domain (Dom0). Unprivileged Domain (DomU) De reguliere domains, zonder speciale rechten

26 Hoofdstuk 3. Xen Driver Domain DomU met speciale privileges om bepaalde hardware rechtstreeks aan te spreken. Paravirtual Machine (PVM) Een geparavirtualiseerd Unprivileged Domain (DomU). Hardware Virtual Machine (HVM) Een hardware gevirtualiseerd DomU. Dit is een domain dat in full virtualization mode draait, gebruikmakend van de hardware virtualisatie extensies die de nieuwe Intel en AMD processoren bieden. Men vindt meer informatie over dit type domain terug in sectie Hypercall Een signaal dat een domain kan uitsturen om de hypervisor ervan op de hoogte te brengen dat het een geprivilegieerde taak wil uitvoeren. Native device driver Traditionele I/O driver waarmee de fysieke hardware devices worden aangestuurd. 3.3 Architectuur Xen paravirtualization Xen gaat uit van het principe van de paravirtualisatie; de VMM gaat er namelijk van uit dat de gevirtualiseerde kernel zich ervan bewust is dat deze geen exclusieve toegang heeft tot de hardware. Zodoende dient Xen geen onnodige CPU cycles te verliezen aan de vertaalslag van instructies voor het afschermen van de individuele VMs; wat het geval is bij binary translation, beschreven in sectie 2.3. Een domain krijgt geen speciale hardware voorgespiegeld (emulatie), maar heeft de beschikking over de fysieke hardware. Deze VM heeft echter geen directe toegang tot de hardware, maar dient via de Xen Application Programming Interface (API) met de hypervisor te communiceren. Dit betekent dat een guest systeem speciaal aangepast dient te worden voor gebruik in een geparavirtualiseerde Xen omgeving. Gelukkig beperkt dit zich tot de kernel van het guest systeem, zodoende dat de applicaties die in user-mode draaien onaangeroerd blijven. Sinds versie van de Linus Linux tree Vanilla zijn deze patches standaard in de Linux kernel opgenomen. Het is sinds versie 3 van Xen ook mogelijk om onaangepaste guest systemen als VM te draaien: de zogenaamde Hardware Virtual Machine (HVM). Hier gaan de voordelen van paravirtualisatie echter verloren; deze machines dienen namelijk in full virtualization mode te werken. Deze virtualisatie methode wordt in Xen verwezenlijkt door gebruik te maken van hardware extenties zoals Intel Virtualization Technology (Intel VT) en AMD Virtualization (AMD-V). In het artikel van J. De Gelas [10] wordt er uitgebreid op hardware assisted virtualization ingegaan. We gaan er hier niet verder op in. 14

27 Hoofdstuk 3. Xen Figuur 3.2: Overzicht van de Xen architectuur De hypervisor en het Privileged Domain Hypervisor Het centrale onderdeel van de Xen technologie is diens VMM. Deze hypervisor, gebaseerd op een kleine, autonome Linux kernel, draait rechtstreeks bovenop de fysieke hardware en onder de VMs waar ze de resource scheduling en geheugenpartitionering verzorgt. Ze is verantwoordelijk voor de abstractie van de onderliggende hardware, en ze zorgt voor isolatie van de verschillende VMs. Om deze taken zo efficiënt mogelijk te bewerkstelligen, en omdat ze niet bekend is met de I/O hardware in het systeem, werkt de hypervisor nauw samen met het Dom0. De Xen hypervisor is opgebouwd uit enkele modules (fig. 3.2) met elk een gespecialiseerde taak: Control Interface Dit onderdeel van de hypervisor staat in voor het verdelen van resources onder de verschillende domains. Enkel Dom0 heeft exclusieve controle over dit onderdeel. Via deze interface verloopt de communicatie tussen de VMM en Dom0. Safe Hardware Interface Deze interface wordt aangeroepen door een native device driver binnen Dom0 of een driver domain, indien deze de fysieke hardware wil aanspreken. Event Channel Via dit onderdeel verloopt de communicatie tussen de verschillende domains. Een domain stuurt via dit kanaal een event, een hypercall genaamd, naar het 15

28 Hoofdstuk 3. Xen Dom0 en de VMM indien deze een geprivilegieerde taak wil uitvoeren. Hypercalls worden besproken in sectie Virtual CPU (VCPU) De VCPU verzorgt de virtualisatie van de fysieke processoren. Het is mogelijk om meer Virtual CPUs (VCPUs) toe te wijzen aan een domain dan er fysiek in de machine aanwezig zijn. Vanuit performantie oogpunt wordt dit echter afgeraden. Virtual MMU (VMMU) Deze zorgt voor het virtueel geheugenbeheer van de domains. Met andere woorden, de virtuele MMU verzorgt de afscherming van de verschillende page tables per domain. De taken en werking van de Virtual MMU (VMMU) wordt in sectie verder toegelicht. Domain0 De Xen VMM werkt niet alleen, maar wordt geassisteerd door Dom0 (fig. 3.2, VM0). Dit domain bevat het OS van waaruit het het beheer van de hypervisor en de DomUs gebeurt; de Domain Management and Control module (fig. 3.3, DM&C). Dit beheer wordt verwezenlijkt via een service die in dit domain draait; namelijk de xend daemon. Dom0 bevat ook alle native device drivers en een back-end interface om de fysieke I/O hardware aan te sturen. DomUs maken hypercalls vanuit hun front-end drivers, langs het event channel, naar de back-end in Dom0. Deze stuurt op zijn beurt de hardware aan, gebruik makende van de VMM s safe hardware interface. In sectie vindt men meer informatie terug over dit driver model. In dit domain draait ook de xenstore daemon, welke informatie verzamelt over de toestand van de hypervisor en de VMs. Figuur 3.3: Basisorganisatie van de Xen componenten. 16

29 Hoofdstuk 3. Xen CPU-tijd en scheduling CPU-tijd Een goed tijdsbesef is van groot belang voor de werking van een kernel; het process scheduling systeem hangt hier immers van af. Een OS dat zonder virtualisatie op de hardware draait zal elk process een bepaalde hoeveelheid CPU-tijd, CPU-cycles, toekennen. Als een OS gevirtualiseerd wordt, kunnen er echter problemen optreden, daar een VM (of domain) zelf een process is binnen het hypervisor systeem. De VM krijgt zelf slechts een deel van de totaal beschikbare fysieke CPU-tijd, aangezien deze gedeeld dient te worden met andere virtuele instanties. Een guest systeem dient zich dus bewust te zijn van zowel werkelijke tijd, de wall clock, en z n eigen domain virtual time. Xen houdt verschillende tijdssystemen bij, welke gebruikt worden voor CPU scheduling. Deze zijn: Cycle counter time Deze zorgt voor een precieze tijdsreferentie, dewelke wordt gebruikt voor het accuraat afleiden van de andere tijdsreferenties. Op Symmetric Multi Processing (SMP) systemen wordt er verondersteld dat de cycle counter time gesynchroniseerd wordt tussen de processoren. System time Dit is een 64-bit teller dewelke het aantal nanoseconden bijhoudt dat er verstreken is na het opstarten van het systeem. Wall clock time Dit is de reële systeemtijd, uitgedrukt in microseconden sinds 1 januari 1970 ; de zogenaamde Unix time 4. De wall clock time kan accuraat gehouden worden door te synchroniseren met een Network Time Protocol (NTP) server. Domain virtual time Deze teller verloopt aan hetzelfde tempo als de system time, maar enkel als het domain wordt gescheduled. Op deze manier wordt het aandeel CPU-tijd dat een domain krijgt toegewezen, aangeduid door het tempo waarin zijn domain virtual time toeneemt. De Xen VMM exporteert de system time en de wall clock time via shared page tables (zie 3.3.5) naar de domains. De hypervisor stuurt elke tien milliseconden een timer event naar het guest systeem dat wordt uitgevoerd. Wanneer een domain gescheduled wordt, ontvangt deze ook een timer event, opdat deze de tijd die verlopen is terwijl het inactief is geweest, kan aanpassen. Ten slotte kan een guest OS ook een aanvraag doen naar de VMM om op een gespecifiëerde system time zo n timer event te sturen

30 Hoofdstuk 3. Xen CPU schedulers Xen biedt een uniforme API van CPU schedulers, zodat het mogelijk is om uit een aantal schedulers te kiezen, of er zelfs een toe te voegen. Men kan een scheduler specifiëren via de sched= Xen boot-parameter. Er zijn standaard al een aantal CPU schedulers geïmplementeerd in een Xen systeem. Een vergelijkende beschrijving van deze schedulers vindt men terug in de paper van Cherkasova et al. [8]. Credit Deze scheduler is een proportional fair share CPU-scheduler, vanaf grond af opgebouwd voor gebruik op SMP systemen. Deze scheduler duidt een domain aan met een gewicht een optioneel maximum. Het gewicht van een domain bepaalt hoeveel recht deze heeft op CPU-tijd, zonder het maximum, uitgedrukt in een percentage, te overschreiden. Dit is de standaard gebruikte CPU-scheduler. Borrowed Virtual Time (BVT) is ook een proportional fair share CPU-scheduler, gebaseerd op het concept van virtual time, die de VM met de laagste domain virtual time eerst uitvoert. Bovendien biedt BVT low-latency ondersteunding voor VMs die realtime applicaties draaien, doordat deze domains de mogelijkheid geeft om hun virtual time terug te spoelen om zo voorang te krijgen bij het schedulen van CPU-tijd. Simple Earliest Deadline First (SEDF) Deze scheduler biedt een gewogen CPU aandeel aan aan een domain op een intuïtieve manier, gebruik makend van realtime-algoritmen. Hierover is meer documentatie te vinden in de Xen distributie Hypercalls Vanwege de paravirtualisatie vereist Xen dat de guest kernel hiervoor is aangepast. Dit bood de ontwikkelaars van Xen de kans om het systeem van calls en interupts te vereenvoudigen. Een kernel die in full virtualization mode draait, gaat er immers van uit dat deze op fysieke hardware draait en zal, vrij veel calls naar de hardware maken. Bepaalde evenementen, zoals bijvoorbeeld een context switch, zullen een hele reeks achtereenvolgende calls teweeg brengen die telkens dienen geïnterpreteerd en uitgevoerd te worden door de virtualisatielaag. Dit hele systeem is erg omslachtig en kan voor een enorme performantie impact zorgen. In Xen wordt dit aangepakt doordat een guest OS zijn calls naar de hardware dient te maken via efficiënte, Xen-specifieke instructies, de zogenaamde hypercalls, dewelke het traditionele systeem vervangen. Waar traditioneel voor een bepaalde taak, zoals het uitvoeren van een context switch, een groot aantal geprivilegieerde calls gemaakt dient te worden, is het met Xen mogelijk om dit alles te combineren in slechts één hypercall, eventueel aangevuld met parameters, waarna de hypervisor het geheel afhandelt. Zo is er bijvoorbeeld de mmu update() hypercall, dewelke het hele geheugenbeheer, zoals het updaten van de page tables of het 5 Deze documentatie vindt men terug in docs/misc/sedf scheduler mini-howto.txt. 18

31 Hoofdstuk 3. Xen uitvoeren van een TLB flush, voor z n rekening neemt. Dit reduceren van het aantal systeem calls zorgt voor een verminderde virtualisatie overhead. Verder verloopt de communicatie tussen domains onderling, en met de VMM, alsook de verschillende events, via hypercalls. Zo bestaat de aanvraag van een domain naar een timer event (sectie 3.3.3) uit de set timer op() hypercall. Inter-domain communicatie verloopt via de event channel op() hypercall. Voor een overzicht van de beschikbare hypercalls en hun functies verwijzen we de lezer graag door naar de XenSource [5] documentatie Privileges en geheugenbeheer De Virtual Memory Management Unit (VMMU) Xen maakt gebruikt van een geparavirtualiseerde MMU, de Virtual MMU (VMMU), dewelke verantwoordelijk is voor de virtualisatie van het geheugenbeheer. Er wordt gebruik gemaakt van direct-mode memory management of pseudo-physical memory (fig. 3.4); er wordt niet langer een kopie bijgehouden van de actuele page tables in shadow page tables (zie pagina 8), zoals bij binary translation, maar domains mogen rechtstreeks in het fysieke geheugen werken. Een VM krijgt van de hypervisor een deel van het fysiek geheugen, gespecificeerd in de configuratie van het domain met een standaardwaarde en een maximum, toegewezen en mag deze zelf beheren, onder strict toezicht van de VMM. Figuur 3.4: Geheugenbeheer: Xen s pseudo-physical memory versus shadow pages. Wanneer een guest OS gescheduled staat voor een CPU, dan zal de VMM ervoor zorgen dat de page table base verandert en de VMMU enkel het geheugenbereik weergeeft waar het domain recht op heeft. Een domain heeft in principe enkel toegang tot zijn eigen page 19

32 Hoofdstuk 3. Xen tables, maar er is ook een mogelijkheid om bepaalde, gedeelde page tables aan te spreken. De tijdssynchronisatie (zie 3.3.3) steunt op deze shared page tables. Indien een operating system toegang wil tot nested page tables (64-bits werking), dan kan dat enkel read-only. De Xen hypervisor gebruikt zelf maar een klein, vast deel van het fysieke geheugen. Ze zal echter ook de bovenste 64 MiB van elke virtuele address space reserveren. Verder is Xen in staat om met Physical Address Extension (PAE) te werken op 32-bit systemen, zodat het systeem meer dan 4 GiB werkgeheugen kan aanspreken. Privileges In een Xen gebaseerd systeem, draait de VMM in ring 0, waardoor ze volledige toegang heeft tot het fysieke geheugen van het systeem en er delen van kan toewijzen aan de domains. Een guest OS krijgt plaats in een van de minder gepriviligeerde ringen 6. Hoe de indeling precies gebeurt hangt af van de architectuur en het OS. Op een 32-bit (x86) geparavirtualiseerd Linux systeem kan de VMM gebruik maken van memory segmentation om zichzelf af te schermen van de andere processen. De kernel van het guest systeem draait hier in ring 1. De userspace applicaties doen hun werk in ring 3, net zoals in een native situatie. Figuur 3.5: Privilege ring model bij een 64-bit systeem. Op een 64-bit systeem kan Xen echter geen gebruik maken van memory segmentation, waardoor het genoodzaakt is geheugen af te schermen op page-basis. De guest kernel draait hier nu ook in ring 3, zoals de usermode applicaties (fig. 3.5). Weliswaar is dit op basis van strikt gescheiden page tables. Indien een applicatie een system call uitvoert op de guest kernel, dan dient Xen in te grijpen door de page tables aan te passen. Deze context switch tussen ring 0 en ring 3 gebeurt door middel van het syscall/sysret 7 principe

33 Hoofdstuk 3. Xen In beide gevallen is het een guest OS niet toegestaan om een gepriviligeerde taak uit te voeren, en kan het de de gepriviligeerde bits in (E)FLAGS 8 niet aanpassen. Als een OS in een domain zo n taak wil uitvoeren, dient deze een hypercall naar de VMM te sturen Drivermodel Xen maakt gebruik van een gesplitst model met frontend- en backend-drivers. Meer concreet wil dit zeggen dat alle native device drivers, nodig om de fysieke hardware aan te sturen, enkel aanwezig zijn in Dom0, dewelke een backend-interface naar deze drivers aanbiedt. Een DomU bevat een generieke frontend-interface, namelijk de xennet en xenblk drivers, die via hypercalls over het event channel met de driver backend communiceert (fig. 3.6 en 3.7). Er komt hier dus geen emulatie aan te pas; er wordt enkel vereenvoudigd. Figuur 3.6: Domain0 bevat de native en backend drivers, dewelke DomainU aanspreekt via diens frontend-drivers. Wanneer een DomU bijvoorbeeld de netwerkkaart wil aanspreken, dan zal de kernel de xennet driver aanspreken, dewelke de te versturen data in een shared memory page plaatst (zie 3.3.5) en een hypercall verzend. Als de VMM deze actie authoriseert, wordt de instructie die de DomU kernel wil uitvoeren naar de backend van het Dom0 gestuurd. Dom0 laat deze instructie dan uitvoeren door de native device drivers, over de safe hardware interface van de hypervisor. Doordat de communicatie over twee verschillende kanalen verloopt, namelijk het event channel voor de instructies en een shared memory page voor de datatransfer, is het mogelijk om requests samen te bundelen voor een efficiënte toegang tot het hardwareapparaat. Het is mogelijk om een DomU de rechten te geven om rechtstreeks bepaalde hardware apparaten aan te spreken. Dit domain, een driver domain genoemt, dient dan over een native 8 EFLAGS is de 32-bit opvolger van het 16-bit FLAGS status register op de Intel IA32 processor. Verder is er ook het 64-bit RFLAGS register. 21

34 Hoofdstuk 3. Xen Figuur 3.7: Xen driver model. device driver te beschikken, alsook de backend, voor dit apparaat. Dit maakt het mogelijk dat andere DomUs ook via dit driver domain de fysieke hardware kunnen aansturen Virtuele netwerking Alle domains communiceren via een virtuele netwerkbrug xenbr0 die via de interface peth0 binnen het Dom0 verbonden is met de buitenwereld. De peth0 interface is eigenlijk de fysieke eth0 interface, en neemt dan ook diens instellingen over. Het is mogelijk de configuratie van de netwerkbrug in te stellen in de Xen configuratiebestanden, om bijvoorbeeld de brug aan een andre fysieke interface te koppelen, of om meerdere netwerkbruggen aan te maken. Figuur 3.8 geeft een schema weer van dit systeem. Figuur 3.8: Netwerking binnen een Xen systeem. 22

35 Hoofdstuk 3. Xen Hardware Virtual Machines Sinds versie 3.0 van Xen is het mogelijk om onaangepaste OSs te virtualiseren. Hier wordt dan gebruik gemaakt van full virtualization, gebruik makend van de hardware extensies voor virtualisatie van de moderne processoren; Intel VT en AMD-V. Voor deze full virtualization wordt gebruik gemaakt van een speciale Xen versie van de QEMU emulator 9, die de hardwareemulatie voorziet. Met Xen en hoger is het ook mogelijk om gebruik te maken van hardware virtualisatie van de tweede generatie; namelijk Hardware Assisted Pages (HAP), dewelke besproken wordt in sectie Figuur 3.9: Xen full virtualization dmv. QEMU. Zowel Novell als Citrix bieden geparavirtualiseerde I/O drivers aan voor HVMs in hun commerciële producten. Deze drivers berusten op hetzelfde front-end en back-end principe als het standaard Xen model (zie 3.3.6), en bieden een enorme performantieboost. Deze PV I/O drivers verkeren echter nog in BETA fase, en zijn dus nog niet stabiel te noemen

36 Hoofdstuk 4 Praktisch gebruik van Xen 4.1 Inleiding In dit hoofstuk vindt de lezer meer informatie terug over het praktisch gebruik van Xen. Zo wordt er uitgelegd welke de verschillende installatiemogelijkheden zijn, wat de systeemvereisten zijn, en de stappen die men moet ondernemen om een Xen omgeving op te zetten. Vervolgens wordt er beschreven hoe men virtuele machines aanmaakt, beheert en kan monitoren met de Xen Management (xm) tool. Ten slotte is er nog een kleine troubleshooting sectie. 4.2 Installatie Vereisten om Xen te gebruiken Hier volgt een korte lijst met hard- en softwarevereisten voor het draaien van de Xen VMM, het Dom0 en een of meerdere DomUs. Voor een meer uitgebreide lijst verwijzen we de lezer graag door naar het boek van von Hagen [16] (3de hoofdstuk) en de XenSource [6] documentatie. Hardwarevereisten De volgende hardwarecomponenten zijn vereist om een werkende Dom0 host op te zetten met één of meerdere virtuele machines: Processor Een Pentium 4 compatibel systeem met een klokfrequentie van 1, 5 GHz of beter. Xen ondersteunt momenteel systemen met maximaal 32 processoren. Om HVMs te draaien heeft men een processor met Intel VT of AMD-V extensies nodig. Zie [2] voor een lijst van compatibele processoren. Moederbord Als men een processor met Intel VT of AMD-V gebruikt, dient deze optie ook in het BIOS van het moederbord ingeschakeld te zijn. Sommige moederborden onder- 24

37 Hoofdstuk 4. Praktisch gebruik van Xen steunen processoren met virtualisatie extensies, maar kunnen deze niet inschakelen. Zie [1] voor een lijst van compatibele moederborden. Geheugen Er wordt een minimum van 1 à 2 GiB werkgeheugen aangeraden voor degelijke werking. De hoeveelheid gebruikt geheugen is erg afhankelijk van het aantal, het type (bv. non-gui of Graphical User Interface (GUI)) en de grootte van de virtuele machines die op het systeem zullen draaien. Harde schijf Men dient genoeg harde schijfruimte te voorzien voor de virtuele machines; elke DomU heeft namelijk zijn eigen bestandssysteem. Het is ook gebruikelijk om plaats te voorzien voor updates en snapshots van de VMs. Benodigde softwarepakketten De volgende softwarecomponenten zijn minimaal vereist in een Dom0 systeem: Bridge-utils verzorgt het beheer van virtuele netwerken. GRand Unified Bootloader (GRUB) is, op moment van schrijven, de enige bootloader die de Xen VMM kan laden. Iproute of iproute2 zorgt voor de configuratie van de netwerkinterfaces en de routering van ethernet pakketten. Lbsdl (optioneel) is nodig als men een grafische console naar een VM wenst over het Simple DirectMedia Layer (SDL) protocol. Libvncserver (optioneel) is nodig als men een grafische console naar een VM wenst over het Virtual Network Computing (VNC) protocol. Python (versie 2.4 of hoger) is de programmeertaal waarin de xend daemon en de Xen beheerprogramma s zijn ontwikkeld. Pyxml of python-xml wordt gebruikt om de vele extensible Markup Language (XML) configuratiebestanden die Xen gebruikt te parsen. SSL cryptografische bibliotheken (libssl) voor beveiligde communicatie. Udev zorgt ervoor dat hardware nodes dynamisch worden aangemaakt tijdens het opstarten van het Linux systeem. Zlib wordt gebruikt voor datacompressie en -decompressie. 25

38 Hoofdstuk 4. Praktisch gebruik van Xen Installatie van binaire pakketten Xen in SUSE Linux Enterprise Server (Novell) SUSE Linux Enterprise Server (SLES) was de eerste enterprise Linux distributie die Xen officëel ondersteunde, en dit vanaf versie 10 van het besturingssysteem. De installatie van een volledig werkende Xen omgeving in SLES verloopt heel eenvoudig met het beheerprogramma SUSE Yet another Setup Tool (YaST2). Als men in YaST2 onder de kop Virtualization kijkt, dan kan daar de optie Install Hypervisor and Tools teruggevonden worden. Ook het creëren en beheren van virtuele machines is mogelijk met YaST2. Xen in Debian Linux Sinds Debian 4.0 zijn er Xen pakketten beschikbaar in de unstable en experimental software repositories. Deze pakketten kunnen geïnstalleerd worden met de apt-get tool. Softwarepakketten van belang, volgens de Debian Wiki [4], zijn onder andere: xen-linux-system-kernelversie libc6-xen (enkel voor i386 systemen) xen-tools (optioneel) grub Installatie vanaf de broncode Xen is vrije software waardoor de broncode 1 beschikbaar is voor download en gebruik. Hieronder worden de stappen beschreven die men moet ondernemen om Xen vanaf de broncode te installeren. Als voorbeeld gaan we uit van een SLES10 systeem waarop de virtualisatiesoftware wordt geïnstalleerd. Installeren van de nodige softwarepakketten Voor het compileren van de Xen broncode dienen een aantal pakketten, opgesomd in tabel 4.1, op het systeem aanwezig te zijn. De manier van installeren van software hangt sterk af van de gebruikte Linux distributie, maar deze pakketten vindt men meestal terug in de officiële repositories van de distributie. Indien het nodig moest blijken, is het steeds mogelijk om de software te downloaden van de officiële

39 Hoofdstuk 4. Praktisch gebruik van Xen Tabel 4.1: Benodigde software voor het compileren van Xen. GCC v3.4 of hoger GNU Make GNU Binutils zlib-dev python-dev libncurses-dev openssl-dev xorg-x11-dev bridge-utils iproute hotplug of udev website of vindt men ze terug in software databanken zoals RPMSeek 2. In SLES kunnen deze softwarepakketten heel gemakkelijk geïnstalleerd worden via volgend commando: 1 y a s t i gcc make b i n u t i l s z l i b d e v e l python d e v e l ncurses d e v e l c u r l d e v e l o p e n s s l d e v e l xorg x11 d e v e l bridge u t i l s i p r o u t e udev g e t t e x t d e v e l De Xen broncode downloaden en installeren De volgende stap bestaat eruit om de Xen broncode binnen te halen. Hiervoor zijn er twee methodes beschikaar; de eerste zijnde het downloaden van een tarball archief vanaf de Xen.org website, en de andere via het Version Controll System (VCS) Mercurial 3. De voorkeur gaat naar het gebruik van Mercurial 4. Nadat we eventueel Mercurial op het systeem hebben geïnstalleerd, kunnen we de laatste versie van de Xen broncode downloaden. Ook dient de broncode van een Linux kernel met Xen patches binnengehaald te worden. Nadat dit gebeurd is kunnen we het geheel compileren en installeren. 1 hg c l o n e r RELEASE http : / / x e n b i t s. xensource. com/xen 3.2 t e s t i n g. hg hg c l o n e r 406 http : / / x e n b i t s. xensource. com/ linux xen. hg 3 cd xen 3.2 t e s t i n g. hg make world 5 make i n s t a l l Dit zal de Xen VMM, libraries, tools en een paravirtualiseerbare Linux kernel ( ) compileren. Er kan ook geopteerd worden om zelf een Linux kernel te patchen. Indien dit gewenst is, kunnen de kernel patches gecompileerd worde met het make mkpatches commando, om ze vervolgens toe te passen op de broncode van een Vanilla 5 - of een custom-build Linux kernel

40 Hoofdstuk 4. Praktisch gebruik van Xen De meest gangbare distributies bieden ook speciale Xen-gecompileerde kernels aan en vanaf versie van de Vanilla-tree bevat Linux standaard al ondersteuning voor virtualisatie. Vervolgens dient GRUB nog juist ingesteld te worden. We moeten namelijk de gloednieuwe Xen VMM en het Dom0 kunnen booten. Dit wordt verwezenlijkt door een nieuwe optie in het /boot/grub/menu.lst bestand te specifiëren. Het is ook wenselijk om Xen als standaard opstartsysteem in te stellen. Men dient als kernel optie de Xen VMM te specifiëren, de Dom0 kernel wordt met de module optie aangeduid. Concreet betekent dit dat eerst de hypervisor gestart wordt, waarna deze de Dom0 kernel aanroept. 1 t i t l e Xen r o o t ( hd0, 0 ) 3 k e r n e l / boot /xen gz module / boot / vmlinuz xen r o o t=/dev / sda4 ro vga=0x317 5 module / boot / i n i t r d xen In de bootoptie hierboven wordt er ook een Initial RAM Disk als module gespecifiëerd. Dit is een image met een minimaal root bestandssysteem dat tijdens het opstarten in het geheugen wordt geladen en onder andere de essentiële opstartmodules bevat. Deze RAM Disk kan men in SLES aanmaken met het mkinitrd commando. Vervolgens dient men de rc scripts nog aan te passen zodat de xend daemon automatisch met het systeem wordt gestart. In SLES is dit gemakkelijk te verwijzenlijken door gebruik te maken van het YaST2 beheerprogramma. De optie vindt men terug in het System, System Services(Runlevel) menu. Ten slotte kunnen we het systeem opnieuw opstarten. Als alles goed is gegaan wordt men begroet met een werkende Xen omgeving en kan men aan de slag met het creëren van VMs. Indien xend niet kan starten, dient er gecontrolleerd te worden of alle benodigde softwarepakketten aanwezig zijn op het systeem (zie en 4.4.2). 1 \ \/ / / \ / 3 \ // \ \ \ ) / \ / ) / / 5 / /\ \ ( ) ( ) 7 (XEN) Xen v e r s i o n ( r o o s s l a b. l o c a l ) ( gcc v e r s i o n ( p r e r e l e a s e ) ( SUSE Linux ) ) Mon May : 3 6 : 2 1 CEST 2008 (XEN) L a t e s t ChangeSet : F r i Apr : 0 3 : : d2eb5fad Commerciële Xen opties XenSource, dat recent is overgenomen door Citrix 6, biedt zowel vrije als commerciële licenties aan op hun Xen producten. Dit bedrijf werd opgericht door het team van de University

41 Hoofdstuk 4. Praktisch gebruik van Xen of Cambridge, onder leiding van Ian Pratt, dat Xen oorspronkelijk heeft ontwikkeld. Zij zijn dan ook nog steeds verantwoordelijk voor het grootste gedeelte van de ontwikkeling van dit virtualisatieplatform. De broncode blijft gelicenseerd onder de GNU GPL en is ter download beschikbaar op het eerder vernoemde Xen.org. Meer informatie over dit bedrijf en hun producten kan men op de XenSource website 7 terugvinden. Een ander commerciëel bedrijf is Virtual Iron 8. Hun geleverde diensten zijn gebaseerd op de Xen hypervisor. 4.3 Xen beheer met de Xen Manager De standaard tool voor het beheer van een Xen omgeving is de Xen Management tool die aangeroepen wordt met het xm commando. Hiermee is het onder andere mogelijk om VMs aan te maken, af te sluiten, op te slaan, ze te monitoren en een (seriële) console ernaar te openen. Deze tool kan ook geavanceerde zaken zoals het dynamisch toevoegen en/of verwijderen van VCPUs, block- en netwerk apparaten en geheugen. Het commando laat zelfs toe om de gebruikte Xen scheduler te manipuleren. Kortom, de commandolijn gebaseerde Xen Manager kan alle taken op een Xen systeem aan. Figuur 4.1: De interactie met de xend daemon, via het xm commando. In deze sectie zullen we de meest gangbare opties van xm bespreken. Voor een volledige lijst kan er steeds beroep gedaan worden op de man-pagina (man xm) van het commando Algemene xm opties Hier worden algemene xm opties beschreven die niet meteen invloed hebben op het manipuleren van VMs

42 Hoofdstuk 4. Praktisch gebruik van Xen Usage : xm <subcommand> [ a r g s ] 2 Control, l i s t, and manipulate Xen g u e s t i n s t a n c e s. xm dmesg geeft de dmesg meldingen van de Xen VMM weer. [... ] 2 (XEN) Using s c h e d u l e r : SMP C r edit S c h e d u l e r ( c r e d i t ) (XEN) I n i t i a l i z i n g CPU#0 4 (XEN) Detected MHz p r o c e s s o r. (XEN) CPU: L1 I Cache : 64K (64 bytes / l i n e ), D cache 64K (64 bytes / l i n e ) 6 (XEN) CPU: L2 Cache : 512K (64 bytes / l i n e ) (XEN) CPU 0 ( 4 ) > Core 0 8 (XEN) AMD SVM Extension i s enabled f o r cpu 0. [... ] xm help toont een lijst van beschikbare opties met telkens een korte beschrijving waar deze voor staan. xm info geeft info weer over Xen en de Xen host. 1 host : quadbarcelona 1u r e l e a s e : xen 3 [... ] xen major : 3 5 xen minor : 0 x e n e x t r a : xen caps : xen 3.0 x86 64 xen 3.0 x86 32p hvm 3.0 x86 32 hvm 3.0 x86 32p hvm 3.0 x86 64 [... ] xm list [domain] Als dit commando wordt gebruikt zonder een domain te specifiëren, wordt er een lijst getoond van alle domains die geregistreerd staan bij het Xen Domain Management. Als men wel een domain specifiëert, wordt enkel de status van die VM weergegeven. In combinatie met de --long optie wordt de gehele configuratie van het domain in Simple XML Persistence (SXP) formaat op het scherm afgedrukt. Name ID Mem VCPUs S t a t e Time ( s ) 2 Domain r o l t p b xm log drukt de xend log af. xm shell opent een interactieve xm shell zodoende er een hele hoop commando s achter elkaar gegeven kunnnen worden zonder het xm voorvoegsel. 30

43 Hoofdstuk 4. Praktisch gebruik van Xen Creëeren van een DomainU systeem Voor het aanmaken van een DomU dient men een configuratie en een root filesysteem voor de VM aan te maken. Het root filesysteem kan men bekomen door een image van een reeds geïnstalleerd systeem aan te maken of te downloaden. Men kan ook gebruik maken van distributie-specifieke tools zoals Debian s debootstrap en SUSE s Install into directory YaST2 optie. Als het glsdom0 systeem een GUI bevat, dan is het ook mogelijk om een virtueel systeem aan te maken via het virt-manager programma. Een Xen DomU configuratiebestand kan in drie verschillende bestandsformaten gedefiniëerd worden. Om een nieuw DomU systeem aan te maken wordt meestal gebruik gemaakt van een Python configuratiebestand, maar intern werkt Xen voornamelijk met SXP of XML. Zo n Python configuratiebestand ziet er als volgt uit: 1 ostype = s l e s 1 0 name = o l t p memory = 4096 vcpus = 4 5 cpus = 0 3 o n c r a s h = d e s t r o y 7 o n p o w e r o f f = d e s t r o y o n r e b o o t = r e s t a r t 9 l o c a l t i m e = 0 b u i l d e r = l i n u x 11 # k e r n e l = / boot / vmlinuz xen # ramdisk = / boot / i n i t r d xen 13 # r o o t = / dev /xvda2 b o o t l o a d e r = / usr / l i b / xen / boot /domuloader. py 15 b o o t a r g s = entry=xvda2 : / boot / vmlinuz xen, / boot / i n i t r d xen e x t r a = 17 d i s k = [ f i l e : / var / l i b / xen/ images / o l t p / disk0, xvda, w, phy : / dev / s t o r a g e / lun1, xvdb1, w, ] v i f = [ mac=00:16:3 e : 5 3 : 0 f : f6 ] 19 vfb = [ type=sdl ] Vooral de bootloader en bootargs opties zijn hier interessant. Normaal dient de DomU kernel in het Dom0 systeem aanwezig te zijn om te starten (kernel, ramdisk en root opties), dewelke gewoonlijk ook de gebruikte Dom0 kernel is. Met het domuloader.py script is het echter mogelijk de DomU-kernel uit diens root filesysteem te extraheren en deze in een tijdelijke directory in het Dom0 systeem op te slaan, waarna deze vervolgens gestart wordt. Als men de configuratie en een filesysteem bezit, kan de nieuwe VM aangemaakt worden met het xm create commando. De machine zal worden opgestart, en indien gewenst kan er meteen een (virtuele) seriële console naar geopend worden door de -c optie bij het commando te specifiëren. Als de VM wordt afgesloten, zal deze niet meer beschikbaar zijn volgens xm list. Men dient het domain immers te registreren bij de Xen manager door gebruik te maken 31

44 Hoofdstuk 4. Praktisch gebruik van Xen van het xm new commando. Meer configuratie voorbeelden, met een beschrijving van elke optie, vindt men terug in /etc/xen/examples/. De configuratie van een HVM DomU verloopt gelijkaardig met dat van een Paravirtual Machine (PVM) met kleine verschillen in het configuratiebestand. Ook hiervan zijn voorbeelden te vinden op de eerder vernoemde locatie Het beheer van een DomU Eenmaal een domain is aangemaakt, kunnen hier allerlei acties op losgelaten worden. Zo kan men domains starten, afsluiten of migreren naar een ander systeem waar Xen op draait. Bij elk van deze commando s dient het domain gespecifiëerd te worden waarop het van toepassing is. xm console opent een virtuele, seriële console naar het domain. xm reboot zal het domain herstarten. xm shutdown sluit een domain af. xm destroy termineert een domain meteen. xm <pause unpause> Met dit commando kan je het uitvoeren van een domain pauzeren of opnieuw starten. xm <save restore> <file> slaat de toestand van een domain op in een gespecifiëerd bestand om deze later te herstellen. xm <vcpu-set mem-set> biedt de mogelijkheid om het aantal actieve VCPUs of het gebruikte werkgeheugen van een domain in te stellen. xm migrate wordt gebruikt als men een domain van een Xen hostsysteem wil migreren naar een ander Xen systeem Monitoren van DomUs Men kan de domains in de gaten houden met het interactieve xentop (of xm top) commando. Het toont onder andere VCPU gebruik, geheugengebruik en I/O gebruik. 1 # put xentop output here # Het is mogelijk dit commando in batch-modus te gebruiken om voor een bepaalde tijd, met een bepaald interval, de monitorwaarden naar een tekstbestand weg te schrijven. Een voorbeeld van deze batch-mode is xentop -d2 -i150 -b > monitor; dit commando zal gedurende

45 Hoofdstuk 4. Praktisch gebruik van Xen iteraties, met telkens 2 seconden wachttijd, de output in het monitor tekstbestand wegschrijven. Doordat voor elke output regel de naam van het domain wordt afgedrukt, kan men gemakkelijk in het bestand filteren door middel van het grep commando. 4.4 Xen troubleshooting Netwerkproblemen Het kan voorvallen dat bij het draaien van Xen domains het netwerk problemen vertoont. Zo kan men bijvoorbeeld perfect naar andere machines op het netwerk pingen, maar toepassingen die op de applicatielaag van het TCP/IP model werken zullen falen. Dit fenomeen liet zich uiten bij het gebruik van de Intel R 82575EB Gigabit Ethernet Controller 9 in combinatie met de igb 10 netwerkdriver. De oorzaak hiervan ligt in de TCP checksum berekeningen die botst met bepaalde Xen optimalisaties. De oplossing bestaat erin deze TCP checksumming uit te schakelen in de domains. Het uitschakelen van TCP checksumming kan men met het ethtool -K <interface> tx off commando. Deze instelling gaat echter verloren tijdens een herstart van de VM. Het is dus interessant om dit proces te automatiseren. Eén van de mogelijke oplossingen is door het commando in een scriptje te steken dat aangeroepen wordt bij het inschakelen van de netwerkinterface. 1 echo #!/ bin /bash > / e t c / s y s c o n f i g / network / s c r i p t s / txchecksumoff echo e t h t o o l K eth0 tx o f f >> / e t c / s y s c o n f i g / network / s c r i p t s / txchecksumoff 3 l n s / e t c / s y s c o n f i g / network / s c r i p t s / txchecksumoff / e t c / s y s c o v e r s c h i l n f i g / network / i f up. d/15 txchecksumoff De xend daemon wil niet opstarten Indien de xend daemon niet wil starten na een verse Xen installatie en deze een cryptische Python foutmelding weergeeft, is het mogelijk dat de oorzaak ligt bij het ontbreken van bepaalde vereiste softwarepakketten. Een lijst van deze pakketten kan de lezer terugvinden in sectie Onder onze SLES10 SP1 installatie, bijvoorbeeld, dienden we de XML extensies voor Python nog te installeren. 1 y a s t i pyxml python xml &strOSs=All&OSFullName=All%20Operating%20Systems&lang=eng 33

46 Hoofdstuk 5 VMware ESX Figuur 5.1: VMware 5.1 VMware inleiding VMware werd opgericht in 1998 en is uitgegroeid tot de virtualisatie-marktleider. Met meer dan klanten, partners en een omzet van $ 1,3 miljard is VMware één van de grootste groeiende software bedrijven in de wereld. In 1999 kwam hun eerste product op de markt, VMware Workstation. Vooral bedoeld voor desktop virtualisatie werd het al snel populair voor devoloppers om hun software te testen. In 2001 ging VMware van start op de servermarkt met de GSX en ESX sever. Later kwam dan de gratis versie van GSX, VMware Server genaamd. VMware houdt er een hele virtualisatie-filosofie op na. Deze heeft de naam VMware Infrastructure en bestaat uit vele onderdelen waaronder ESX Server en Virtual Center. In dit document beperken we ons tot de VMware ESX Server 3.5. Voor meer info omtrend de producten van VMware of voor toepassingen die hier niet aan bod komen, zie website VMware [3]. 34

47 Hoofdstuk 5. VMware ESX VMware ESX VMware ESX behoort tot de hypervisor familie, een techniek die VMware al jaren beheerst en ook verder heeft verfijnd. De afkorting ESX heeft geen betekenis maar zou vroeger gestaan hebben voor Electric Sky exclamation. VMware ESX installeert men op de fysieke server, ook wel bare metal genoemd, en voegt zo een virtualisatielaag toe tussen hardware en het virtueel OS. VMware ESX zorgt ervoor dat er verschillende VMs tegelijk naast elkaar draaien op één virtuele server. Elke VM is uitgerust met processoren, geheugen, netwerk, opslag, en bios zodat Windows, Linux, Solaris en Netware OSs virtueel kunnen geïnstalleerd worden De console Als VMware ESX wordt geïnstalleerd krijg je automatisch een console die je kan gebruiken voor allerhande configuraties en het beheren van de VMs. Deze console is een aangepaste Red Hat 7.2 distributie zodat deze de VMkernel kan beheren. Om op afstand deze console te gebruiken is SSH default enabled. De console wordt door de VMkernel aanzien als een VM. Probeer dus geen zware toepassingen te gebruiken op de console omdat deze resources van de virtuele machines gebruikt. De /proc/vmware directory bevat informatie over de VMware ESX server virtualisatie laag in de virtuele machines. Hiervoor kan je het cat commando gebruiken om info op te vragen of het echo commando om bepaalde waarden weg te schrijven naar bestanden in het proc filesysteem. Deze informatie is echter ook beschikbaar via de VMware Management interface (VMware Infrastructure Client (VI client)) en het is aangeraden dat je via deze weg informatie opvraagt of wegschrijft. Zie 5.1 voor extra commando s in de console Architectuur van VMware ESX Bare-metal architectuur. VMware ESX plaatst een robuuste virtualisatie laag op de server hardware om zo dicht mogelijk bij de native prestaties te komen en toch betrouwbaar en schaalbaar te zijn VMware ESX 3.5 nieuwigheden -Sata disk drivers support voor ESX Server 3.5 installatie. -Nieuw File systeem : VMFS3 (Virtual Machine File System) Oudere versies van vmware kunnen niet werken met dit filesysteem. -Nieuw virtueel machine formaat : VM3 -Update van de VMware tools. -VI Client installatie files downloadbaar via een webinterface op de VMware ESX server. Deze interface is bereikbaar door te surfen naar het IP adres van de server. 35

48 Hoofdstuk 5. VMware ESX -64GB RAM toegelaten voor virtuele machines. De meest geheugen intensieve workloads in VMs met een geheugen limit zijn nu uitgebreid tot 64GB. -Support voor krachtige fysieke machines. Gebruik maken van zware server systemen tot 32 cpu kernen en 256GB Ram voor consolidatie op grote schaal. -Lokaal SATA opslag support. Maak gebruik van Servers met locale SATA opslag voor een verdere daling van de total cost of ownership en tegelijk het consolideren van workloads. -Support Windows Vista OS -Verbeterde virtuele machine performantie door: Netwerk optimalisatie: reduceren van de CPU overhead geassocieerd met netwerk i/o. Support voor hardware nested page tables : Optimalisatie van memory translition time tussen guest OS en fysiek geheugen. Support voor large memory pages : verbeteren van geheugen toegang en efficientie voor guest OS en de hypervisor. Parvirtualisatie voor Linux OS : vanaf Linux kernel , performanter werken door virtualisatie bewuste Operating systems te gebruiken. 5.2 VMware ESX ontleding VMFS Het Virtual Machine File System is een performant cluster file systeem dat geoptimaliseerd is voor de virtuele server opslag omgeving. Alle onderdelen van de virtuele machine worden automatisch in één map geplaatst. Er wordt ook voor elke nieuwe VM een subdirectory aangemaakt. VMFS zorgt voor de fundamenten van virtualisatie gespreid over verschillende servers waardoor services zoals Vmotion, Distributed Resource Scheduler en VMware High Availability kunnen toegepast worden. Omdat dit een cluster filesysteem is moeten we rekening houden met alignment. Eigenschappen van VMFS - Maximum virtual disk size: 2 TB - Maximum file size:2 TB max - Block size: 1MB to 8MB Onderdelen van een VM Uit welke files bestaat een VM in VMware ESX nu? 36

49 Hoofdstuk 5. VMware ESX 1 l s l / vmfs / volumes / s u n f i r e \ : s t o r a g e 1 /Win2K3 32Oltp/ t o t a l rw r r 1 r o o t r o o t May : 3 4 vmware. l o g rw 1 r o o t r o o t May : 3 4 Win2K3 32Oltp f l a t. vmdk 5 rw 1 r o o t r o o t 8684 May : 3 4 Win2K3 32Oltp. nvram rw 1 r o o t r o o t 406 May : 2 7 Win2K3 32Oltp. vmdk 7 rw 1 r o o t r o o t 0 Apr : 0 2 Win2K3 32Oltp. vmsd rw r r 1 r o o t r o o t 1878 May : 2 6 Win2K3 32Oltp. vmx 9 rw 1 r o o t r o o t 268 May : 0 6 Win2K3 32Oltp. vmxf.log Deze file houdt de logging van de virtuele machine bij. Dit kan handig zijn bij eventuele trouble shooting..nvram Deze file houdt de instellingen van de VM zijn BIOS bij..vmdk Dit is een Disk DescriptorFile, hier worden de instellingen van de virtuele harde schijf bijgehouden.. inhoud: 1 # Disk D e s c r i p t o r F i l e v e r s i o n=1 3 CID=6f a 5 e parentcid= f f f f f f f f 5 createtype= vmfs 7 # Extent d e s c r i p t i o n RW VMFS Win2K3 32Oltp f l a t. vmdk 9 # The Disk Data Base 11 #DDB 13 ddb. t o o l s V e r s i o n = 7299 ddb. adaptertype = l s i l o g i c 15 ddb. geometry. s e c t o r s = 63 ddb. geometry. heads = ddb. geometry. c y l i n d e r s = 1958 ddb. uuid = C a6 9 f 3a ca b8 9d c3 64 5d 9 f be 19 ddb. virtualhwversion = 4 -flat.vmdk Dit is de eigenlijke virtuele harde schijf..vmsd In dit bestand staat informatie en metadata ivm de snapshots..vmx Dit is het hoofd configuratiebestand, de settings van de virtuele machine worden hier bijgehouden. Bij oudere versies van VMware ESX kan dit bestand de extensie.cfg hebben..vmxf Dit is een extra bestand dat wordt gebruikt in een team van verschillende VMs..vswp Swapfile voor de virtuele machine. De bios gebruikt voor de virtuele machines is PhoenixBIOS 4.0 Release 6. 37

50 Hoofdstuk 5. VMware ESX VMware tools Niet vergeten de VMware tools te installeren op uw virtuele machine. Deze tools verbeteren de grafische prestaties van de VMs aanzienlijk door gebruik te maken van de VMware tools SVGA driver. Ook krijg je door het VMware Tools package de mogelijkheid om gebruik te maken van shared folders, en drag and drop operaties. Andere tools in de package zorgen voor tijdsynchronisatie met tussen guest en host, automatisch vastnemen en loslaten van de cursor, copy-paste tussen guest en host, optimalisatie van de muis-snelheid. De installers voor VMware Tools voor Windows, Linux, FreeBSD en NetWare guest operating systems zijn ingebouwd in de VMware Workstation als ISO files. 5.3 Monitoring in VMware ESX VMware Infrastructure Client De eerste manier om esx te monitoren is via de VI client. Indien je de host of één van de VMs aanklikt dan kan je naar het tabblad Performance. Hier zie je realtime grafieken die de prestaties weergeven van bepaalde elementen. Deze kan je selecteren in het keuzevak bovenaan (zie 5.2). Figuur 5.2: Performance in VIC esxtop Met de VMware esxtop tool krijgen we een realtime (elke 5 seconden default) overzicht van de ESX Server worlds. De term world verwijst naar processen die draaien op de VMkernel. Er zijn 3 types van werelden : System Dit zijn de verschillende system services. Deze bevatten één idle world per fysieke CPU die runt als er geen belasting is op die fysieke CPU, helper worlds voor asynchrone taken en driver worlds. 38

51 Hoofdstuk 5. VMware ESX Service Console Dit is de wereld van de service console, die runt altijd op CPU0. Virtual Machine Dit is de wereld voor elke virtuele CPU. (belangrijk bij het troubleshooten) Esxtop laat ons dus toe CPU en geheugen verbruik, Disk en network bandwidth te monitoren. Via redirection kunnen we dan de output doorverwijzen naar een (komma separated) tekstbestand. 1 e s x s e r v e r# esxtop > bestand. t x t voor een volledige comandolijst voor esx verwijs ik u door naar de manual van esxtop. 1 e s x s e r v e r# man esxtop 5.4 Andere VMware toepassingen Zoals eerder vermeld heeft VMware een volledige infrastructuur dus is het wel nodig een korte uiteenzetting te doen over al deze elementen VirtualCenter Agent : De VirtualCenter Agent werkt als een mini-virtualcenter Server en heeft volgende functionalliteit: -Bundelt en dwingt de beslissingen van resource toewijzingen af gemaakt door VirtualCenter en de DRS engine.] -Geeft commandos voor configuratie veranderingen van de host agent door aan de VM.] -Geeft host configuratie commandos door aan de host agent.] -Verzamelt performance statistieken, alarms, error condities van de host agent en zend die door naar de VirtualCenter Server.] Consolidated Backup : Maakt het altijd mogelijk om een backup van een draaiende VM te nemen Update Manager : Zal alle patches en updates voor de virtuele infrastructuur automatisch laten uitvoeren VMware HA : VMware High Availability laat toe om de virtuele machines op een VMware ESX Server automatisch te laten herstellen van een host failure. Als de host uitvalt worden alle virtuele machines onmiddelijk opgestart vanop een andere host in de infrastructuur. (zie 5.3) 39

52 Hoofdstuk 5. VMware ESX Figuur 5.3: VMware HA VMotion : VMotion maakt het mogelijk om virtuele machines over te zetten naar een andere fysieke server en dit allemaal zonder de virtuele machine te hoeven afsluiten.(zie 5.4) Figuur 5.4: VMotion Storage VMotion : Storage VMotion biedt de mogelijkheid om de extra opslag schijven van de virtuele machine te migreren naar een andere fysieke storage array.(zie 5.5) VMware DRS : Het Dynamically Allocate System Resources systeem zorgt ervoor dat de beschikbare resources dynamisch worden toegewezen aan de hand van VMware Distributed Resource Scheduler (DRS). DRS gaat het gebruik van de resources monitoren om zo de beschibare resources op een intelligente wijze toe te wijzen aan de verschillende VMs, dit allemaal gebaseerd op vooraf vastgestelde regels. Wanneer de resources van een VM te klein worden kan een overschot van capaciteit op een andere fysieke server gebruikt worden door live migration aan de hand van VMotion. (zie 5.6) 40

53 Hoofdstuk 5. VMware ESX Figuur 5.5: Storage VMotion. Figuur 5.6: DRS Virtual Center Server : Dit is een centrale management service voor het configureren, aanmaken en het beheren van de virtuele omgevingen. Met virtual center is het mogelijk meerdere VMware ESX hosts samen te brengen en hun fysische resources gecombineerd en efficiënt te gebruiken. Virtualisatie services zoals VMotion, HA, DRS en VCB gebruiken de informatie van de Virtual Center Server om zo een optimaal, efficiënt en high available datacenter te creëren De vier onderdelen van Virtual Center Server zijn: VirtualCenter Management agent op elke VMware ESX host. VMware Infrastructure API bevat interfaces met andere VMware Virtual Center clients alsook met third party oplossingen. Database Interface om data van host configuraties,virtuele machine configuraties, resources, preformance statistieken, events, alarms, permissies van gebruikers en dergelijke op te slaan. Een Active Directory interface om gebruikers toegang te controleren. 41

54 Hoofdstuk 5. VMware ESX 5.5 Maintenance en Standby Modes Je kan de VMware ESX server in maintenance mode en standby mode gaan plaatsen, beide modes hebben vele gelijkenissen. Zo verhinderen beide modes dat er nog virtuele machines werken. Toch hebben beide modes een verschillend doel. De VMware ESX server kan je in één van de gewenste modes plaatsen via de VI client Maintenance Mode Zowel standalone hosts als hosts in een cluster kunnen in maintenance mode geplaatst worden. Deze mode beperkt de activiteiten van VMs zodat deze kunnen uitgeschakeld worden in voorbereiding voor de uitschakeling van de host. Zolang de host in maintenance mode zit laat hij niet toe dat er VMs worden opgestart. Als de server in een cluster zit kan je de optie evacuate powerd-off VMs meegeven, dit zorgt ervoor dat de uitgeschakelde VMs worden gemigreerd naar een andere host.deze mode wordt gebruikt om bijvoorbeeld extra geheugen toe te voegen aan de fysieke server Standby Mode Wanneer een host machine in standby mode staat is die eigenlijk uitgeschakeld. 42

55 Hoofdstuk 5. VMware ESX Tabel 5.1: Speciale console commando s. /proc/vmware Entry chipset config debug filters interrupts log loglevels mem net pci procstats pshare rpcstats sched scsi shrdev stats swap thermmon timers uptime vm vmkperf watchpoints Console commando s Description State of interrupt controllers. Advanced ESX Server parameters available through the VMware Management Interface. Debugging information. Network traffic shaping. Used, together with chipset, to determine the state of interrupt controllers. VMkernel log output. Amount of debug logging. Memory parameters. Configuration and statistics for virtual NICs and bond devices State of PCI adapters in the system. Statistics for the /proc/vmware directory Page sharing statistics for memory resource management. Statistics on remote procedure calls (RPCs). Scheduler statistics on memory and CPU. Information on SCSI devices and mappings between storage controllers and virtual machines. Statistics on shared devices. Counts of various low-level events in ESX Server. Swap statistics. Thermal monitoring information for each processor. State of ESX Server internal timed event scheduler. ESX Server uptime. Statistic for individual virtual machines by VMID. Statistics on ESX Server performance. Statistics for debugging. 43

56 Hoofdstuk 6 Praktisch gebruik van VMware ESX 6.1 VMware ESX 3.5 installatie De installatie van VMware ESX 3.5 is snel en eenvoudig. Starten doet men zoals bij vele installaties door de cd-rom in de server te plaatsen. Bij het booten van de server krijgen we volgend startscherm: Figuur 6.1: Installatie VMware ESX. We kunnen de keuze maken tussen Graphical of Text Mode installatie van VMware ESX 3.5. De Text Modus wordt enkel gebruikt indien de muis of video controller van uw server niet goed werkt, de Graphical Mode wordt aangeraden. Na het testen van de cd-rom op enige gebreken start de installatie wizard van VMware ESX, 44

57 Hoofdstuk 6. Praktisch gebruik van VMware ESX hier worden enkele configuraties gevraagd zoals keyboard en muis instellingen.om te kunnen installeren moeten we de licentie overeenkomst aanvaarden.er wordt gekozen voor de default partitionering. Vervolgens krijgen we een overzicht van de partitionering. Figuur 6.2: Partitionering VMware ESX. Deze lay-out wordt standaard genomen en zullen we dus niet wijzigen,op het volgende scherm is de optie Edit default bootloader configuration vereist. Zo zal VMware ESX ervoor zorgen dat er een (grub) bootloader op de machine komt. Hierna kan de netwerk configuratie gewijzigd worden. Het voorlaatste scherm laat ons toe om de tijdzone te gaan instellen. Als laatste scherm krijgen we nog een overzicht van de gekozen installatie, klik hier op next en dan wordt VMware ESX op de server geïnstalleerd. Eens de installatie is afgelopen moet er nog eenmaal op finish geklikt worden. Hierna wordt de server herstart in VMware ESX. Figuur 6.3: VMware ESX startscherm. 45

58 Hoofdstuk 6. Praktisch gebruik van VMware ESX 6.2 Aligneren Track alignment van de VMFS partities zorgt voor een verbetering van I/O performantie (lagere latency an betere throughput). De best practice,aangeraden door VMware, is het aanmaken van partities via VI client. Dit zal automatisch resulteren in 64KB-gealigneerde partitie tabel. 1 f d i s k / dev / sdc n ( nieuwe p a r t i t i e ), p ( primary ), 1 ( p a r t i t i e #1), 2 xenter ( d e f a u l t s ), x ( e x p e r t mode ), 3 b ( s t a r t b l o k k e n s p e c i f i r e n ), 1 ( p a r t i t i e #1), 128 ( a l i g n e r e n ), r ( normale mode ), t ( p a r t i t i e type ), 1 ( p a r t i t i e #1), fb (= vmfs volume ), w ( opslaan en f d i s k a f s l u i t e n ) Nu zien we dat in de folder /vmfs/devices/disks/vmhbaxxx er een vmhbax:x:x:1 bijgekomen is, dit is de nieuwe partitie die we nog moeten formateren om in te kunnen zetten. Dit kan met de vmkfstools utility: v m k f s t o o l s C vmfs3 b 1m S mijnlun / vmfs / d e v i c e s / d i s k s /vmhba1 : 1 : 0 : 1 -C is verplicht en is het type filesysteem, -b is optioneel en is de blokgrootte (1 m, 2 m, 4 m & 8 m mogelijk), -S is het optionele label. 6.3 VMware Infrastructure Client (VIC) De VI client is de tool om uw virtuele machines te beheren, instellingen te veranderen, en storage toe te voegen aan de fysieke server. Deze handige tool kan men afhalen door gewoon te surfen naar het IP adres van de VMware ESX server Overzicht van de host Algemeen Hiervoor selecteren we de host in het rechterveld, deze wordt aangeduid aan de hand van de computernaam van de fysieke server. Figuur 6.4: Host overzicht in VIC. 46

59 Hoofdstuk 6. Praktisch gebruik van VMware ESX Getting Started : Hier staat een korte uitleg wat een host is en kan er wat extra uitleg over de VMware Infrastructure worden opgevraagd. Ook kan men hier een VM aanmaken of importeren. Summary : Geeft u een overzicht over de fysieke server, merk, model, aantal processoren, type processoren, gebruik van de machine en hoeveel opslag er is. Hier kan men de fysieke server ook afleggen, herstarten, in Maintenance Mode gaan, een resource pool toevoegen of een nieuwe virtuele machine aanmaken. Virtual Machines : Hier is er een overzicht van de VMs met hun status en verbruik. Men kan de kolommen naar wens aanvullen met extra data of een lijst van die data exporteren naar een bepaald formaat (.html,.csv,.xml,.xls) Resource Allocation : Hier krijgt men een overzicht welke VM bepaalde resources gebruikt. Ook worden bovenaan de totalen weergegeven. Performance : Deze pagina geeft u realtime grafieken van prestaties, men kan deze prestaties opslaan als.jpg maar nog handiger is report performance (zie monitorring). De grafiek kan losgekoppeld en handmatig herladen worden. Configuration : Op deze pagina kunt u verschillende hardware settings bekijken en instellen. Een in mijn ogen belangrijke instelling is bijvoorbeeld Virtual Machine Startup/Shutdown, ga hier naar properties en u hebt de mogelijkheid de virtuele machines te laten opstarten met esx. Dit kan handig zijn na bijvoorbeeld stroompanne, eens de VMware ESX server is gestart starten de virtuele machines automatisch op. firewallsettings kunnen hier worden aangepast. Users & Groups : Hier krijgt men een overzicht van de gebruikers en de groepen het is natuurlijk mogelijk om hier extra gebruikers en groepen toe te voegen. Events : Hier krijgt men een overzicht van alle events die hebben plaatsgevonden op de VMware ESX Server. Permissions : Hier kan men de persmissies van bepaalde gebruikers instellen de keuzes zijn read only, Administrator, no access. 6.4 Virtual Machine (VM) U krijgt deze tabs ook als men een VMaanklikt links in het overzicht. De meeste tabs geven hetzelfde terug als bij de host maar dan over de geselecteerde virtuele machine, er zitten echter twee nieuwigheden bij. Ook 47

60 Hoofdstuk 6. Praktisch gebruik van VMware ESX Figuur 6.5: VM overzicht in VIC. Getting Started : Hier kan men de VM gaan starten of de settings ervan aanpassen, ook is er een korte uitleg over VMs. Console : Hier kan men remote inloggen op uw virtuele machine, hier merkt men ook de voordelen als de VMware tools hebt geïnstalleerd. Dit venster kan losgekoppeld worden door rechts te klikken op de virtuele machine en open console te kiezen Toolbar Deze handige toolbar bovenaan laat u toe verschillende toepassingen, commando s te lanceren. Terug is er een verschillende layout voor de fysieke server of een virtuele server. De functionaliteit wanneer de fysieke server geselecteerd wordt is eerder beperkt, men kan een nieuwe VM aanmaken of een resource pool creëren. Bij de virtuele machine krijgt men echter de volgende toolbar te zien: Figuur 6.6: Toolbar in VIC. De twee blauwe pijlen zijn volgende of vorige. De rode vierkant sluit de virtuele machine af, vergelijkbaar met het uittrekken van de stroom. De pauze knop staat voor suspend. In de suspend mode wordt de huidige staat van de virtuele machine opgeslaan alvorens die uit te schakelen zo is het mogelijk, als de VM terug wordt opgestart, om verder werken. Met de groene play knop schakelt een VM aan. De groene en rode pijl herstarten een VM De belangrijkste knoppen zijn echter connect floppy en connect cd/dvd hiermee is het mogelijk een iso,vanaf de pc waar VI client draait, mounten in de VM De knoppen hiernaa dienen om snapshots te nemen, terug te keren naar een bepaald snapshot of de snapshots beheren. Met de laatste knop opent één console naar de machine. 48

61 Hoofdstuk 6. Praktisch gebruik van VMware ESX Nieuwe Machine aanmaken Om een nieuwe virtuele machine aan te maken gebruiken we,in dit voorbeeld, VI client. we selecteren de fysieke machine en dan via rechtsklik, file/new/virual machine of de sneltoets ctrl+n om de New Virtual Machine Wizard te starten. De volgende manieren om de nieuwe machine te configureren kunnen gekozen worden: Typical Name and Location De naam van de nieuwe virtuele machine. Datastore Hier kan men kiezen waar de virtuele machine wordt opgeslaan. Guest OS Welk besturingssysteem komt op de viruele machine? Microsoft,Linux,Novell Netware, Solaris, Other. Elke keuze geeft u onderaan een combobox die verschillende versies (bijvoorbeeld Windows Server 2003, 32 of 64bit). CPU s Het aantal VCPUs, minimum 1 en maximum 4, die worden toegewezen aan de virtuele machine. Memory Hoeveelheid ram die de virtuele machine kan/mag gebruiken. Network Aantal virtuele netwerkkaarten. Zet het vinkje Connect at Power On aan, dan wordt de netwerkkaart ingeschakeld bij het opstarten van de VM. Afhankelijk van het gekozen OS is er de keuze uit een van de volgende netwerk adapters: vlance - AMD Lance PCNet32 ethernet adapter De meeste OSs,zowel 32bit 1 als 64bit, bieden support voor de vlance ethernet adapter. Hierdoor kan de vlance virtuele adapter gebruikt worden zonder extra drivers te installeren. e Intel e1000 ethernet adapter De vlance adapter werd vervangen door de e1000. De enige adapter die support heeft in Windows Vista 32bit, wordt gebruikt voor alle 64bit guest OSs. De e1000 driver zit ook ingebakken in de meeste OSs en voorziet hierdoor een snel werkende netwerk connectie en betere performantie dan de vlance adapter. vmxnet - VMware high speed virtual ethernet adapter Vmxnet, een geparavirtualiseerde adapter gebruikt voor hoge I/O performantie, werd ondersteund door de meeste 32bit guest OSs. Het is wel vereist de VMware tools te installeren om toegang te hebben tot de vmxnet driver. Zonder de VMware tools werkt deze adapter zoals een vlance adapter. ESX Server 3.5 heeft nu een enhanced-vmxnet adapter aan boord voor de meeste OSs. Voor deze adapter is er support voor de 64bit OSs en voegt extra features toe, bijvoorbeeld TCP 1 Bij 32bit systemen wordt deze adapter afgebeeld als flexible adapter. 49

62 Hoofdstuk 6. Praktisch gebruik van VMware ESX Virual Disk Capacity: Hoe groot moet de virtuele harde schijf zijn die wordt toegewezen aan deze nieuwe virtuele machine? Ready to Complete New Virtual Machine: Hier staat een overzicht van alle gekozen Custom instellingen en is het mogelijk nog eens extra opties gaan aanpassen door onderaan Edit the virtual machin settings before submitting aan te vinken. Name and Location: Zie Typical. Datastore: Zie Typical. Guest Operating System: Zie Typical. CPU s: Zie Typical. Memory: Zie Typical. Network: Zie Typical. I/O Adapters: Er zijn twee soorten adapters SCSI en IDE. Voor IDE wordt er altijd gekozen voor de ATAPI driver. Verder kan men kiezen welke soort van SCSI Adapter, er is de keuze tussen LSI logic of Buslogic. Default gebruiken virtuele machines de BusLogic adapter gebruikt.uitzonderingen zijn Windows Server 2003,Red Hat Enterprise Linux 3 en Netware die default de LSI logic adapter gebruiken. Indien men de LSI logic adapter wenst te gebruiken op een andere virtuele machine (bijvoorbeeld Windows XP of 2000) dan moet de LSI20320 SCSI adapter driver gedownload worden van op de site van LSI 2. Belangrijk Linux distributies met een kernel vanaf bieden support voor de LSI Logic adapter. Hier moet dan ook de driver gedownload worden bij LSI. Select a Disk: Hier is het mogelijk een nieuwe virtuele harde schijf aanmaken, een bestaande gebruiken of gewoon geen hard disk aanmaken. Disk Capacity: Zie Typical. Advanced Options: Disk mode : Normal of Independent: De default, Normal mode omvat de huidige staat van de disk in elke snaphot die genomen wordt.als men niet wenst dat de data op de disk wordt meengenomen in de snaphot dan kan Independent aangevinkt worden. Wanneer voor de optie Independent gekozen

63 Hoofdstuk 6. Praktisch gebruik van VMware ESX wordt is er de mogelijkheid de mogelijkheid om Persistent of Nonpersistent te kiezen. De eerste optie zorgt ervoor dat alle data onmiddelijk en permanent naar de disk wordt geschreven, de tweede optie doet dat niet ook al wordt de machine uitgeschakeld. Ready to Complete New Virtual Machine: Zie Typical 6.5 Installatie VMware Tools Windows 2003 Server Hier volstaat om in de VI client uw Windows VM, die moet geboot zijn, rechts aan te klikken en kies Install VMware Tools. Log als administrator in op de VM en als autorun enabled is op die machine wordt er gevraagd of de installatie wizard gestart mag worden, klik yes. Op Windows 2003 Server wordt de SVGA driver geinstalleerd en zal de VM automatisch herstarten Sles10 VMware tools installeren op een linux client doen we het best via de command line. Natuurlijk moet de machine eerst aangezet worden, eens volledig opgestark klik rechts op de machine in de VI client en kies Install VMware Tools. Vervolgens werken we via de console, om de commandline 3 van de guest te gebruiken, de rest van de installatie af. 1 Eerst moeten we de k e r n e l s o u r c e i n s t a l l e r e n : y a s t i gcc k e r n e l s o u r c e 3 De cd rom d r i v e moet gemount worden : 5 mount / dev /cdrom /mnt/cdrom 7 De t a r met f i l e s voor vmware t o o l s moeten we uitpakken : t a r zxpf /mnt/cdrom/vmwaretools <xxxx >. t a r. gz 9 De cd rom d r i v e unmounten : 11 umount / dev /cdrom 13 Ga naar de j u i s t e map : cd vmware t o o l s d i s t r i b 15 S t a r t de \vmw Tools i n s t a l l e r : 17. / vmware i n s t a l l. p l 19 Hier moeten e r e n k e l e vragen beantwoord worden, om d e f a u l t i n s t e l l i n g e n t e a c c e p t e r e n h o e f t men e n k e l Enter t e drukken. 3 Voor deze configuraties zijn root rechten vereist. 51

64 Hoofdstuk 6. Praktisch gebruik van VMware ESX 6.6 Settings van de Virtuele machines De settings van een virtuele machine kunnen aangepast worden door rechts te klikken op de virtuele machine, in de VMware Infrastructure Client, en dan edit settings te selecteren. Let wel: vele opties kunnen niet verandert worden wanneer de VM ingeschakeld is. Hier worden enkele van de meest gebruikte opties besproken Hardware Figuur 6.7: VMware virtual machine options. Memory: de grote van de virtuele ram. CPUs: het aantal virtuele CPU s. Floppy Drive1: Device Status: Het vinkje Connect at power on is beschikbaar wanneer kiezen voor een floppy image aan te maken of een bestaande floppy image te gebruiken. Dit zal image als floppy disk mounten bij het opstarten van de VM. Device Type: Client Device : dit is de floppy drive op de pc waarop de VI client runt. Host Device : dit is de floppy drive op de fysieke server waarop VMware ESX staat. Use existing floppy image in datastore : dit is een iso file die is opgeslaan op de VMware ESX server en die gemount wordt als floppy drive. Create new floppy image in datastore : hier is er de mogelijkheid een floppy image te gaan creëren en op te slaan op de VMware ESX server. 52

65 Hoofdstuk 6. Praktisch gebruik van VMware ESX CD/DVD Drive1: Device Status: Het vinkje Connect at power on is beschikbaar wanneer kiezen voor het gebruik van Host Device of Datastore ISO file. Wat het doet is de image als floppy disk mounten bij het opstarten van de VM. Device Type : -Client Device: dit is de cd-rom drive op de pc waarop de VI clientrunt. -Host Device: dit is de cd-rom drive op de fysieke server waarop VMware ESX staat. -Datastore ISO file: hier kan er een iso file van op de datastore gemount en gebruikt worden als cd-rom. Mode : Deze settings kunnen enkel aangepast worden als er voor Client Device wordt gekozen. Passtrough Integrated Drive Electronics (IDE) : dit geeft ons de mogelijkheid om de cd-rom drive te reserveren enkel voor deze VM. Emulate IDE : hiermee wordt de IDE ADD : met deze knop kan er extra virtuele hardware toevoegt worden Options Hier kunnen we verschillende algemene opties van de VM overlopen en instellen. Deze instellingen worden echter zelden gebruikt. Figuur 6.8: VMware virtual machine options Resources De belangrijkste setting hier vindt men bij Advanced CPU. Hier is het mogelijk de affinity instellen van processoren, dit betekent dat de VM enkel de aangevinkte processoren zal 53

66 Hoofdstuk 6. Praktisch gebruik van VMware ESX gebruiken. Zo kunnen we zorgen voor een totale afscheiding tussen de verschillende VMs. Figuur 6.9: VMware virtual machine options. 6.7 Troubleshooting KERNEL MOUNTING FAILED Na de installatie van VMware ESX Server 3.5 op enkele machines met de onboard nvidia MCP55 sata controller krijgt men bij de eerste herstart : 1 I n v a l i d compressed format ( e r r =2) <6>Freeing i n i t r d memory : 7508K f r e e d VFS Cannot open r o o t d e v i c e UUID=a1f28d49 8a1a 4c c f 9abf 8a38ae768a98 or 0 3 P l e a s e append a c o r r e c t r o o t= boot o p t ion 5 Kernel panic : VFS Unable to mount r o o t f s on 0 0 : Kernel 0 xc s. data 0 xc038c000 s. bss 0 xc Dit komt omdat VMware ESX een xml bestand aanmaakt met een lijst van alle SATA controllers en hun id s.door een bug in VMware ESX 3.5 maakt hij maar 1 controllerpoort aan voor de MCP55. Dit kunnen wij handmatig aanpassen: Start VMware ESX in troubleshoot mode. In de console : Eerst de rechten aanpassen om te kunnen schrijven in het xml bestand #chmod +w / e t c /vmware/ p c i i d / s a t a n v. xml 2 #v i / e t c /vmware/ p c i i d / s a t a n v. xml Onderaan moeten we dit toevoegen. Let erop dat het device met id 037e reeds bestaat en we een device met 037f moeten toevoegen: 54

67 Hoofdstuk 6. Praktisch gebruik van VMware ESX <d e v i c e i d = 037 f > 2 <vmware l a b e l = s c s i > <d r i v e r >sata nv </d r i v e r > 4 </vmware> <name>mcp55 SATA C o n t r o l l e r </name> 6 </device > We testen of deze aanpassing correct is door volgende programma te runnen 1 #e s x c f g p c i i d Nu zien we een aantal loading, writing en replacing lijnen. We moeten de rechten nu opnieuw juist zetten 1 #chmod w / e t c /vmware/ p c i i d / s a t a n v. xml Herstart nu het systeem, het probleem is opgelost Problemen met de AMD Opteron 8356 CPU. Hieronder geef ik een overzicht wat er allemaal nodig was om een bepaalde machine klaar te stomen voor een werkende VMware ESX installatie. De Hardware: Type server : SuperMicro A+ Server 201M-UR+B Chipset/Moederbord : SuperMicro H8DMU+ CPU 2x AMD Opteron 8356 Figuur 6.10: QuadBarcelona CPU. Ram : 8x 1 GB 55

68 Hoofdstuk 6. Praktisch gebruik van VMware ESX Storage : DAS 6x Seagate Cheetah 300 GB 15K5, 1 x Baracuda 250 GB (OS), 1x Barracuda GB (opslag VM) Raid kaart : LSI Logic MegaRAID SAS 8344ELP Het eerste werk was een verse installatie van VMware ESX 3.5 hier dook al echter een probleem op, de installatie die uiteraard via de grafsiche interface zou moeten verlopen versprong naar de text interface. Toen de installatie beëindigd was en de machine wenste te booten in VMware ESX dook het eerste probleem op, plots kreeg ik onderstaande code. 1 0 xbad001e Het gevolg hiervan was dat VMware ESX niet volledig gestart was en er dus niet veel met de machine kon worden aanvangen. Na wat opzoekwerk bleek deze fout hetvolgende te zijn : 1 VMK UNSUPPORTED CPU xbad001e ENODEV Unsupported CPU Ondertussen werden de CPU s terug uit de machine verwijderd en vervangen door de oudere AMD Opteron K8 versies. Met deze CPU s werkte de machine optimaal en zo was het mogelijk alle instellingen op VMware ESX te vervolledigen. Toen de processoren terug vrij kwamen werd een nieuwe versie van de BIOS geïnstalleerd, eenmaal dit gedaan te hebben leek alles goed te verlopen tot de volgende melding verscheen tijdens het opstarten: 1 I n i t i a l i z i n g Cryptographic API NET4: Linux TCP/IP 1. 0 f o r NET IP : r o u t i n g cache hash t a b l e o f 2048 buckets, 16 kbytes TCP : Hash t a b l e c o n f i g u r e d ( e s t a b l i s h e d bind 65536) 5 NET4: Unix domain s o c k e t s 1. 0 /SMP f o r Linux NET4. 0 VFS : Cannot open r o o t d e v i c e UUID=534860c5 a65c 4e29 8a7d 5e 9 3 f 7 d 4 f 3 d 1 or 0 0 : P l e a s e append a c o r r e c t r o o t= boot option Kernel panic : VFS : Unable to mount r o o t f s on 0 0 : k e r n e l 0 xc s. data 0 xc s. bss 0 xc Om dit op te lossen moest er worden opgestart in troubleshooting mode, inloggen en hetvolgende commando werdt uitgevoerd. e s x c f g boot b Dit commando herbouwt de boot record. Eens dit gedaan te hebben kon de server heropgestart worden. De boot procedure verliep vlekkenloos tot de server op het inlog scherm kwam : 56

69 Hoofdstuk 6. Praktisch gebruik van VMware ESX Figuur 6.11: Snapshot disabeling access. Hier werd gedacht aan een probleem met VMware ESX omdat de CPU s recenter waren dan de gebruikte VMware ESX. Dus werd er een upgrade gedaan naar een recentere versie van esx. Hiermee was het probleem echter niet opgelost, na wat verder opzoekwerk hebben we de oplossing gevonden. Desondanks de foutmeldingen kon de VI client worden gestart. Hier bleek ook dat al de luns met data niet meer zichtbaar waren. Toen moest hetvolgende gebeuren: select de host (rootnode), ga naar de Configuratie tab en kies Advanced Settings. Kies LVM en verander dan LVM.EnableResignature op optie 1. Ga dan naar Storage en klik Refresh, alle opslag is terug zichtbaar, de optie LVM.EnableResignature kon terug op optie 0 gezet worden. De server werd hierna heropgestart en alle fouten waren weg. Ook al mijn virtuele machines waren echter verdwenen, dit komt door LVM.EnableResignature. Als deze optie op 1 wordt gezet kunnen er snapshots of replicas van de VMFS volumes terug gebruikt worden maar krijgen ze een nieuw ID. Hierdoor kunnen de virtuele machines niet worden geladen omdat er nog verwezen wordt naar een ander harde schijf ID. Dit heb ik, wegens tijdsgebrek, opgelost door het creéren van nieuwe machines en de bestaande harde schijven te gebruiken. 57

70 Hoofdstuk 7 Benchmarks: Worst load scenario 7.1 Inleiding De bedoeling van dit testscenario is om een vergelijking op VMM niveau te kunnen maken. Meer concreet betekent dit dat we het systeem zwaar proberen te belasten, om zo het maximum uit de beschikbare resources te halen. In deze test zou hierdoor de efficiëntie van de hypervisor in het verdelen van de fysieke resources naar boven moeten komen. Deze situatie komt niet overeen met hoe het er in een productie omgeving aan toe gaat. Figuur 7.1: Schematische weergave van de Linux worst load testopstelling. Dit testscenario bestaat uit vier Linux VMs met de MySQL databasesoftware geïnstalleerd. Elke VM heeft de beschikking over een Logical Unit (LUN) op een RAID array voor de database. Deze machines worden als Online Transaction Processing (OLTP) systemen ingezet en er wordt gebruik gemaakt van de sysbench 1 benchmark. Onze opstelling verschilt van opzet

71 Hoofdstuk 7. Benchmarks: Worst load scenario met het bekende vconsolidate 2 van Intel daar we hier elke VM dezelfde workload toewijzen. Verder sluiten we een extra scheduling factor uit door de som van de VCPUs niet boven het aantal beschikbare fysieke processoren te laten komen. Onze real world testopstelling (hoofdstuk 8) voorziet wél een verschillende workload per VM; namelijk een OLTP systeem, een Online Analytical Processing (OLAP) systeem en twee webservers. 7.2 Opzet Sysbench: Online Transaction Processing (OLTP) benchmark Online Transaction Processing (OLTP) systemen zijn operationele systemen, oftewel transactie verwerkende systemen, voor de ondersteuning van operationele processen zoals invoer en verwerking van data. In een OLTP omgeving dient de database dus geoptimaliseerd te zijn voor grote schrijfacties en kleine leesacties. Voorbeelden van OLTP systemen zijn Enterprise Resource Planning (ERP) en/of Manufacturing Execution Systems (MES) systemen. Naast OLTP systemen zijn er ook nog Descision Support Systems (DSSs) 3 zoals OLAP 4. In ons Linux worst load testscenario maakten we gebruik van de sysbench OLTP 5 benchmark. Deze test laat ons toe de database performantie in schrijfacties van een server te testen. Zo worden hier vooral de processoren en de beschikbare geheugenbandbreedte gestressed, alsook de gebruikte storage. Deze OLTP test wordt toegepast op een MySQL 6 database. Belangrijk is hier de versie van MySQL, daar deze databasesoftware in het verleden niet goed van twee naar vier CPUs schaalde Algemeen sysbench testprotocol Hier wordt het algemeen sysbench on Linux testprotocol beschreven. Dit is het standaard protocol, gegroeid uit research en verschillende testrondes, van waaruit verder gewerkt wordt, telkens door slechts één parameter te wijzigen. Het algemeen testprotocol dat geldig is over de gehele benchmarkfase, wordt nog eens samengevat in bijlage C. De gedetailleerde testconfiguraties, met bijvoorbeeld BIOS instellingen, kan men in bijlage E terugvinden. Virtuele machines Een VM krijgt vier VCPUs toegedeeld. Er wordt ook gezorgd dat deze vastgepinned zijn op de vier cores van een fysieke quadcore CPU. Verder heeft elke VM de beschikking over 4 GiB geheugen. Er is een extra harde shijf voorzien voor de images van de VMs. Ten slotte

72 Hoofdstuk 7. Benchmarks: Worst load scenario heeft elk virtueel systeem de beschikking over een LUN op de externe Redundant Array of Independent Disks (RAID) storage. RAID configuratie De gebruikte Serial Attached SCSI (SAS) controller is de Adaptec RAID Als Direct Attached Storage (DAS) wordt er gebruik gemaakt van de Promise VTrak J300s 8 met zes Seagate Cheetah 15K5 300 GiB 9 SAS schijven. De snelheid van de gebruikte controller en de schijven is belangrijk, opdat deze geen beperkende factor zouden zijn in de tests. In tabel 7.1 vindt men de gebruikte RAID configuratie terug. Tabel 7.1: overzicht van de gebruikte RAID configuratie. RAID Controller instellingen RAID Level: 0 Stripe Size: 64 KiB Read Caching: Yes Write Caching: Enable Always LUN filesysteem Om de RAID storage in verschillende LUNs te verdelen, wordt er gebruik gemaakt van Logical Volume Management (LVM). Bijkomed voordeel is dat de LUNs automatisch gealligneerd worden op fysieke onderlaag (zie sectie?? voor meer over disk alignment). LVM zal er voor zorgen dat een Logical Volume (LV) steeds start op een veelvoud van 64 KiB vanaf het begin van het fysieke volume. Deze offset is te manipuleren door de grootte van de voorziene metadata ruimte aan te passen via de --metadatasize=<size> optie van het pvcreate commando. Een LV zal starten op het volgende veelvoud van 64 KiB, na de metadata; als men dus de standaard metadatasize van 192 gebruikt, zal de eerstvolgende LV starten op 256 KiB. Het gebruikte filesysteem op een LUN is ext3, met de -E stride=16 optie. Deze stride bekomt men door de RAID stripe size, 64 KiB te delen door de gebruikte block size, vier kilobyte, van het filesysteem. De maximale block size in een Linux systeem komt overeen met de gebruikte page size [14]; dewelke 4 KiB is voor IA-32 systemen. patchen om grotere block sizes toe te staan. Het is mogelijk de Linux kernel te

73 Hoofdstuk 7. Benchmarks: Worst load scenario SLES10 installatie Het gebruikte Linux systeem is een SLES10 installatie (SP1/2; x86 en x86-64). Er wordt voor een installatie van het basissysteem gekozen (zonder X en dergelijke). Men dient er rekening mee te houden dat de systeempartitie geformateerd wordt met het ext3 bestandssysteem. Er wordt ook geöpteerd voor de No Access Time (noatime) optie voor elke gemounte partitie in de fstab configuratie; dit is een best practice dat voor een (kleine) performantiewinst kan zorgen. Ten slotte dient er gecontrolleerd te worden dat het standaard runlevel ingesteld staat op 3; er is geen GUI aanwezig. Na installatie wordt het systeem volledig geupdated. De gebruikte SP1 kernel (uname -r) is ; voor SP2 is dit Verder wordt het gcc pakket nog geïnstalleerd (yast -i gcc). MySQL De gebruikte MySQL versie is , met de large configuratie file. Er wordt een testdatabase, sbtest, aangemaakt. De MySQL databases (/var/lib/mysql/ ) dienen op een LUN van de RAID storage te komen. Deze LUN wordt ook gemount met de noatime optie. Sysbench De gebruikte sysbench versie is 0.4.8, en wordt vanaf source gecompileerd. Benchmarking De benchmark fase kan geheel geautomatiseerd worden door middel van een paar scripts, dewelke men terug kan vinden in bijlage F.1. Vanaf een Linux werkstation wordt het sysbench master.sh script gestart, dewelke gelijktijdig Secure Shell (SSH) connecties legt met een gespecifiëerde lijst servers. Op deze servers wordt dan het sysbench client.sh script aangeroepen. Dit script reset en prepareert MySQL (prepmysql.sh) om vervolgens het monitorscript en de benchmark te starten. Het sysbench script zal verscheidene malen een benchmark starten, naargelang de meegeleverde parameters. In ons geval wordt sysbench vier maal achtereenvolgens uitgevoerd, startende met acht threads om zo, in stappen van 8, tot 32 threads te komen. Per test zullen er 25K transacties uigevoerd worden op een recordset van 1M. De gemeten waarde is de uitvoertijd van de test, dat we omrekenen naar het aantal transacties dat uitgevoerd worden per seconde. Ook de 95 percentile latency wordt gemonitorred; deze wordt bekomen door 5 % van de langst durende transacties te laten vallen, om vervolgens het maximum van het overige deel te nemen. Met andere woorden, we meten de lanste wachttijd, na het elimineren van de grootste uitschieters. 61

74 Hoofdstuk 7. Benchmarks: Worst load scenario Om te kunnen vergelijken dienen de benchmarks ook in een native situatie, zonder virtualisatielaag, te worden uitgevoerd. Door de maxcpus=<getal> boot parameter te specifiëren kan men de native Linux kernel duidelijk maken hoeveel CPUs er maximaal geactiveerd mogen worden. In ons geval was dit vier voor de quad tests, en twee voor de dual tests. De waardes voor de test met vier VMs worden bekomen door de gemiddelde score te nemen van de VMs samen. 7.3 Xen benchmarks RAID configuratie - WriteBack vs. WriteThrough Met deze test wilden we de impact van de Write Policy optie van de RAID controller onderzoeken. Hier zijn twee mogelijkheden, namelijk WriteBack en WriteThrough. Met de WriteThrough optie zal de controller de data die toekomt, meteen wegschrijven naar de schijven. De WriteBack optie daarentegen zal datablokken eerst bufferen in diens onboard geheugen, alvorens deze weg te schrijven. Dit brengt als voordeel, onder andere, mee dat de controller de kans krijgt om de toegezonden data te sorteren en deze dan in grote blokken kan wegschrijven. Als de WriteBack optie is ingeschakeld, dient er een batterij op de controller aangesloten te zijn opdat deze de gebufferde data veilig kan stellen bij een stroomuitval van de server. Figuur 7.2: Sysbench: WriteBack versus WriteThrough resultaten. Uit de resultaten, volgens figuur 7.2 en tabellen D.1 en D.2, kunnen we afleiden dat er een performantiewinst van bijna 250 % te behalen is in onze OLTP test door het inschakelen van de WriteBack optie. 62

75 Hoofdstuk 7. Benchmarks: Worst load scenario Xen Quad Opteron 8356 Als eerste werd de AMD Opteron machine (E.1) aan de tand gevoeld. Dit is een 1U server met vier sockets aan boord, welke elk een gloednieuwe quad-core Opteron 8356 bevatten die geklokt staat op 2.3 GHz. De VMs kregen hier de beschikking over 4 VCPUs en 4 GiB werkgeheugen. In de native situatie wordt er gebruik gemaakt van de maxcpus=4 boot parameter om het OS te beperken tot vier cores. Figuur 7.3: Sysbench: Xen Quad Opteron Hier zien we dat deze machine in de native situatie een snelle uitvoeringstijd van gemiddeld 44, 57 s weet te behalen. Wat opvalt uit de resultaten (fig. 7.3 en tabel D.3) is de vrij grote performance drop van 24 % van een DomU tegenover de native situatie. Als we de vergelijking maken met vier draaiende VMs tegenover de native situatie, dan kunnen we een daling van 48 % opmeten. Deze waarden staven het belang van I/O performantie al; de beloofde nearnative performantie steunt enkel op CPU-intensieve taken; dewelke het meest van de tijd in usermode hun werk verrichten Xen Quad Opteron 8356 numa=on Tijdens het uitpluizen van de xm dmesg logs, viel er ons een eigenaardigheid op. Non-Uniform Memory Access (NUMA) ondersteuning, de architectuur gebruikt door deze Opterons, werd namelijk door de Xen VMM uitgeschakeld. Na wat research bleek dat NUMA support in deze bepaalde Xen versie (3.0.4), nog in een experimentele staat verkeert. Uit nieuwsgierigheid hebben we de ondersteuning afgedwongen door de numa=on Xen bootparameter te gebruiken. De testopstelling is exact dezelfde als deze hierboven. Als we de resultaten, uit figuur 7.4 en tabel D.4, vergelijken met de vorige, kunnen we een klein 63

76 Hoofdstuk 7. Benchmarks: Worst load scenario Figuur 7.4: Sysbench: Xen Quad Opteron 8356 numa=on. verschil opmeten van ongeveer twee percent. Deze waardes zijn niet meteen schokkerend te noemen, en daarbij dienen we nog op te merken dat in de vorige testopstelling de architectuur al artificiëel werd afgedwongen door de VMs op de juiste CPU nodes vast te pinnen Xen Quad Xeon E7330 Vervolgens was de Intel machine (E.2) aan de beurt. Zoals de AMD server, is dit ook een 1U machine met vier sockets. In deze test werd er gebruik gemaakt van vier quad-core Xeon E7330 processoren met een klokfrequentie van 2.4 GHz. De VMs kregen hier ook de beschikking over 4 VCPUs en 4 GiB werkgeheugen. In de native situatie wordt er gebruik gemaakt van de maxcpus=4 boot parameter om het OS te beperken tot vier cores. Uit figuur 7.5 en tabel D.5 blijkt dat er hier een verlies van % in OLTP prestaties optreedt als we de prestaties van een enkele DomU tegenover de native situatie plaatst. Dit is zowat een de helft minder dan bij de AMD processoren; echter liggen de native scores bij Intel ook een stuk lager met een gemiddelde van 505 transacties per seconde tegenover 565. Een verdere vergelijking tussen de machines wordt voortgezet in sectie Als we vier domains draaien merken we een prestatieverlies op van 26 % tegenover de native situatie Xen Quad Xeon E7340 In deze testopstelling hebben we de Xeon E7330 processoren vervangen door de E7340. Deze CPUs verschillen maar op één punt, en dat is cache; waar de E7330 twee maal 3 MiB L2 cache heeft, bevat de E7340 twee maal 4 MiB. Op de processoren na, komt de testopstelling overeen 64

77 Hoofdstuk 7. Benchmarks: Worst load scenario Figuur 7.5: Sysbench: Xen Quad Xeon E7330. met de vorige (E.3). Ook hier hebben de VMs weer toegang tot vier VCPUs en wordt de native situatie wederom beperkt met de maxcpus=4 boot parameter. Figuur 7.6: Sysbench: Xen Quad Xeon E7340. Onze vraag is uiteraard: Wat valt er hier te winnen door de L2 cache met 2 MiB op te drijven?. Uit onze resultaten (fig. 7.6, tabel D.6) blijkt dat er een winst geboekt wordt van amper 2 4 % tegenover de E7330 processoren. In deze situatie is het dus niet meteen interessant te investeren in processoren met een iets grotere L2 cache. De grootste overhead ligt namelijk bij de hypervisor. 65

78 Hoofdstuk 7. Benchmarks: Worst load scenario Xen Dual Opteron 8356 Om de schaalbaarheid van de Opteron processoren te meten, werden de sysbench tests nog eens herhaald met twee, in plaats van vier, sockets. In deze test werd er gebruik gemaakt van de AMD machine E.1, na het verwijderen van twee quadcore CPUs. De VMs kregen hier de beschikking over 2 VCPUs en 3 GiB werkgeheugen. In de native situatie wordt er gebruik gemaakt van de maxcpus=2 boot parameter om het OS te beperken tot twee cores. Figuur 7.7: Sysbench: Xen Dual Opteron Uit de resultaten, volgens figuur 7.7 en tabel D.7, merken we dat er een valt te behalen is van 36 % door twee extra processoren bij te voegen. Dit is minder dan we verwachtten en hier wordt in de conclusie (7.5.1) dan ook verder op ingegaan Xen Dual Xeon E7330 Om ook de schaalbaarheid van de Xeon processoren te meten, werden de sysbench tests nog eens herhaald met twee, in plaats van vier, sockets. In deze test werd er gebruik gemaakt van de Intel machine E.2, na het verwijderen van twee quadcore CPUs. De VMs kregen hier de beschikking over 2 VCPUs en 3 GiB werkgeheugen. In de native situatie wordt er gebruik gemaakt van de maxcpus=2 boot parameter om het OS te beperken tot twee cores. Ook hier merken we dat er een maar een winst optreedt van 33 % als we het systeem met vier CPUs tegenover dat met twee plaatsen (fig. 7.8, tabel D.8). In de conclusie (7.5.1) wordt hier verder op ingegaan. 66

79 Hoofdstuk 7. Benchmarks: Worst load scenario Figuur 7.8: Sysbench: Xen Dual Xeon E Xen Quad Opteron 8356 Ten slotte wilden we de performantie van Xen3.0.4, dat geleverd wordt met SLES10 SP1 eens vergelijken met de laatste beschikbare versie van de VMM; namelijk versie Deze diende vanaf de broncode gecompileerd te worden, waarover meer in sectie Behalve de gebruikte Xen versie, is deze testconfiguratie gelijk aan E.1. Figuur 7.9: Sysbench: Xen Quad Opteron De scores (fig. 7.8 en tabel D.8) volgen ook hier het reeds bekende gedrag. Beide Xen versies zijn aan elkaar gewaagd; er is namelijk een kleine perfomantie winst van 3 % als er gebruik 67