NetOpus: December 2007 Thema: Mobiel werken Rubriek: Serie Titel: Conversie en migratie Auteur: Bram Dons & Jan Reinders Pagina s: 44-48 Conversie en migratie Virtueel beheer met VMware deel 3 In de eerste twee delen van deze serie hebben we basis gelegd voor een praktische en betaalbare proefopstelling om ervaring op te doen met VMware Virtual Infrastructure. Vervolgens hebben we een aantal virtuele servers opgezet en daarna twee hosts getest met de nieuwe opties DRS en HA. Het beheer van de omgeving gaat natuurlijk verder dan dat. Met VMware kunnen we namelijk ook de levenscyclus van servers beter beheren. Bram Dons & Jan Reinders In deze aflevering zullen we een oude NT 4.0 server virtualiseren, zodat verouderde hardware eindelijk kan worden afgedankt. We spreken van van Physical2Virtual (P2V) en soms ook van V2V of V2P. We willen geautomatiseerd tijdelijke servers opzetten en ze na gebruik ook weer verwijderen. In de praktijk is de eerste vraag meestal hoe we überhaupt aan de virtuele machines komen. Een methode is natuurlijk om handmatig een VM op de ESX server te creëren en vervolgens alle applicaties daarop te installeren. Als je echter bestaande servers over wilt zetten naar een virtuele omgeving, dan is het veel eenvoudiger en sneller om bestaande fysieke systemen met alle daarop geïnstalleerde applicaties in een keer te converteren naar een VM. We bespreken daarvoor een VMware conversieapplicatie. Een recente VMware ontwikkeling is Virtual Desktop Infrastructure (VDI). Hierbij kan intensief gebruik gemaakt worden van het al langer bestaande concept van templates en cloning. Hiermee kunnen geautomatiseerd virtuele werkplekken ontstaan en ook weer worden opgeruimd. Het blijkt dat de levencyclus van een virtuele machine steeds beter te beheren is in de virtuele wereld van VMware. We bekijken de verschillende mogelijkheden in onze proefopstelling van de vorige afleveringen. Servers, parameters en tools Het maken van een nieuwe virtuele machine is niet moeilijk. Een VM bestaat uit ten minste twee belangrijke bestanden, de VMX file en de VMDK file (virtuele disk). Met de VI client kunnen alle bestanden van een VM eenvoudig zichtbaar worden gemaakt door de datastore (opslag) aan te klikken met browse via rechtermuistoets). Dit is te zien in Afbeelding 1. Door in de VI client een host te selecteren kan handmatig een nieuwe virtuele machine worden gemaakt (Afbeelding 2). In feite wordt daarmee het VMXbestand geconfigureerd zonder dat er kennis over de opbouw van zo n (ascii) bestand nodig is. Daarnaast wordt een VMDK-bestand gemaakt dat een harde schijf zal definiëren. Een virtuele machine is eigenlijk niets meer en niets minder dan een verzameling bestanden. Een aantal faciliteiten van de VM worden door nog een aantal hulpbestanden ondersteund, waarvan het snapshot-bestand en de bios-definitie de belangrijkste zijn. Deze hulpbestanden zijn: Server.nvram - de nvram, ofwel de bios-settings Server.vmdk - de disk descriptor Server-flat.vmdk - de eigenlijke disk Server.vmsd - wordt gebruikt voor snapshots Server.vmx - de beschrijving van de hardware van de VM Server.vmxf - een xml-achtige beschrijving van het vmx-bestand vmware.log - de standaard logfile. Afbeelding 1. In essentie bestaat een virtuele server uit twee bestanden, een configuratiebestand (VMX) en een diskbestand (VMDK)
Conversie en migratie Mobiel werken Afbeelding 2. Alle i/o devices van de vm zijn gedefinieerd. De cluster en de datastore zijn bekend zodat de zowel de VMX als de VMDK zullen worden aangemaakt Zodra een VM actief is komen er nog een aantal bestanden bij: Server.vswp - de kernel swapfile. ESX3 heeft nu voor de kernel van elke VM een eigen swapfile in plaats van één swapfiles voor alle VM s vmware-xx.log bij het migreren (VMotion, DRS) wordt een nieuw logbestand gemaakt, zodat beide ESX-machines kunnen loggen wat ze doen Server.hlog - een bestandje dat VMotion bij een migratie gebruikt Bij een suspend van een VM ontstaat ook een bestand: Server.vmss - de inhoud van het RAM-geheugen op het moment van de suspend Het.hlog-bestand wordt niet opgeruimd na een migratie van een VM. Daarnaast zijn er nog.redo-files als je redo-logging actief is, in verschillende varianten. Handhaven Een andere manier om een VM te maken is het gebruiken van cloning. Een snapshotmanager kan hierbij nog een extra hulpmiddel zijn. Vooral bij het testen van onze omgeving is het maken van een snapshot van de machine een belangrijk hulpmiddel. We maken een snapshot als we tevreden zijn over de werking van een bepaalde machine, en dat kan eventueel dagelijks worden gedaan. Door de verschillende VMSD-bestanden wordt de status van een diskfile als het ware bevroren. Met de snapshotmanager kan dan altijd een stap terug worden gedaan (Afbeelding 3). Met cloning kan een machine in zijn geheel worden overgezet naar een duplicaat. Elke virtuele machine kan worden gekloond. Hierbij kun je ook zaken als computernamen en Security ID aanpassen. Nadat een kloon is gemaakt, kan met de snapshotmanager de source worden teruggezet naar een eerste versie. Op deze manier kunnen we heel gestructureerd te werk gaan. Maak een snapshot van een VM en richt dan deze server in. Maak een kloon van deze versie en ga dan terug naar de uitgangsversie, zodat weer een nieuw systeem kan worden aangemaakt. Afbeelding 3. Er zijn twee snapshots gemaakt. Door een versie te kiezen en go to te selecteren, kan de status van een machine worden teruggedraaid Het maken van duplicaten kan ook met een tussenstapje: een template. Elke machine kan naar een template worden gekloond of geconverteerd. Dit is een niet uitvoerbare machine die te allen tijde als uitgangspunt kan worden gebruikt om een nieuwe machine te maken. Als het een Windows machine is, dan ligt het voor de hand om het template klaar te zetten met een sysprep procedure. Sysprep is een hulpprogramma van Microsoft waarmee een machine down gaat om bij de eerst volgende reboot een nieuwe configuratie aan te nemen voor bijvoorbeeld de computernaam en de interne beveiliging. Als we van een sysprep-machine een template maken voordat deze zal doorstarten, dan is de kloon die we maken van deze template altijd uniek voor wat betreft de computernaam en kan tevens op vele aspecten een herconfiguratieslag doormaken. VMware Converter 3 Een veel snellere en eenvoudigere methode is met behulp van een conversietool en de zogenoemde Physical to Virtual (P2V) methode. De firma VMware heeft daarvoor zelf het gratis VMware Converter 3 tool beschikbaar, maar er zijn ook tools van third-party leveranciers, waaronder de meest bekende PlateSpin en Leostream. Ook via de virtuele techniek van Microsoft is P2V mogelijk naar een VMware-omgeving. De Microsoft s Virtual Server 2005 Migration Toolkit kan een fysiek systeem converteren naar Microsoft s VM format en daarna kan het worden geïm
Schema 1. VMware Converter architectuur, waarub ook een backup-image kan worden omgezet naar een werkende virtuele machine porteerd binnen VMware ESX Server of Workstation. In deze aflevering uit de VMware reeks beperken we onze keus tot die van VMware Converter 3. Met de nieuwe VMware s Converter zijn VM s van bronnen met verschillend formaten (fysieke-, standaloneen EXS Server Server) te importeren in verschillende VMware producten (standalone Workstation en ESX Server). Alhoewel Converter alleen op een Windows-systeem werkt, kan de VM na de conversie naar een door VMware ondersteund host-platform worden overgezet. Naast het Windows OS is Converter in staat om third-party producten als Symantec Backup Exec System Recovery en Microsoft Server/Virtual PC naar VMware s VM s over te zetten. Voor disaster recovery kan een kloon van een fysiek systeem worden gemaakt en de nieuwe VMware Converter 3.0.1 maakt een restore mogelijk van een VMware Consolidated Backup (VCB) image van VM s naar een draaiende VM. VMware Converter biedt een snellere manier van converteren door gebruik te maken van disksector-gebaseerd kopiëren, in tegenstelling tot kopiëren op bestandsniveau bij andere producten. Converter neemt eerst een snapshot van het bronsysteem voordat de conversie begint, wat resulteert in een minder aantal falende conversies en geen downtime voor de server. De Converter communiceert rechtstreeks bij hot cloning met het guest-os dat op de bron fysieke systeem draait, zonder downtime en heeft als zodanig geen betrokkenheid op hardwareniveau. Converter kan op een fysiek systeem of een VM worden geïnstalleerd. In een doorsnee setup wordt zowel de VMware Converter als de Agent geïnstalleerd. De VMware Converter starter is gratis te downloaden van www.vmware.com/ converter. De Converter Enterprise uitvoering ondersteunt ook local cold cloning en kan meerdere conversies tegelijkertijd uitvoeren. Enterprise is echter niet gratis, maar wordt gelicenseerd als onderdeel van de subscription services van VirtualCenter Management Server. Local en remote cloning VMware Converter ondersteunt hot en cold cloning. Bij cold cloning wordt een disk gekloond waarbij de gekloonde disk een virtuele disk is, ofwel een exacte kopie van het fysieke bronsysteem. Het omvat het kopiëren van de diskdata van een fysiek bronsysteem naar een virtuele disk. Natuurlijk is dat niet anders dan het maken van de verschillende VMDKbestanden en een VMX-bestand. Bij de herconfiguratie van het systeem wordt het gemigreerde OS geschikt gemaakt om met de nieuwe virtuele hardware te kunnen functioneren. Deze instellingen gebeuren op de VM na voltooiing van het kloonproces. Het migratieproces is niet destructief, zodat het originele bronsysteem ongewijzigd blijft. Als de VM en het fysieke bronsysteem op hetzelfde netwerk worden ingezet, dan moeten uiteraard wel de netwerknaam en ip-adres worden aangepast. Hot cloning, ook wel live cloning genoemd, omvat het klonen van een bronsysteem terwijl het besturingssysteem actief is. Een agent doet het werk en moet op het bronsysteem worden geïnstalleerd. Bij cold cloning boot de gebruiker opnieuw het bronsysteem vanaf een cd met daarop zijn eigen OS en wordt vanaf de Converter gedraaid. Cold cloning laat geen footprint achter op het bronsysteem. Verder kan het (hot) kloonproces lokaal of van afstand worden uitgevoerd. Bij local cloning wordt de migratie uitgevoerd, waarbij de applicatie (agent en software) op het bronsysteem draait. Bij remote cloning vindt toegang tot het bronsysteem plaats zonder het fysiek te hoeven benaderen, zolang deze maar actief is met een agent. Verder ondersteunt Converter volumeen disk-based cloning. Volume-gebaseerd cloning ondersteunt hot- en cold cloning en de import van bestaande VM s. Bij volume-gebaseerde cloning zijn alle volumes binnen de doel-virtuele machine basic volumes, ongeacht het type van het corresponderende bronvolume. Hot cloning ondersteunt alle type bronvolumes, cold cloning (via boot-cd) alle type dynamische volumes, maar geen Windows NT4 fault-tolerant volumes. Converter ondersteunt diskgebaseerde cloning bij cold cloning en bij de import van bestaande VM s. Bij diskgebaseerde cloning worden alle sectoren van alle disks gekloond, waarbij alle volume-metadata behouden blijven. De doel-vm ontvangt exact dezelfde volumes van hetzelfde type als de bron-vm. Diskgebaseerde cloning ondersteunt alle types basic en dynamic disks. De door Converter gecreëerde VM be
Conversie en migratie Mobiel werken Afbeelding 4. Import bronsysteem Van fysiek naar VM Een fysiek systeem, standalone VM, ESX Server of VirtualCenter VM kan als invoer dienen voor Converter. In ons testvoorbeeld voeren we een conversie uit van een fysieke server, met daarop Windows 2003 R2 (32bit) geïnstalleerd, naar een VM op een ESX Server. In de voorgaande test zijn we uitgegaan van een EXS Server, die wordt beheerd door Virtual Center en is geconfigureerd met de clusters VMware DRS. Converter ondersteunt echter geen clusters waarin DRS is geconfigureerd voor gedeeltelijk of geheel automatisch, zodat we de DRS eerst moeten wijzigen naar manual. Voor de conversie op een lokaal systeem installeren we zowel Converter en de agent. Na het opstarten van Converter klikken we op Import Machine en kiezen we voor Physical Computer. We vervolgen met de Step 1: Source lijst en na doorklikken zien we de pagina Source Type, waarin de schijven worden getoond die voor import in aanmerking komen. Voor elk getoond volume is de New Disk Space aan te passen of compleet weg te laten. Afbeelding 5. Bronvolumes Afbeelding 6. Definieer de target voor de virtuele machine. We kiezen de Virtual Centre machine vat, met uitzondering van sommige hardwareafhankelijke drivers, een exacte kopie van de disk state van het fysieke systeem, VM, of system-image. De instellingen van het bronsysteem die identiek blijven, zijn: OS-configuratie (computernaam, security ID, user accounts, profiles en preferences, enzovoort), applicaties en databestanden, diskpartities en volume serial number. De meeste gemigreerde applicaties zullen correct binnen een VM functioneren omdat hun configuratie- en databestanden dezelfde locatie hebben als op de bron-vm. Sommige applicaties zijn echter afhankelijk van de onderliggende hardware, zoals een serienummer of hardwarefabrikant. Na de migratie kunnen de volgende veranderingen met betrekking tot de hardware plaatsvinden: cpu-model en serienummers, ethernetadapters met een verschillend mac-adres en grafische kaarten (VMware SVGA card). Disknummering en partities blijven hetzelfde, maar elke diskdrive kan een ander model en manu facturing strings bevatten. Primaire diskcontrollers kun nen verschillen met de bronserver en applicaties niet verwerken, omdat ze afhankelijk zijn van devices die binnen een VM na conversie niet meer beschikbaar zijn. Step 2 bestaat uit de keuze voor het doelsysteem waarbij we kiezen voor een VMware EXS Server. Zodra gekozen is voor een Virtual Center target moet ook een host en een datastore worden gekozen (opslag in ons geval). Dit is ons iscsi-systeem. In de daarna volgende pagina s kan worden gekozen uit het aantal beschikbare NIC s en eventueel de installatie van VMware tools. Hieruit blijkt dat de Converter in staat is de images te injecteren met configuratie- en applicatie-gegevens. In de laatste Customization-stap kan de gebruiker nog een aantal zaken aanpassen, waaronder: identificatie VM op netwerk; server licentie, tijdzone en NIC-eigenschappen. De laatste pagina is het Ready to Complete -scherm, waarna het conversieproces start. Afhankelijk van zaken als het aantal te converteren applicaties, diskruimte en
wezig is en voltooit het conversieproces zonder problemen. Na afloop zien we de geconverteerde fysieke server terug als VM binnen de ESX Server. We loggen in op de VM en zien dat Windows 2003 R2 zonder problemen is geconverteerd (Afbeelding 9) Afbeelding 7. De conversie is begonnen waarbij ook de gekozen gegevens in beeld kunnen worden gebracht Afbeelding 8. Listing conversieproces Afbeelding 9. Geconverteerde fysieke server als VM binnen VI omgeving type OS, kan het conversieproces van een tiental minuten tot enkele uren in beslag nemen. Aanvankelijk trachten we een 64-bit systeem met daarop Windows 2003 32-bit geïnstalleerd over te zetten, maar dat accepteert VMware natuurlijk niet. Bij de conversie kijkt Converter naar het aantal aanwezige cpu s op de bron- en de doelserver. In ons geval bestaat de bronserver uit een Dual Xeon processor en het doelsysteem een enkele Pentium 4 cpu. De Converter geeft daarbij prima aan dat slechts één processor op het doelsysteem aan Direct beschikbaar Door met virtuele machines te werken, worden veel beheertaken en stuk eenvoudiger. Met snapshots en cloning kunnen snel nieuwe systemen worden aangemaakt en zelfs bestaande fysieke servers en werkstations kunnen op die manier door conversie direct virtueel beschikbaar worden gemaakt. Het conversietool van VMware is opmerkelijk verbeterd in vergelijking met de eerdere P2V-oplossingen. Met hot cloning kan een fysieke server zelfs dagelijkse en geautomatiseerd gevirtualiseerd worden op een datacenter. In geval van nood heb je dan direct een werkende virtuele backup beschikbaar van je server. «