Na twee lange maanden van tests op Microsofts Hyper-V en VMwares ESX komt het allemaal neer op twee dingen: ervaring en geloofsovertuiging. VMware ESX geniet onze voorkeur omdat het zowel in onze prestatie-analyse als in de geboden beheertools diepte en volwassenheid toont. Hyper-V is wel erg Windows-centrisch, en heeft nog flink wat ruwe randjes.

In onze prestatietest, vorige maand, won ESX het van Hyper-V, al pikte Microsoft hier en daar wel een puntje mee. De compatibiliteitsvoorsprong die Hyper-V in eerste instantie heeft met het aantal ondersteunde hardwareplatforms (door de brede ondersteuning die Windows Server 2008 biedt), wordt geheel teniet gedaan door de gebrekkige ondersteuning voor non-Windows VM's. VMware's lijst van ondersteunde hardware is korter, maar zijn relatief lange lijst van ondersteunde besturingssystemen maakt ons erg blij.

Het Virtual Center beheerplatform van VMware is ook volwassen en het beheer van de VM's op de VMware host is rechtdoorzee. Virtual Infrastructure Client (VIC) is de beheerinterface van Virtual Center.

System Center Virtual Machine Manager (SC-VMM) 2008 (waar wij een erg late bèta van hebben getest die volgens Microsoft alle functionaliteit van het eindproduct bevat) werkt erg nauw samen met het onderliggende Active Directory, en de interface is wat we gewend zijn van System Center zodat beheerders het snel onder de knie hebben. Maar helaas: tijdens de test crashte de boel herhaaldelijk, zowel tijdens het uitvoeren van standaardtaken (het opvragen van de instellingen van een VM host) als tijdens het aanroepen van geavanceerde functies (bijvoorbeeld de migratie van ESX VM's naar Hyper-V).

Beide leveranciers hebben wat ons betreft nog werk te doen op het gebied van beveiligingsopties: de beveiliging van de authenticatie moet beter, en er moet een aparte, veilige opslag komen voor VM-images.

De twee platformen kunnen flink worden aangekleed met een keur aan add-ins die werkelijk van alles kunnen toevoegen, van blikvangende GUI's tot extra functies voor door de leveranciers bevoordeelde hardware. Gezamenlijk kunnen deze functies werkelijk alles betekenen voor iedereen, maar we moesten toch afzonderlijke componenten testen om tot een goede vergelijking te komen.

Dus we kozen voor de standaardbundel: de hypervisor zelf samen met de beheertools voor het aanmaken, uitvoeren, volgen en onderhouden van een VM-infrastructuur in een productieomgeving. Dat betekent in dit geval Hyper-V met SC-VMM 2008 tegen ESX Infrastructure Foundation. Bij die laatste hebben we slechts een optie aangezet, VirtualCenter for ESX, wat net als SC-VMM een startpakket is voor het beheer van meerdere gevirtualiseerde hosts. Op deze manier zijn beide met elkaar vergelijkbaar.

Hoewel we in de regel maar zelden software testen die nog niet helemaal rijp is voor productie, kozen we toch voor de SC-VMM bèta (build 0991.1) voor Hyper-V, omdat de release in september zou zijn en het pakket volgens Microsoft feature-complete is. Maar september werd niet gehaald, en het is nog maar de vraag wanneer hij rtm gaat. Tegen die tijd zullen we nog even kijken naar de definitieve versie, maar nu liepen we tegen vastlopers aan en kent het product nog allerlei beperkingen in de configuraties die niet in het definitieve product horen te zitten.

De gereedschappen

De snelheid van het aanmaken, verplaatsen, monitoren en analyse van VM's is dikwijls cruciaal. Dit omdat virtualisatie vaak een consolidatieslag is, en een enkele server meerdere processen behelst.

We hebben Hyper-V en ESX ieder op twee servers gebouwd, dit om te kunnen meten hoe ze omgaan met zowel nieuwe als geconsolideerde gevirtualiseerde besturingssystemen en applicatieprocessen. We beoordeelden de flexibiliteit bij het aanmaken van nieuwe VM guests, de belangrijkste tools die de zware P2V-taken (het verplaatsen van fysieke server naar VM) op zich nemen, en uiteraard de belangrijkste beheertools.

De tools voor het volgen van VM's rekenden we af op de diepte van de gegevens die elk product ons kon geven en de manier waarop dit wordt gecommuniceerd naar de gebruiker, in logs of reports. We keken ook naar de flexibiliteit van de beveiligingsopties.

VM beheertools moeten ten minste vier basisfuncties kunnen leveren: beheer van hardwaredrivers, toewijzen en aanmaken van ruimte voor VM guests, het volgen van zowel constante factoren (CPU, schijfruimte, I/O) als het melden van incidentele waarschuwingen en het in- en uitladen en backuppen van discrete VM's.

Microsofts SC-VMM helpt bij het aansturen van Hyper-V guests van buiten (dus vanaf een non-virtuele serverhost). De GUI is uiteraard op Windows gebaseerd, en is direct verbonden met de SC-VMM 2008 beheerengine die op dezelfde machine draait als de Active Directory Domain Controller samen met SQL Server. SC-VMM installeert een agent op iedere Hyper-V VM die het onder zijn hoede heeft.

ESX en zijn hosted VM's worden gevolgd en aangestuurd door VirtualCenter, welke als Windows-applicatie op de achtergrond draait op of de virtuele server, of op het Windows-systeem dat ermee verbonden is. VirtualCenter eist dat SQL Server Express Edition geïnstalleerd is om goed te kunnen draaien als opslag voor beheergegevens, en dat een agent op elke ESX Server is gezet.

SC-VMM en VirtualCenter voerden de eerder genoemde beheerfuncties uit met wisselend succes.

Zoals we meerdere malen aangaven in de prestatietest heeft Microsoft een gratis Linux Interface Connector ter beschikking gesteld waarmee SUSE Linux 10 guest-VM's versneld worden.

ESX heeft een add-in genaamd VMTools, die net als LinuxIC netwerk- en geheugendrivers toevoegt en een snellere grafische vertaalslag maakt naar de guest-VM mocht dat gewenst zijn.

Met SC-VMM kan de beheerder een VM-guest aan- en uitschakelen, of subtiel parkeren. Het moet ook mogelijk zijn om gebruikerstoegang voor VM's te beheren vanuit Active Directory. Het is dan, uiteraard, mogelijk om de gebruikers te beperken. Helaas was deze functie duidelijk niet gereed toen we het testten, want SC-VMM hing zich er regelmatig aan op. De omgeving doet ook aan verplaatsing van VM images en moet het zelfs aankunnen om ESX-VM's te importeren naar Hyper-V, maar dat deed het ook niet met de bètacode. Andersom, importeren van Hyper-V images naar ESX, werkte trouwens ook niet, dus kunnen we concluderen dat het bij geen van de hypervisors loont om de images van de ander te gebruiken.

VirtualCenter kan het meeste wat Hyper-V kan, en meer. We konden bijvoorbeeld ook templates aanmaken als basis voor toekomstige VM's, virtuele machines klonen of met een aangeschakelde VMotion (aparte licentie) tussen twee hosts migreren. Het is ook mogelijk om rechten toe te kennen aan verschillende gebruikers en verschillende groepen voor elke VM.

Dan is er de Resource Pool, waarmee hulpbronnen makkelijker worden toegewezen aan verschillende virtuele machines. U hebt, laten we zeggen, zes VM's, en u wilt dat twee daarvan bij elkaar 60 procent van de middelen krijgen, terwijl de rest het met de overige 40 procent moet doen? Dan kunt u twee pools maken en deze toewijzen aan de betreffende VM's.

Bouwen van een virtuele host

We hebben verschillende stappen ondernomen na installatie om de slots klaar te zetten voor onze Hyper-V en ESX hosts. Die slots hebben we vervolgens gevuld met emulatieprocessen van severmigratie en consolidatie. Zodra de hypervisor is geïnstalleerd, konden we in beide gevallen guest-processen creëren die de plaats bezet houden voor besturingssystemen en applicatieprocessen van de fysieke servers die we naar de VM's wilden migreren.

Het installeren van guest instances kon in beide gevallen zonder tussenkomst van SC-VMM of VirtualCenter, en ook de installatie van de daadwerkelijke VM, het besturingssysteem kan gewoon van CD/DVD of netwerkbron. De beheertools maken het proces wel makkelijker. Standaardtaken als duplicatie, aanmaken, kopiëren en toewijzing worden er eenvoudiger mee.

Voor bestaande OS/applicatie-combi's die we moesten migreren hadden de hypervisors een vergelijkbare procedure van het vangen van het serverproces, en import in de virtuele guest-plek die we hadden ingeruimd.

Dit proces heet klonen, en er zijn twee fysieke-naar-virtuele (P2V) methodes beschikbaar die beide hypervisors ondersteunen: vanaf een schijfimage, of van een draaiende productieserver. Helaas konden we Microsofts P2V niet testen, omdat de bèta op dit punt het wederom liet afweten, ondanks flink patchen, getweakte instellingen en vele telefoontjes naar de technische dienst. Het is domweg nog niet af.

VMware's P2V-app heet VMware Converter en is optioneel. Deze werkte wel, zolang de HD-controller werd ondersteund. Met Windows lukte dit het beste, en we konden klonen aanmaken van Windows XP en Windows Server 2003. Met iets meer moeite en extra stappen lukte Linux en WS 2008 ook nog wel.

Images van werkende virtuele machines kunnen vervolgens gebruikt worden als basis van andere VM-guests. Deze zijn in standaardformaten opgesteld en kunnen gemount worden als bestandssystemen zodat de inhoud kan worden aangepast. Voor Hyper-V is dat het cross-Windows VHD-formaat, terwijl ESX VMDK hiervoor gebruikt.

Sommige organisaties gebruiken virtuele images voor verspreiding, en ze moeten daarom aangepast kunnen worden zodat ze uniek kunnen worden gemaakt (iets dat Windows wel eens wil eisen) of om specifieke softwarecombinatie te draaien op andere locaties.

Mounting en aanpassing van de images is met beide pakketten geen probleem, maar hier kleven wel wat haken en ogen aan op gebied van beveiliging.

Volgende week deel twee, met een verslag van het aanmaken van hosts, migratie, monitoren en beveiliging. En uiteraard: de conclusie.

Uitgevoerd door Tom Henderson en Brendan Allen van Networkworld,

vertaling: Michiel van Blommestein Bron: Techworld