Tips, Tricks und HOWTOs Virtualisierung für Profis und Einsteiger Serverkonsolidierung, Testumgebung, mobile Demo

Transkript

1 virtuelle Maschinen mit VMware und Virtual PC Tips, Tricks und HOWTOs Virtualisierung für Profis und Einsteiger Serverkonsolidierung, Testumgebung, mobile Demo Physical to Virtual mit VMware Teil1 Ein System soll von einer physischen Maschine in eine VM umgesetzt werden - Physical to Virtual, kurz P2V. Welche grundsätzliche Vorgehensweise ist angebracht? Welche Stolperfallen lauern? Hier finden Sie die Antworten für Workstation, GSX und ESX! Wer die Investition machen will, kann natürlich gleich auf den P2V- Assistenten von VMware oder auf andere Software, etwa von Platespin, zurückgreifen. Aber auch dort ist manuelle Arbeit notwendig und mit folgender Anleitung geht es ebenso einfach. Einige der hier geschilderten Probleme sind grundsätzlicher Natur, Sie würden auch mit dem P2V-Assistenten darüber stolpern! Hinweis: Dieses PDF-Dokument enthält Lesezeichen als Inhaltsverzeichnis! Direkt vor Ihnen liegt sie - gefährlich, bedrohlich und mit höchster Sprengkraft. Ihre persönliche tickende Zeitbombe! Bloß nicht anfassen! Ja nicht neu machen! Wenn hier etwas kaputt geht! Und dabei ist es eigentlich nur der betagte NT-Server mit einer alten Fibu-Datenbank, die einmal im Monat für irgendwelche Auswertungen noch benötigt wird. Ihr Vorgänger, welcher die Anwendung eingerichtet hatte, ist weg. Wenn jetzt die alte Hardware schlapp macht... Solche oder ähnliche Maschinen finden sich in fast jedem Serverraum. Alte Applikationen fristen Ihr Dasein auf noch älteren Betriebsystemen und betagter Hardware. Eine gute Methode, diese potentiellen Gefahren zu entschärfen, ist Virtualisierung. Die alte Hardware verschwindet, ein Umzug der VM auf aktuellere Hardware ist in Zukunft kein Problem mehr und das System lässt sich, mittels einer einfachen Kopie der virtuellen Systemplatte, für immer Konservieren und Sichern. Nebenbei sieht es im Serverschrank wieder richtig aufgeräumt aus. Cloning oder Neuinstallation? Grundsätzlich gibt es zwei Möglichkeiten, um eine virtuelle Maschine mit Leben zu erfüllen. Der einfachste Weg ist die Neuinstallation eines frischen OS direkt in der VM. Leider ist es in der Praxis nicht immer möglich, diesen sauberen Weg zu beschreiten, weil schon vorhandene Produktionsmaschinen virtualisiert werden müssen. Eine komplette Neuinstallation ist dabei oft unmöglich, da alle Applikationen neu einzurichten wären. Gleich im Vorfeld trotzdem der wichtige Hinweis: Nutzen Sie die Gelegenheit zu einer Bereinigung Ihres Systems! Sie können dank VMware völlig ungestört, parallel zum laufenden Betrieb, ihre 1

2 Server in einer virtuellen Testumgebung komplett neu aufsetzen und alle Applikationen sauber installieren. Das befreit vom Ballast jahrelang aufgelaufener Fehlinstallationen, übrig gebliebener DLLs, alter Treiber, kaputter Konfigurationen oder unnötiger Platzfresser. Und ein Upgrade des OS auf eine aktuelle Version ist dabei auch gleich möglich. Mit einem sauber installierten, frisch gepatchten Server, legen Sie eine gute Grundlagen für Ihre weitere Arbeit. Wenn Sie allerdings den Aufwand einer kompletten Neuinstallation scheuen (und da sind Sie nicht allein!), dann kommt nur die zweite Möglichkeit in Frage - die 1:1 Übertragung des Systems vom physischen Rechner auf eine neue virtuelle Maschine. Folgende Anleitung soll die Grundlagen für diesen Weg der 1:1 Virtualisierung liefern. Allgemeines zur 1:1 Virtualisierung Im Grunde unterscheidet sich die Virtualisierung einer physischen Maschine nicht von einem Austausch der Hardware bei einem echten Rechner-Wechsel. Alle Probleme, die beim Umzug des Betriebssystems auf einen neuen physischen Rechner auftauchen, entstehen auch bei der Virtualisierung. Die Vorgehensweise kann in folgende Schritte aufgeteilt werden: - Vorbereiten des Quellsystems - Image erstellen und Image auf eine leere virtuelle Platte übertragen - Vorbereiten des ersten Startvorganges und erster Start der VM - Nacharbeiten am System in der VM - Daten zurückspielen Jeder einzelne dieser Schritte soll im Folgenden detailliert erläutert werden. Es gibt sicherlich für jeden beschriebenen Weg auch andere Vorgehensweisen, z.b. bei der Art das Image zu erstellen. Die vorgestellten Verfahren sind Vorschläge für eine möglichst allgemeingültige, einfache zu realisierende Variante. Vorbereiten der Virtualisierungsaktion Hardware Zuerst ist auf dem Quellsystem zu prüfen, welche Hardware unter VMware Probleme bereiten könnte und ob man diese umgehen kann. So gibt es keine virtuellen ISDN-Karten, z.b. für die zentrale Faxlösung! Hier hilft der LAN-CAPI eines ISDN-Routers. Achten Sie dabei auf eine eventuell benötigte FAX-G3-Option! 2

3 Dongles in Form von internen Steckkarten, Firewire-Geräte oder die Notwendigkeit spezieller VGA-Karten, können das vorzeitige Aus für ein Virtualisierungsvorhaben bedeuten. Auch die Kompatibilität bestimmter USB-Geräte (auch Dongles!), sollte vorher in einer Test-VM geprüft werden! Lastmessungen müssen bei sehr stark frequentierten Servern unbedingt im Vorfeld erfolgen. Die Virtualisierung eines unter Vollast laufenden Servers mit Dual-CPU auf einem VMware-Host, der ebenfalls nur über 2 CPUs ähnlicher Leistung verfügt, ist nicht sehr sinnvoll. Arbeitet der Quellserver dagegen nur bei 5-10%, steht einem einfachen Dual-CPU-Host nichts im Wege. Die Netzwerkbandbreite und Plattenperformance, sowie der Speicherbedarf (nur 3,6 GByte RAM pro VM!) müssen ebenfalls betrachtet werden. Software Auch bei der Software gibt es Fallen. Lizenzierung mittels Hardwareprüfsummen beispielsweise. So etwas fällt einem oft erst am Ende des Vorhabens, Nachts halb drei auf die Füße. Um diese Zeit kann beim Support garantiert niemand einen neuen Lizenz-Key, passend zur neuen virtuellen Hardware bereitstellen! Eine Neuregistrierung von Betriebssystemen, wie Windows-XP, kann nach dem Umzug ebenfalls notwendig werden. Pilotmigration auf eine Testmaschine unbedingt empfohlen! Böse Überraschungen lassen sich am einfachsten ausschließen, indem man ein Image der Systemplatte des Quellsystems zieht und irgendwann als Pilot-Versuch in eine VM migriert. Das kann in Ruhe in einer abgeschotteten Test-VM, parallel zum laufenden Betrieb des Originals erfolgen. Mit vielen modernen Imaging-Tools (sh. unten) lässt sich sogar das Image für den Test im laufenden Betrieb von der Quellmaschine ziehen. So können schon viele Probleme aus dem Wege geschafft werden, bevor man am Wochenende mit der heißen Umstellung beginnt! Die heiße Phase Sind alle Punkte geklärt und ein Wochenende oder eine lange Nacht ist reserviert, steht dem eigentlichen Vorhaben nichts mehr im Wege. Wichtige Hinweise! Sicherheit! Machen Sie am Quellserver keine unnötigen Änderungen (Treiber entfernen, Applikationen deinstallieren), die Sie nicht einfach wieder 3

4 rückgängig machen können. Tätigen Sie gleich als Erstes ein Image der Systemplatte, welches Sie notfalls wieder zurückspielen können! Es ist immer ein beruhigendes Gefühl, jederzeit wieder den originalen Server in Betrieb nehmen zu können, sollten bei der Virtualisierung Probleme auftauchen! Notieren Sie sich jede Änderung am Quellsystem! Eine komplette Datensicherung vor der Umstellung sollte selbstverständlich sein! Es hat sich bewährt, in den Nächten vor der Umstellung eine Komplettsicherung mit Rücksetzen des Archiv-Bits zu machen. So müssen am TagX nur noch die geänderten Files gesichert werden, das spart wichtige Zeit für die eigentliche Tätigkeit. Entfernen Sie unbedingt das LAN-Kabel vom Quellsystem, damit keinerlei Daten von externen Programmen (Datenbanken, Zeiterfassungen, Mailtransfers, ADS/NDS-Synchronisationen) am System mehr verändert werden, bis es wieder sicher läuft! Verbinden Sie das Quellsystem gegebenenfalls über einen extra Switch, ein separates VLAN oder ein einfaches Cross-Link-Kabel mit einer dedizierten Bridged-Netzkarte im VMware-Host. Bei unkritischen Maschinen ist das nicht unbedingt nötig, bietet aber immer die beste Sicherheit! System vorbereiten Vor der Virtualisierung ist das Quellsystem gründlich auszudünnen, um keinen unnötigen Ballast mitzuschleppen. Dazu gehört das Leeren des Temp-Ordners sowie des Papierkorbes und das Aufspüren großer Dateien, wie Dump-Files o.ä. Ausgezeichnete Dienste leistet hier das Programm SequoiaView, welches sehr anschaulich auf einen Blick die Platzsituation auf der Festplatte visualisiert. Hinweis: Auf einem Server sollten grundsätzlich die Daten-Partitionen und die System-Partition getrennt sein. So dürfte die System-Partition in den wenigsten Fällen 4-5Gbyte überschreiten. Wer nur eine einzige Riesenpartition mit System und Daten hat, der bekommt beim Image Probleme mit dem Platz- und Zeitbedarf! Bei getrennten Partition können die Daten nach erfolgreicher Virtualisierung später einfach per Backup- Software übertragen werden. Als nächstes sollten alle Dienste auf Deaktiviert gestellt und beendet werden, die sehr viel Zeit zum Starten benötigen, oder die auf Datenbanken zugreifen, z.b. Exchange-Dienste, Datenbankserver oder Virenscanner. Änderungen an Daten durch laufenden Programme müssen unbedingt verhindert werden! 4

5 Konfigurations- und Monitoring-Programme (Intel-, Compaq- ServerManagement usw.) könne schon deinstalliert werden, wenn ein Sicherungs-Image des Servers vorhanden ist. Schließlich müssen Sie sich unbedingt die IP-Konfiguration notieren, weil diese, aufgrund anderer Netzkarten im Quellsystem, neu anzulegen ist! Ein ipconfig /all > c:\ip.txt schreibt die notwendigen Daten in eine Datei auf C:\, welche dann gleich im Image liegt. Treiber Großes Augenmerk ist schon im Vorfeld auf die notwendigen IDE, oder SCSI-Treiber zu legen. Vor dem Image müssen die später benötigten Treiber vorinstalliert werden, sonst gelingt es unter Umständen nicht, die virtualisierte Maschine zu starten! Auf die Treiberproblematik gehe ich ausführlicher im zweiten Teil des Workshops ein. Im ersten Teil arbeiten wir grundsätzlich mit virtuellen IDE- Platten. ESX-Nutzer (kennt kein IDE) müssen sich noch bis zum zweiten Teil gedulden oder eine Zwischenstufe auf Workstation, bzw. GSX nutzen. Hier im ersten Teil nur soviel: ACHTUNG! Sorgen Sie unbedingt dafür, dass in der Quellmaschine (vor allem XP, W2003) unter "IDE-Controller" kein herstellerspezifischer Treiber installiert ist. Ändern Sie den Treiber im Gerätemanager in einen "Standard-Zweikanal-PCI-IDE-Controller" rechte Maustaste > Eigenschaften > Treiber > Treiber aktualisieren > alle bekannten Treiber in einer Liste anzeigen Besonders XP und Windows2003 können in einer VM oft nicht starten ohne diese Vorbereitung. Warum das so ist und andere Wege zur Umgehung dieses Problems, erfahren Sie ebenfalls im zweiten Teil. Der hier im Bild installierte VIA-Bus-Master- Controller wird bei Clonen von XP garantiert zu einem BlueScreen führen! 5

6 Imaging-Programm wählen Sind alle Vorbereitungen getroffen, kann vom Quellsystem ein Image der System-Partition gezogen werden. Hierzu gibt es eine Vielzahl von Programmen, welche je nach Geschmack eingesetzt werden können. Eine sehr gute Alternative zu den teuren Kandidaten, wie Ghost, DriveImage oder Acronis ist z.b. Drive SnapShot ( Der große Vorteil von Drive Snapshot ist das Format als einfache EXE- Datei, welche ohne Installation oder Neustart, direkt im laufenden System, ausgeführt werden kann! Das ist sehr praktisch, um noch im Produktionsbetrieb ein Image für die Testmigration zu ziehen. Leider kommt das Tool auf manchen Raid-Systemen mit Wartungspartition (z.b.: Compaq) beim Zurückspielen des Images nicht immer zurecht. Das in einer Ziel-VM zu testen, ist aber dank VMware problemlos möglich! Sehr gute Erfahrungen habe ich mit dem recht teuren Tool Acronis True Image gemacht. Es kommt auch problemlos mit Systempartitionen auf dynamischen Datenträgern zurecht. Weiterhin lässt sich eine Boot-CD mit GUI, vollem Funktionsumfang und sicher funktionierendem Netzwerk erstellen. ( Letztendlich ist die Auswahl den persönlichen Vorlieben und Erfahrungen überlassen. Das eigentliche Problem ist nicht die Wahl des richtigen Tools, sondern die Übertragung des Images in eine virtuelle Platte. Dazu hat sich das Erstellen einer Wartungs-VM bewährt. 6

7 Wartungs-VM einrichten Die Wartungs-VM ist unser Werkzeug, wenn es darum geht, das Image auf eine virtuelle Platte zurückzuspielen und später einige Nacharbeiten am geklonten System zu machen. Die Wartungs-VM ist nichts weiter, als eine virtuelle Maschine mit laufendem OS und allen benötigten Tools. Die Verwendung dieser Wartungs-VM und das weitere Vorgehen, zeigt folgendes Bild als Übersicht: Clone der physischen Maschine erstellen virtuelle Welt Netzwerkverbindung über Bridged-Adapter physische Maschine verbunden mit LW I: der Wartungs-VM Wartungs-VM z.b. mit Win2000 und Drive-Image o.ä. C: System D: Daten C: System I: Images leere Platte Schritt 1: Erstellen einer Image-Datei von der Systempartition der physischen Maschine Schritt 2: Zurückspielen der Image-Datei auf eine leere virtuelle Platte Clone anpassen und bootfähig machen virtuelle Welt Wartungs-VM z.b. mit Win2000 und Drive-Image o.ä. neue VM Clone des physischen Systems C: System I: Images Clone C: System Schritt 3: Änderungen an geklonter System-Partition (Boot.ini, HAL.DLL usw.) Schritt 4: Umhängen der Platte mit dem geklonten System in eine neue VM Sven Ahnert - Erstellen Sie eine neue VM mit drei virtuellen Platten: Platte1 enthält das gewünschte Betriebssystem für die Wartungs-VM, z.b. Windows2000. Dieses System kann frei gewählt werden und hat nichts mit dem physischen Quellsystem zu tun! Platte2 ist eine ausreichend dimensionierte, leere virtuelle Platte, welche später die Image-Dateien der originalen physischen Rechner aufnehmen wird. 7

8 Platte3 wird später die Systemplatte der übertragenen Maschine. Diese Platte muss die bootfähige Systempartition des Quellsystems aufnehmen und ist entsprechend zu dimensionieren. ACHTUNG! Platte3 muss eine IDE Platte sein! In dieser Wartungs-VM installieren Sie ein ordentlich lauffähiges Betriebssystem und sorgen für einen funktionierenden Netzwerkzugang mit einem Bridged-Adapter. Weiterhin installieren Sie alle ServicePacks und Patches, sowie häufig benötigte Tools (Zip, Texteditor...), welche Sie bei Ihrer täglichen Arbeit nicht missen möchten. Und vor allem natürlich Ihr Imaging-Tool der Wahl! Hinweis: Wenn Sie lieber eine bootfähigen CD zum Image-Zurückspielen verwenden (BartPE, Knoppix, Acronis...), so können Sie das tun. Die Wartungs-VM wird Ihnen trotzdem gute Dienste leisten! Tipp! Machen Sie von der VM keinen Snapshot! Sonst landen alle Aktionen, z.b. das spätere Image-Zurückspielen, erst in Redologs und müssen dann sehr zeitaufwändig, mittels Remove Snapshot, auf die eigentliche virtuelle Platte übertragen werden! Kopieren Sie lieber zur Sicherheit die fertige Systemplatte komplett, für den Fall, dass beim Image Zurückspielen die falsche Platte als Ziel gewählt wird. Sie wären nicht der Erste, dem das passiert ;-) Die virtuelle Platte2 der Wartungs-VM wird nun formatiert und im LAN freigegeben. Image erstellen und Klonen Wir wechseln jetzt zur vorbereiteten physischen Maschine. Dort wird die freigegebene Platte2 der Wartungs-VM als Netzlaufwerk verbunden. Mit einem Imaging-Tool, welches eine laufende System-Partition sichern kann, wird die Systempartition in ein Image-File gesichert. Dieses Image- File wird über das Netzwerk gleich auf der verbundenen virtuellen Platte2 der Wartungs-VM abgelegt. Das geht natürlich auch mit einer ordentlich funktionierenden Boot-CD. Oft hat man aber Stress, dort auf Anhieb die Netzwerkkarte der Quellmaschine zum laufen zu bringen. Achtung! Wie schon erwähnt: Vor dem Image sollte die Quellmaschine vom öffentlichen Netz getrennt oder heruntergefahren werden, um nachträgliche Änderungen an den Daten zu verhindern! Bei einer Testmigration ist das natürlich nicht nötig. Nach erfolgtem Image wechseln wir wieder zur Wartungs-VM. Wenn das Image-File dort ordentlich angekommen ist, kann es mit dem Imaging-Tool auf die virtuelle Platte3 zurückgespielt werden. Platte3 ist dann die geklonte Systemplatte des Quellsystems. 8

9 Fertig! Wir haben einen Clone unseres physischen Rechners! Platte3 kann nun in eine neue jungfräuliche VM als Systemplatte eingebunden werden. Wer Mut hat, kann diese VM schon einmal booten. Mit etwas Glück, mit funktionierendem Plug&Play und vor allem mit IDE als Plattentyp, läuft unsere virtualisierte Maschine in 70% der Fälle problemlos hoch! In den anderen 30% werden Sie einen Bluescreen zu Gesicht bekommen mit verschiedenen Fehlermeldungen. Und genau hier beginnt der knifflige Abschnitt! Vorbereiten des ersten Startvorganges der VM Wenn Sie bei Ihrem ersten Startversuch kein Glück hatten, müssen verschiedene Anpassungen an dem System auf Platte3 gemacht werden, bevor es in eine neue VM als Systemplatte umgehängt werden kann. Dabei ist es von Vorteil, dass man in der Wartungs-VM einfach den Inhalt der geklonten Systemplatte editieren kann, um z.b. die Datei Boot.ini anzupassen. Schritt3 der obigen Zeichnung wird das Thema des nächsten Teils dieses P2V-Workshops. Probleme bei Multiprozessor-Quellmaschinen, Ersetzen der HAL.DLL, Anpassen der Boot.ini, Treiberprobleme mit SCSI-Platten, verschobene Directory-Datenbanken oder Transaction-Logs, Editieren der Registry es gibt genug zu tun, um das System in der virtuellen Maschine zum laufen zu bekommen, wenn es nicht gleich beim ersten Versuch bootet. Sollten Sie zu den glücklichen 70% gehören, bei denen es funktioniert hat, können Sie jetzt schon die VMware-Tools in Ihrer virtualisierten Maschine installieren, die Netzwerkkonfiguration neu einrichten und die Daten auf eine separate virtuelle Platte per Bandsicherung und Sicherungs-Agent zurückspielen. Fertig! Weitere mögliche Nacharbeiten an der neuen VM sind ebenfalls Thema von Teil2. Sven Ahnert 9