Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Einführung
2 Virtuelle Maschinen im Unternehmen
3 Virtualisierungssoftware – eine Marktübersicht
4 Auswahl der möglichen virtuellen Maschine
5 Auswahl der richtigen Virtualisierungssoftware
6 Auswahl der richtigen physikalischen Infrastruktur
7 Installation und Update des Wirt-Systems
8 Verwaltung der Virtualisierungssoftware
9 Virtuelle Netzwerke
10 Virtuelle Festplatten
11 Erstellung einer virtuellen Maschine
12 Verwaltung der virtuellen Maschinen
13 VMware VirtualCenter
14 Skriptierung und Programmierung unter VMware und MS Virtual Server
15 Backup, Restore und Disaster Recovery
16 Templates (VM-Vorlagen)
17 Zusatzsoftware
18 Nützliche Adressen im Web
A Clustereinrichtung und Beispielumgebungen
B Kommandozeile und wichtige Dateien
C Häufige Fragen
Stichwort

Jetzt Buch bestellen
Ihre Meinung?

Spacer
<< zurück
VMware und Microsoft Virtual Server von Dennis Zimmer
Virtuelle Server im professionellen Einsatz
Buch: VMware und Microsoft Virtual Server

VMware und Microsoft Virtual Server
geb., mit CD
612 S., 49,90 Euro
Rheinwerk Computing
ISBN 978-3-89842-701-2
Pfeil 17 Zusatzsoftware
Pfeil 17.1 Migration – P2V, V2V
Pfeil 17.1.1 VMware P2V Assistent
Pfeil 17.1.2 VMware Virtual Machine Importer
Pfeil 17.1.3 Microsoft Virtual Server Migration Toolkit
Pfeil 17.1.4 Platespin PowerP2V
Pfeil 17.1.5 Leostream P>V Direct
Pfeil 17.2 Sonstiges
Pfeil 17.2.1 Leostream Virtual Controller
Pfeil 17.2.2 Platespin PowerRecon
Pfeil 17.2.3 Dunes VS-M
Pfeil 17.2.4 Dunes VS-O
Pfeil 17.2.5 ESXRanger
Pfeil 17.2.6 OpalisRobot CAP for VMware/Virtual Server

17 Zusatzsoftware

Nicht nur die eigentlichen Hersteller, sondern auch Drittanbieter bieten nützliche Programme zur besseren Administration der Virtualisierungssoftware und der Migration der virtuellen Maschinen an.

Es existiert mittlerweile eine Vielzahl an Werkzeugen und Programmen von den Virtualisierungsherstellern aber auch von Drittanbietern zur Verwaltung und Migration virtueller Maschinen. Da ich nicht auf alle am Markt verfügbaren Produkte eingehen kann, habe ich mir die bekanntesten und in Foren sehr häufig erwähnten Programme genauer angeschaut, um Ihnen einen Überblick zu verschaffen. Auf Plugins verschiedener Management Tools wie z. B. das Hewlett-Packard Openview Plugin oder den IBM Director Virtual Machine Manager etc. bin ich nicht eingegangen, da sie zwingend einer Installation des Hauptproduktes bedürfen.


Rheinwerk Computing - Zum Seitenanfang

17.1 Migration – P2V, V2V Zur nächsten ÜberschriftZur vorigen Überschrift

Viele Firmen nutzen bei einer Umstellung von physikalischer auf virtuelle Infrastruktur die Gelegenheit und installieren viele Server komplett neu in virtuellen Maschinen. Dies macht auch oft Sinn, weil die Server im Laufe der Zeit immer Softwareaktualisierungen und sonstigen Installationen unterworfen sind, was sie mit der Zeit immer träger und störungsanfälliger macht. Allerdings gibt es auch Systeme, deren Neuinstallation schier unmöglich ist, da entweder die Installationsdateien fehlen oder schlichtweg das Know-how nicht mehr vorhanden ist. Hier bietet es sich an, die physikalische Maschine als Ganzes in eine virtuelle Maschine umzuwandeln. Dieses Verfahren nennt man P2V-Migration (physical to virtual). Je nach Systemausstattung bzw. Servermenge ist dieses Verfahren mehr oder weniger aufwändig. Des Weiteren kann neben der manuellen Art über Images auch der Weg über speziell dafür ausgelegte Programme beschritten werden. Software wie beispielsweise PowerP2V der Firma Platespin eignet sich insbesondere für sehr große Umgebungen mit vielen Servern, da hier die Migration größtenteils automatisiert werden kann.

Ein gibt eine weitere Form, nämlich die der Migration zwischen virtuellen Maschinen. Wenn beispielsweise von Microsoft Virtual Server auf VMware GSX/ESX oder umgekehrt gewechselt werden soll, dann nennt man das V2V-Migration (virtual to virtual). Hier bieten Ihnen die jeweiligen Hersteller kostenlose Hilfsprogramme an, aber auch Drittanbieter decken diesen Fall oftmals ab.


Bedenken Sie, dass Ihnen die P2V-Produkte allenfalls den Migrationsprozess selbst erleichtern. Alle sonstigen Vorarbeiten, die notwendig sind, um das System migrationsfähig zu machen, bleiben davon unberührt. Im Normalfall wird auch nur die Systempartition migriert, daher sind die Datenpartitionen später manuell nachzuziehen. Folgende Tätigkeiten sind in jedem Fall vor der Migration durchzuführen:

  • Komplettsicherung des Systems
  • Entfernen aller hardwarespezifischen Softwareinstallationen (z. B. RAID Software, Netzwerkkartensoftware wie Intel ProUtil)
  • Falls die Systempartition eine dynamische Festplatte ist, sollten Sie diese wieder zu einer Basisplatte konvertieren. Wenn Sie ein Softwareraid oder Stripeset mittels dynamischen Festplatten auf der Systempartition betreiben, haben Sie derzeit wenig Chancen, eine saubere Migration durchzuführen. (Eine solche Konfiguration sollte aber äußerst selten vorkommen.)
  • Deaktivieren aller Programme und Dienste, die auf Partitionen zugreifen, die zu einem späteren Zeitpunkt migriert werden (z. B. Datenbankprogramm auf Systempartition, Datenbanken auf Datenpartition)

Aber auch nach der Migration bleibt viel zu tun:

  • Installation der Tools des Virtualisierungsproduktes (VMware Tools oder Virtual Machine Additions)
  • Funktionstest des Netzwerks, der Systemdienste etc.
  • Rücksicherung der Datenpartitionen
  • Kompletttest des Systems
  • ggf. Einrichtung der Sicherung auf dem neuen System


Rheinwerk Computing - Zum Seitenanfang

17.1.1 VMware P2V Assistent Zur nächsten ÜberschriftZur vorigen Überschrift

Dieses Produkt wurde von VMware selbst mit dem Ziel entwickelt, den Umstieg von der physikalischen in die virtuelle Welt stark zu vereinfachen. Das Produkt bringt allerdings verschiedene Einschränkungen mit, durch die nicht jedes beliebiges System problemlos bzw. überhaupt umgestellt werden kann. Dazu gehören beispielsweise Multibootsysteme oder physikalische Maschinen mit Linux-Betriebssystem. Zudem können verschiedene SCSI- oder Netzwerkkarten Probleme bereiten. Daher kann ich Ihnen nur empfehlen, zunächst alle Randbedingungen, sprich Kompatibilitäten abzuklären, bevor Sie P2V-Produkte einsetzen. Die VMware-Produktwebseite von P2V bietet Ihnen dazu stets aktuelle Informationen. Falls die Hardware überhaupt nicht erkannt wird, können Sie sich unter Umständen noch mit einer Software von Drittanbietern wie z. B. Imagingtools wie Symantec Ghost behelfen, die auch durch VMware P2V angepasst und bearbeitet werden können. Weil nicht alle Betriebssysteme auf dem physikalischen System unterstützt werden, hier eine Übersicht:


Tabelle 17.1 Systemanforderungen VMware P2V Assistent

P2V Assistent Komponente unterstützte Produkte

Virtualisierungsprodukt

  • VMware ESX Server, 2.x
  • VMware GSX Server, 3.x
  • VMware Workstation, 4.x

Helper Machine (Client)

  • Windows NT4 Server (muss zwingend zur Migration eines NT4 Quell-Systems benutzt werden)
  • Windows 2000 Professional
  • Windows 2000 Server
  • Windows 2000 Advanced Server
  • Windows XP
  • Windows 2003 Standard
  • Windows 2003 Enterprise
  • Windows 2003 Datacenter

Quell-System (Server)

  • Windows NT 4 Workstation
  • Windows NT4 Server
  • Windows 2000 Professional
  • Windows 2000 Server
  • Windows 2000 Advanced Server
  • Windows XP
  • Windows 2003 Standard
  • Windows 2003 Enterprise
  • Windows 2003 Datacenter

Abbildung 17.1 Migrationsprozess VMware P2V

Wie funktioniert dieser Migrationsprozess nun genau?

VMware P2V besteht aus zwei Komponenten, einer Boot-CD und einer Installationsroutine für die eigentliche P2V Software. Mit der Boot-CD wird das physikalische System (»Quell-System«) gestartet und zum P2V Server im Netzwerk konfiguriert. Dieser Server erkennt selbstständig Festplatten und Netzwerkkarten des zu migrierenden Systems, daher ist die Hardwareunterstützung durch P2V sehr wichtig. Ab diesem Zeitpunkt kann mit der zweiten Komponente, der eigentlichen P2V Software von einem beliebigen System im Netzwerk auf den Quellserver zugegriffen werden. Wenn diese Verbindung steht, wird ein Image der Bootpartition des Quell-Systems auf dem lokalen PC (auf dem die P2V Clientsoftware läuft) erstellt und auf die entsprechende Virtualisierungssoftware zugeschnitten. Nun muss nur noch die entstandene Festplattendatei der virtuellen Maschine als »exististing disk« eingetragen werden.

Soviel zur grauen Theorie. Gehen wir nun einmal den Prozess konkret durch.

P2V Server (über Boot-CD)

Nach dem der Server mit der P2V Boot-CD gestartet wurde, erscheint der P2V Assistent, der eigentlich den Serverteil der P2V Software darstellt. Neben einigen Informationsmeldungen erscheint auch der Hinweis (Abbildung 17.2), wo auf der CD die Kompatibilitätsliste für die getestete Hardware zu finden ist. Des Weiteren können Sie während des gesamten Vorganges mit Alt + F2 auf eine andere Kommandozeile wechseln und sich mit root anmelden. Ein Kennwort ist hier nicht erforderlich. Ebenfalls wird erwähnt, dass nicht nur mit P2V Images, sondern auch mit solchen von Drittanbietern (z. B. Symantec Ghost) gearbeitet werden kann. Dies ist vor allem dann sinnvoll, falls die lokale Hardware des Quell-Systems nicht von P2V unterstützt wird.

Die nächste erscheinende Meldung zeigt Ihnen die erkannten Geräte wie Festplatten und Netzwerkkarten an. Wenn Sie dies mit OK beantworten, wird in den nächsten Dialog gewechselt, der Sie nach einem erweiterten Hardwarescan fragt (Abbildung 17.3). Sollte alles Notwendige erkannt worden sein, können Sie diese Meldung mit No beantworten.

Abbildung 17.2 Hinweis nach dem Start

Abbildung 17.3 Soll nach weiteren Hardwarekomponenten gesucht werden? Meist kann hier No ausgewählt werden.

Wenn auch der Hardwaredialog erfolgreich abgeschlossen wurde, werden Sie als Nächstes dazu aufgefordert, die Netzwerkkonfiguration vorzunehmen (Abbildung 17.4). Hier können Sie, falls ein DHCP-Server im Netzwerk verfügbar ist, Use DHCP auswählen, ansonsten müssen Sie alle Angaben manuell eingeben. Denken Sie daran, dass dieser P2V Server später vom P2V Client auf dem Administrationsrechner erreichbar sein muss. Zudem können Sie einen Port angeben, über den der Rechner mittels P2V kommunizieren soll.

Abbildung 17.4 Netzwerkeinstellungen des P2V-Assistenten

Abbildung 17.5 Informationsbild des P2V Servers

Ist erst einmal die IP-Adresse vom DHCP Server bezogen oder manuell eingetragen, startet der P2V Server die Netzwerkunterstützung. Sobald dies passiert ist, wird Ihnen ein Dialog mit allen Informationen angezeigt. Diese Infos müssen später im P2V Client als Zielrechner hinterlegt werden.

Ganz wichtig ist hier, dass dieses Informationsbild stehen bleibt. Es ist dies nämlich die letzte Aktion für die P2V Boot-CD, und der Server läuft ab jetzt. Daher müssen Sie hier nichts mehr tun. Also lassen Sie den Rechner in diesem Zustand laufen, und gehen Sie beruhigt an den Administrations-PC.

P2V Client (Installierte P2V Software)

Auf einem beliebigen Windows-Rechner im Netzwerk können Sie nun die Installation durchführen und anschließend die benötigten Lizenzen eintragen. Sobald dies erledigt ist, können Sie die P2V Software auch schon starten.

Abbildung 17.6 Einstiegsbild von VMware P2V, hier können Sie neue Server migrieren oder bestehende Images bearbeiten (auch Images von Drittanbietern).

Da nun schon der P2V Server auf einem der physikalischen Server läuft, wird wie in Abbildung 17.6 die Auswahl Clone a source computer... getroffen. Falls wir schon zu einem früheren Zeitpunkt ein Image gezogen hätten, würde man es über die Auswahl Perform a System Reconfiguration... bearbeiten und für das gewünschte VMware-Produkt vorbereiten können.

Abbildung 17.7 Auswahl des Quell-Systems auf dem der P2V Server gestartet ist.

In einem nächsten Schritt ist der P2V Server selbst anzugeben. Wie in Abbildung 17.7 zu sehen ist, werden IP-Adresse und der im Serverteil angegebene Port hinterlegt. Sobald dies geschehen ist, verbindet sich der P2V Client mit dem Ziel-System und liest dessen Daten aus. In den darauf folgenden Dialogen kann man zwischen den gefundenen Festplatten und den darauf liegenden Partitionen auswählen.

In Abbildung 17.8 sehen Sie den nächsten Dialog, der Sie danach fragt, ob Sie das physikalische System nur Klonen, demnach ein Image ziehen wollen, oder ob das Image danach auch konfiguriert werden soll. Da nur durch eine entsprechende Konfiguration die Daten innerhalb der entstehenden Festplattendatei so angepasst werden, dass Sie direkt für VMware verwendbar ist, wählen wir diese Option aus. Die Auswahl der ersten Option macht immer dann Sinn, wenn das daraus entstehende Image für viele verschiedene virtuelle Maschinen auf unterschiedlichen VMware-Versionen dienen soll. Man kann man es nämlich zu einem beliebigen Zeitpunkt nochmals in den P2V Client laden und an das entsprechende Ziel-System anpassen (Auswahl 1 in Abbildung 17.6).

Abbildung 17.8 Soll nur ein Image gezogen werden oder soll es nach der Erstellung direkt konfiguriert werden?

Abbildung 17.9 Wo soll der Ablageort der Festplattendatei sein?

Nun wird nach dem Zielort für die Festplatte gefragt. Hier haben Sie zwei konträre Optionen: Entweder es wird eine komplette Festplatte genutzt, die direkt an dem administrierenden Rechner (in diesem Fall P2V Client) hängt, oder die Festplattendatei wird in ein Verzeichnis geschrieben. Die erste Option macht hauptsächlich Sinn, wenn der P2V Client in einer virtuellen Maschine ausgeführt wird, an die eine zweite virtuelle Festplatte gebunden wurde. Bei der zweiten Option können Sie zudem angeben, ob die Festplattendatei in die mittlerweile bekannten 2 GB-Dateien aufgeteilt wird und ob die Festplattendatei den gesamten Plattenplatz einnimmt. (Sie erinnern sich, dass bei VMware Workstation und GSX die Möglichkeit besteht, Festplatten anwachsen zu lassen, statt diese direkt mit der vollen Größe anzulegen.) Jetzt können Sie noch die zu kopierenden Partitionen und deren Zielgröße anpassen.

Abbildung 17.10 Erzeugung des Images

Sobald die Plattenauswahl getroffen wurde, wird von P2V mit dem Imaging begonnen. Das erkennen Sie an einem Fortschrittsbalken und der geschätzten Dauer. Darüber hinaus wird Ihnen noch die derzeitige Übertragungsrate über das Netzwerk und die noch zu kopierende Datenmenge angezeigt.

Abbildung 17.11 In welchem Format soll die Festplattendatei endgültig abgelegt werden?

Zum Abschluss der Migration wird Ihnen die Auswahl der möglichen Zielformate angezeigt (Abbildung 17.11), die natürlich mit den Aktualisierungen von VMware P2V ständig erweitert werden. In der von mir verwendeten Version 2 fehlen VMware Workstation 5 und ESX Server 2.5. Das stellt allerdings kein Problem dar, da man dies mit einem simplen Hardwareupgrade bei ausgeschalteter virtueller Maschine über die entsprechenden Administrationswerkzeuge nachziehen kann. Die Aktivierung des Pre-Installs der VMware-Treiber ist absolut zu empfehlen, weil mit ihnen eine deutlich bessere Performance zu erzielen ist als ohne dieselben, auch wenn sie älteren Baujahrs sind. Allerdings sollten Sie, sobald die virtuelle Maschine auf dem endgültigen VMware-System ist, die VMware Tools auf den neuesten Stand bringen und so die aktuellsten Treiber installieren. Nach der Auswahl des gewünschten VMware-Zielproduktes wird die Festplattendatei von P2V fertig konfiguriert und kann nach dem Kopieren an den Zielort direkt in einer neuen virtuellen Maschine als bestehende Festplatte (exisiting disk) genutzt werden.


Rheinwerk Computing - Zum Seitenanfang

17.1.2 VMware Virtual Machine Importer Zur nächsten ÜberschriftZur vorigen Überschrift

Dieses Programm von VMware können Sie kostenfrei von der offiziellen Webseite herunterladen. Es dient dazu, virtuelle Maschinen des Konkurrenten Microsoft, sprich Virtual PC und Virtual Server, in ein VMware nutzbares Format zu konvertieren.

Abbildung 17.12 Auswahl des Formats nach der Umwandlung

Nach dem Start der Software können Sie zuerst die Art der Konfiguration auswählen. Nach Auswahl von Typical wird nach einer auf dem Rechner installierten VMware-Version gesucht, und die Umwandlung der Virtual PC/Server-Maschine wird automatisch an die installierte Version angepasst. Bei Custom können Sie später selbst entscheiden, welches Ausgabeformat entstehen soll.

Abbildung 17.13 Name und Ablageort der umgewandelten virtuellen Maschine

Nachdem Sie den Pfad zur Konfigurationsdatei (.vmc) der virtuelle Maschinen des Virtual PC/Servers im Dialog angegeben haben, wird diese Datei analysiert. Denken Sie jedoch daran, dass die virtuelle Maschine abgeschaltet sein muss. In Abbildung 17.13 sehen Sie den daraufhin erscheinenden Dialog, der nach dem Zielort und dem Namen der zukünftigen VMware VM fragt.

Abbildung 17.14 Neues oder altes Format?

Nun müssen Sie das endgültige Format nach der Umwandlung auswählen, das entweder VMware Workstation 5-kompatibel oder Legacy (Workstation 4, GSX, ESX) ist (Abbildung 17.14). Das Legacy-Format lässt sich später problemlos mit allen anderen VMware-Produkten nach einer entsprechenden Konvertierung verwenden. Zum Zeitpunkt der Drucklegung des vorliegenden Buches gab es keine VMware-Serverversion, die mit dem Workstation 5-Format hätte umgehen können, daher ist hier immer Legacy zu wählen.

Abbildung 17.15 Konvertierung der virtuellen Maschine vom Virtual PC/Server-Format zu einer VM im VMware lesbaren Format

Sobald Sie die restlichen Dialoge durchlaufen haben, beginnt die Umwandlung der Festplattendateien und der Konfigurationsdatei. Sobald die Konvertierung abgeschlossen ist, finden Sie die Dateien im zuvor angegebenen Verzeichnis und können, falls ein VMware Produkt installiert ist, die virtuelle Maschine direkt aus dem VMware Virtual Machine Importer heraus starten.

Abbildung 17.16 Installation der VMware Tools!

Jetzt verbleibt noch eine Aufgabe, die Ihnen nicht vom Virtual Machine Importer abgenommen wird und direkt nach dem Starten der umgewandelten VM erledigt werden sollte: die Installation der VMware Tools. Nach deren Installation und einem Neustart ist die virtuelle Maschine betriebsbereit und kann ohne Abstriche verwendet werden. Es liegt in der Natur der Sache, dass dieses Tool nicht bei jeder Virtual PC/Server-VM funktioniert, im Normalfall sollte dies jedoch problemlos klappen.


Rheinwerk Computing - Zum Seitenanfang

17.1.3 Microsoft Virtual Server Migration Toolkit Zur nächsten ÜberschriftZur vorigen Überschrift

Microsoft bietet mit dem Virtual Server Migration Toolkit ein sehr mächtiges Hilfsmittel zur Migration von physikalischen und virtuellen Systemen in Virtual Server VMs an. Da zumindest die Software selbst kostenfrei ist, kann man dieses Tool durchaus als sehr interessant bezeichnen. Allerdings ist nicht alles Gold, was glänzt, denn es existieren nämlich auch gravierende Nachteile. Erstens ist die Installation sehr anspruchsvoll und erfordert ein gerüttelt Maß an Netzwerk- und Betriebssystemkenntnissen. Zweitens benötigen Sie einen Microsoft Windows 2003 Enterprise oder Datacenter Server, der mittels ADS (Automated Deployment Services) als PXE (Preboot Execution Environment System)-Dienst im Netzwerk auftaucht. Diese kostspielige Voraussetzung kann unter Umständen schon das K.o.-Kriterium sein. Des Weiteren kann es zu Problemen kommen, wenn man schon einen PXE-Dienst im Netzwerk hat, beispielsweise für anderweitige Softwareverteilung, denn nur ein aktiver PXE-Server darf in einem logischen Netzwerksegment vorhanden sein. Abhilfe würde hier nur ein VLAN oder ein Router schaffen. Darüber hinaus müssen die Clients, in unserem Fall die umzustellenden Serversysteme, Netzwerkkarten mit PXE Boot besitzen. Falls dies nicht so ist, muss der Server mittels Bootdiskette (mit PXE-Unterstützung) gestartet werden.

Zudem werden manche Betriebssysteme und Hardwarekomponenten bzw. Konfigurationen nicht unterstützt. Hierauf sollten Sie besonders vor der Installation von VSMT achten, können Sie sich doch so eine Menge Arbeit ersparen.

Unterstützte Betriebssysteme:

  • Windows NT 4.0 Server SP6a
  • Windows 2000 Server SP4
  • Windows 2000 Advanced Server SP4
  • Windows 2003, Standard Edition und Enterprise Edition

Nicht unterstützte Hardwarekomponenten:

  • USB und Firewire
  • nicht Ethernet-Netzwerkadapter
  • Parallelports (Dongle, Modem)
  • Bandlaufwerke

Nicht unterstützte Konfigurationen:

  • dynamische Festplatten
  • SAN-Verbindungen
  • erweiterte Partitionen

Vor der Nutzung müssen die Komponenten folgendermaßen installiert werden:

  1. Automated Deployment Services
  2. ADS Tools auf Virtual Server (falls unterschiedliche Systeme)
  3. VMTS Tools auf Virtual Server (falls unterschiedliche Systeme)

Erst in dieser Konstellation kann das Virtual Server Migration Toolkit überhaupt betrieben werden. Allerdings muss man zusätzlich noch unterscheiden, ob die ADS auf demselben Server wie der Virtual Server läuft. Falls alles auf einem Server läuft, müssen Sie die ADS und VSMT Programme »nur« immer komplett installieren. Zudem muss ein DHCP-Server im Netzwerk existieren, da die PXE Clients nur so eine gültige Netzwerkadresse erhalten.

Abbildung 17.17 Ansicht der VSMT-Umgebung zur Migration

In dieser Anleitung gehe ich von zwei getrennten Systemen aus, ADS wird später auf einem Windows 2003 Enterprise und der Virtual Server auf einem Windows 2003 Standard Server betrieben (Abbildung 17.17). Beide Systeme sind in der gleichen Arbeitsgruppe oder Domäne. Auf dem Windows 2003 Enterprise System läuft zudem ein DHCP-Server.

Automated Deployment Services (ADS) Installation

Die Microsoft ADS-Installationsdateien und Dokumentationen können Sie auf der offiziellen Webseite von Microsoft unter der URL http://www.microsoft.com/windowsserver2003/techinfo/overview/adsbenefits.mspx finden. Ein DHCP-Server sollte jetzt schon im Netzwerk vorhanden sein. Das Imageverzeichnis, nach dessen Pfad hier gefragt wird, sollten Sie auf eine Partition mit entsprechend viel freiem Festplattenplatz legen, weil es alle später zu erstellenden Images aufnehmen wird.

Abbildung 17.18 Installation einer MSDE oder Verwendung eines vorhanden Microsoft SQL Servers.

Sobald die Installationsroutine gestartet ist, werden Sie nach der Datenbank der ADS-Daten gefragt (Abbildung 17.18). Hier können Sie entweder eine kostenfreie MSDE installieren (wird mitgeliefert) oder einen im Netzwerk vorhandenen MS SQL Server nutzen. Falls schon eine ADS-Datenbank existiert, können Sie diese hier angeben. Darüber hinaus wird hier ein neues Zertifikat erstellt, das später vom Virtual Server genutzt werden muss, wenn er nicht auf dem ADS-Server betrieben wird.

Abbildung 17.19 Installation der ADS-Dienste

Im nächsten Installationsschritt (Abbildung 17.19) werden die zu installierenden Komponenten ausgewählt. Auf dem ADS-Server sollten Sie alle Komponenten installieren. Auf dem MS Virtual Server werden später lediglich die Tools installiert.

Abbildung 17.20 Hier wird der Pfad zu einem Windows 2003-Installationsmedium abgefragt. Er wird zur Erstellung des PXE Bootimages benötigt.

Nun müssen Sie noch Angaben zu dem Pfad eines Windows 2003-Installationsmediums machen, mit dem später das PXE Bootimage erstellt wird. Dieses PXE Bootimage wird einem PXE Client beim Starten übergeben und geladen. Zudem werden, wie in Abbildung 17.20 zu sehen, die DHCP-Einstellungen verändert, vorausgesetzt Sie haben den DHCP-Server schon installiert. Diese Einstellungen sind elementar, damit VSMT überhaupt funktionieren kann.

Abbildung 17.21 Mittels ADS Management SnapIns können Sie die Abläufe während der VSMT-Aktionen überwachen.

Sobald die Installation abgeschlossen ist, steht Ihnen der ADS-Server zur Verfügung. Verwalten können Sie ihn über das ADS Management MMC SnapIn. Hier kann später der Fortschritt jeder Aktion des VSMT nachvollzogen und es kann eingesehen werden, ob das Ganze von Erfolg gekrönt war oder nicht.

Abbildung 17.22 Treiberverzeichnis des ADS-Servers

Die mangelnde Treiberunterstützung kann schon unweigerlich zu Problemen bei der späteren Image-Erzeugung führen. Damit die Systeme über die ADS angesprochen werden können, werden die Festplattencontroller und Netzwerkkarten benötigt. Diese müssen in das Verzeichnis %Programfiles%\Microsoft ADS\nbs\repository\PreSystem kopiert werden. Zur Migration von VMware VMs sind diese Treiber, die Sie auf der VMware Tools CD (windows.iso im VMware Serververzeichnis) finden, ebenfalls erforderlich.

Abbildung 17.23 Installation der administrativen Tools auf dem Virtual Server

Falls Sie die beiden Server, ADS und Virtual Server, ebenfalls voneinander trennen, müssen Sie auf dem Virtual Server die ADS Administrative Tools installieren. Zur Installation dient die gleiche Installationsroutine wie beim eigentlichen ADS Server, nur dass wie in Abbildung 17.23 Administrative Tools only ausgewählt wird.

Abbildung 17.24 Installation des ADS-Serverzertifikates. Dies ist sehr wichtig, um die spätere Kommunikation zwischen Tools und Server sicherzustellen.

Jetzt müssen Sie das Serverzertifikat angeben, damit die Kommunikation zum Server überhaupt stattfinden kann. Dieses Zertifikat müssen Sie auf den Virtual Server kopieren und den Pfad, wie in Abbildung 17.24 beispielhaft gezeigt, hinterlegen. Zu finden ist es im ADS-Programmverzeichnis des ADS-Servers.

VSMT-Installation

Nachdem die grundlegenden Bedingungen des Virtual Server Migration Tools durch die Installation der ADS erfüllt sind, kommen wir nun zur eigentlichen Installation. Da zwei Server existieren, ADS Server und Virtual Server System, werden auch unterschiedliche Komponenten von VSMT benötigt.

Abbildung 17.25 Wie soll VSMT installiert werden? Ist dies ein Server oder ein Client?

Auf dem ADS-Server muss eine Vollinstallation des Toolkits durchgeführt werden, die alle Anpassungen der ADS und die benötigten Skripte beinhaltet (Abbildung 17.25). Sobald die Installation abgeschlossen ist, finden Sie alles Notwendige im Programmverzeichnis Microsoft VSMT.

Handhabung der VSM Tools

Innerhalb des VSMT-Programmverzeichnisses finden Sie nun die Dateien GatherHW.exe und VMscript.exe, die Sie zur Migration benötigen. Auf dem Quell-System (physikalische oder virtuelle Maschine) müssen Sie zuallererst die GatherHW.exe /f: pfad_Konfig.xml ausführen. Dadurch wird eine XML-Datei generiert, die den Host-Namen des Quellservers als Namen trägt. In der Datei stehen alle relevanten Informationen, die für die Migration benötigt werden. Daher sind am Client selbst keine weitere Änderung mehr notwendig. Die XML-Datei muss aber zur späteren Weiterverwendung auf den VSMT Server kopiert werden.

Über den Befehl VMscript.exe –hwvalidate –hwinfofile:Quellserver.xml wird der Inhalt der XML-Datei, sprich die Konfiguration des Quell-Systems, überprüft. Falls hier keine Inkompatibilitäten auftreten, sind Sie auf der sicheren Seite. Danach müssen die eigentlichen Migrations-Skripte erstellt werden. Dies geschieht ebenfalls über den VMscript-Befehl, allerdings mit ein paar Parametern mehr (Abbildung 17.26).

Abbildung 17.26 Ausgabe des Vmscript-Befehls zur Generierung der rechnerspezifischen Skript-Dateien.


Tabelle 17.2 Parameter der VMscript.exe

Parameter Erklärung

-hwgeneratep2v oder –p2v

Erstellung der P2V Skripte

-hwinfofile:Quellserver.xml

Konfigurationsdatei, die durch GatherHW.exe erstellt wurde

-name:Name_der_VM

Wie soll die virtuelle Maschine später benannt werden?

-vmconfigpath:Pfad_vmc_Datei

Pfad zur späteren .vmc-Konfigurationsdatei

-virtualDiskPath:Pfad_vhd_Datei

Pfad zur späteren Festplattendatei

-hwdestvs:Virtualserver.local

FQDN des Virtual Servers


Die Parameter vmconfigpath und virtualDiskPath sind von besonderer Bedeutung, da dort die späteren VM-Dateien abgelegt werden. Daher müssen diese vor dem Migrationslauf durch das DeployVM-Skript existieren. Die Pfade müssen aus der Perspektive des Virtual Servers angegeben werden, z. B. d:\virtual_machines\VM1.

Abbildung 17.27 Migrations-Skripte im Verzeichnis des entsprechenden Quell-Systems

Sobald der Vmscript-Befehl erfolgreich ausgeführt wurde, existiert im Programmverzeichnis von den VSMTools ein Verzeichnis P2V und darin ein Unterverzeichnis mit dem Namen des Quell-Systems. Darin befinden sich die eigentlichen Skripte, die zur Migration des Serversystems genutzt werden (Abbildung 17.27).

Abbildung 17.28 Nach Aufruf des Capture-Skripts bleibt das Programm bis zur Erstellung des Images offen.

Um das Image überhaupt einmal zu erstellen, muss man nun nichts weiter machen, als die Datei Quellserver_capture.cmd auszuführen. Die daraufhin erscheinende Eingabeaufforderung konfiguriert den ADS-Dienst, d. h., die Imageerzeugung wird gestartet, sobald sich das Quell-System über den PXE-Dienst mit seiner MAC-Adresse meldet. Daher muss jetzt, ohne das Programmfenster zu schließen, der Quellrechner mit PXE gestartet werden. Sobald sich das Quell-System nun mit dem PXE-Service verbindet, können Sie den Ablauf mit dem ADS Management Snapin verfolgen. Nach dem erfolgreichen Erstellen des Systemimages, können Sie die restlichen Kommandozeilenskripte in folgender Reihenfolge aufrufen, um die Migration abzuschließen:


Tabelle 17.3 Reihenfolge der Skripte zur Migration

Skript Aktionen

_capture.cmd

Erstellung der Festplattenimages

_CreateVM.cmd

Erstellung der Konfigurationsdatei (.vmc) der virtuellen Maschine

Erstellung der virtuellen Netzwerke

Erstellung des SCSI Kontrollers

Erstellung der Festplattendateien (.vhd)

Hinzufügen der Festplattendateien zur virtuellen Maschine

legt das RIS2003.vfd-Diskettenimage (PXE Boot) in das virtuelle Diskettenlaufwerk

konfiguriert die virtuelle Netzwerkkarte in das virtuelle Netzwerk

konfiguriert ADS-Server, damit die neu erstellte virtuelle Maschine das entsprechende Bootimage und damit das vorher erstellte Festplattenimage erhält

_DeployVM.cmd

Anschalten der virtuellen Maschine

Zurückschreiben der Festplattenimages auf die jeweiligen Festplattendateien (.vhd)


Wenn das letzte Skript namens DeployVM.cmd erfolgreich ausgeführt wurde, ist die Quellmaschine komplett in die virtuelle Maschine migriert. Den kompletten Ablauf müssten Sie auch jetzt in der zu Anfang gezeigten Abbildung 17.17 wieder erkennen. Falls Sie möchten, können Sie die entstandene virtuelle Maschine mit dem VMware Virtual Machine Importer in ein VMware-kompatible Maschine konvertieren. Dem Spieltrieb wären hier keine Grenzen gesetzt.


Rheinwerk Computing - Zum Seitenanfang

17.1.4 Platespin PowerP2V Zur nächsten ÜberschriftZur vorigen Überschrift

Platespin liefert mit dem PowerP2V-Produkt ein sehr mächtiges und leicht zu bedienendes Werkzeug zur Migration von physikalischen und virtuellen Maschinen. Wie die beiden Tools VMware P2V und Microsoft VSMT bedient sich auch PowerP2V eines Image-Verfahrens. Bei der Migration kann man sich zwischen einer direkten Migration und einer Image-Erstellung vom Quell-System entscheiden. Im Falle der Image-Erstellung wird dieses Image auf einem Image Server, der zuvor angegeben werden muss, abgelegt und kann danach beliebig oft verwendet werden. Es können beliebig viele und verschiedene Images hinterlegt und Image Server angelegt werden. Bei jeder Erstellung einer neuen VM basierend auf einem Image, können die spezifischen Einstellung des Ziel-Systems granular hinterlegt werden, womit die entstehende virtuelle Maschine direkt nutzbar ist. In zukünftigen Versionen soll diese Funktion dahingehend erweitert werden, dass man aus den Images auch physikalische Maschinen aufsetzen kann. Damit wären auch die Verfahren P2P und V2P möglich, die momentan von keinem Produkt unterstützt werden. Die komplette Migration läuft zum großen Teil vollautomatisch über eine grafische Oberfläche ab, die intuitiv zu bedienen ist. Die Hardwareunterstützung durch PowerP2V ist umfassend und kann auf der Webseite des Herstellers in einer ständig aktualisierten Liste nachgelesen werden.

Funktionsumfang von Platespin PowerP2V

  • Migration von Windows- und Linux-Systemen (derzeit nur RedHat) in VMware ESX Server, VMware GXS Server und Microsoft Virtual Server 2005 VMs
  • Physical-to-Virtual(P2V)-Konvertierung
  • Virtual-to-Virtual(V2V)-Konvertierung
  • Physical-to-Image(P2I)- und Image-to-Virtual(I2V)-Konvertierung
  • automatische und einfache Erfassung und Inventarisierung von physikalischen und virtuellen Systemen
  • keine Agenteninstallation notwendig
  • kein PXE Boot notwendig
  • keine Boot-CD oder -Diskette notwendig
  • detaillierte Aktionsverfolgung und Protokollierung
  • direkte Migration des physikalischen System in ein virtuelles möglich

Die Installation des PowerP2V Servers gestaltet sich im Vergleich zu VSMT erfreulich einfach. Es werden bei weitem nicht so tiefe Netzwerk- und Betriebssystemkenntnisse wie in der Microsoft-Lösung verlangt. In Tabelle 17.4 können Sie die Systemvoraussetzungen vom Server und Client einsehen, Tabelle 17.5 zeigt Ihnen die unterstützten Systeme.


Tabelle 17.4 Systemvoraussetzungen Platespin PowerP2V

PowerP2V Client PowerP2V Server

.NET Framework 1.1 SP 1

  • Windows 2000 Server
  • Windows 2000 Advanced Server
  • Windows 2003 Server
  • Internet Information Server 5
  • .Net Framework 1.1 SP1 (ASP)

ca. 1 GB Festplattenplatz

512 MB Hauptspeicher

MSDE (wird automatisch installiert)

VMware GSX Server VmCOM API, falls GSX Server verwaltet werden

DHCP-Server ist empfehlenswert, da bei der Migration temporär IP-Adressen benötigt werden.



Tabelle 17.5 Unterstützte Systeme

Komponente Voraussetzung

Hardware

  • CPU: x86 166 MHz oder höher
  • 128 MB Hauptspeicher
  • 280 MB Festplattenspeicher (Windows Systempartition)

Betriebssystem Quell-System

  • Windows NT 4 Server
  • Windows 2000 Server
  • Windows 2000 Advanced Server
  • Windows 2003 Standard
  • Windows 2003 Enterprise
  • Windows 2003 Datacenter
  • Windows NT 4 Workstation
  • Windows 2000 Professional
  • Windows XP Home
  • Windows XP Professional
  • Linux RedHat
  • RedHat Linux AS
  • RedHat Linux ES
  • SLES 8
  • SLES 9

Virtualisierungsprodukt

  • VMware ESX Server
  • VMware GSX Server
  • Microsoft Virtual Server
  • Microsoft Virtual PC

Aufgrund der Möglichkeit eines abgesetzten Image Servers ist eine sehr gute Unterstützung für Außenstellen gegeben. Da die meisten Unternehmen auch zwischen Zentrale und Außenstelle eine Firewall betreiben, ist gerade für dieses Produkt die Auflistung der benötigten TCP/IP-Ports sinnvoll (Tabelle 17.6).


Tabelle 17.6 Von PowerP2V verwendete Ports

Port Verwendung

22 (TCP, SSH)

Auslesen der Linux- und VMware ESX-Maschinen

80 (TCP)

Kommunikation zwischen PowerP2V Server und Quell-/Ziel-System

135/445 (TCP)

DCOM/RPC wird zum automatischen Auslesen von Windows-Maschinen über WMI verwendet.

> 1024

Kann u. U. während des Ausleseprozesses der Windows-Konfigurationen durch WMI benötigt werden.

3725 (TCP)

Dateitransfer zwischen Quell- und Ziel-System


Da PowerP2V mit dem Microsoft IIS Webserver arbeitet, müssen Sie den PowerP2V Server entweder auf einem Windows 2000 oder Windows 2003 Server mit installiertem IIS und aktiviertem ASP .Net installieren. Über den Webserver werden später sowohl der PowerP2V Client als auch die Web Services angeboten, über die der Client mit dem Server kommuniziert.

Abbildung 17.29 Webseite des PowerP2V Servers. Hier können Sie den eigentlichen Client herunterladen.

Nach der Installation des PowerP2V Servers, können Sie auf die Webseite des Servers über die URL http://localhost/PowerP2V wechseln und sich den PowerP2V Client herunterladen und installieren. Mit diesem Client wird der komplette PowerP2V Server verwaltet (Abbildung 17.29), es sind demnach keinerlei sonstige Tools notwendig.

Abbildung 17.30 Zum ersten Mal im PowerP2V Client

Sobald Sie den Client gestartet und die Lizenzen eingetragen haben, befinden Sie sich im Management des PowerP2V Servers, das naturgemäß erst einmal leer ist. Dies ändert sich jedoch sehr schnell, da der Server, ständig das Netzwerk nach neuen Systemen absucht und in den entsprechenden Gruppen Source oder Destination einträgt. Die Entscheidung, ob ein System nur als Quell- oder auch als Ziel-System erkannt wird, hängt von der Art der Hardware ab. Physikalische und direkt verbundene virtuelle Systeme können derzeit nur als Quell-Systeme dienen, virtuelle Maschine, die über den Virtualisierungsserver verbunden werden, hingegen sowohl als auch.

Abbildung 17.31 Hinzufügen neuer Systeme

Falls Sie Ihr System nicht in der Oberfläche wiederfinden, können Sie es einfach mit Discover Server Details (rechte Maustaste in das Source- oder Destination-Fenster) hinzufügen (Abbildung 17.31). Nach dem Aufruf erscheint ein Dialogfenster, in dem Sie Angaben zur Netzwerkadresse, zum Betriebssystem (Windows oder Linux) und zu einem Administratorprofil machen müssen. Die Benutzerangaben können Sie entweder verschlüsselt für die einzelnen Server hinterlegen, oder aber Sie werden bei jeder Neuabfrage des Systems erneut nach Benutzernamen und Kennwort gefragt.

Abbildung 17.32 Auslesen der notwendigen Daten des Systems

Nach einem Klick auf Discover wird der Prozess zur Datenerfassung des Systems gestartet (Abbildung 17.32). Die Datenerfassung selbst betrifft sämtliche Angaben des Systems, angefangen beim Betriebssystem über die Festplattenpartitionen bis hin zu den Netzwerkeinstellungen (Abbildung 17.33). Sobald dieser Prozess abgeschlossen ist, steht der Server zur weiteren Verwendung bereit. Gerade dieser Discovery-Prozess ist ein Kernstück von PowerP2V, weil durch die durchgängige Datenerfassung alle weiteren Funktionen erst realisierbar werden.

Beispiel:

Angenommen Sie hätten eine virtuelle Maschine, die Sie zu einem Image Server machen möchten. Diese wurde auch schon vor einiger Zeit von PowerP2V erfasst und enthält eine Festplatte. Da die Images recht groß sind, entscheiden Sie sich dafür, eine weitere große Festplatte der VM bereitzustellen. Damit diese nun von PowerP2V verwendet werden kann, müssen Sie erst das System im Inventar auf den neuesten Stand bringen (refreshen).

Abbildung 17.33 Eigenschaften eines erfassten Systems. Diese Eigenschaften müssen zum reibungslosen Migrieren immer aktualisiert werden.

Abbildung 17.34 Eine in PowerP2V erfasste Infrastuktur

Sobald alle benötigten Maschinen integriert sind, könnte eine kleine Infrastruktur so wie in Abbildung 17.34 aussehen. Auf der linken Seite stehen bei den Quellservern auch die physikalischen Systeme, während auf der rechten Seite ausschließlich virtuelle Maschinen zu finden sind. Übrigens werden mit der Integration eines VMware GSX/ESX oder Microsoft Virtual Server automatisch alle darauf laufenden virtuellen Maschinen direkt übernommen und integriert, wenn sie denn zuvor inventarisiert (discover) worden sind.

Abbildung 17.35 Kontextmenü bei einem vollständig erfassten Quell-System

Wenn Sie nun mit der rechten Maustaste das Kontextmenü eines inventarisierten Systems aufrufen, erhalten Sie eine Ansicht wie die in Abbildung 17.35. Sie könnten schon jetzt eine Migration in eine andere virtuelle Maschine anstoßen oder die Maschine in ein Image umwandeln. Vorher muss jedoch erst ein Image Server installiert sein, was wir mit der Auswahl Install Image Server auch direkt machen können. Es können, wie bereits erwähnt, beliebig viele Image Server mit beliebig vielen Images installiert und genutzt werden. Die Installation des Image Servers läuft wie alles in PowerP2V ohne einen weiteren Eingriff des Administrators ab (allerdings werden Sie vorher noch nach dem Verzeichnis für die Images auf dem Image Server gefragt). Einzige Voraussetzung ist immer die Hinterlegung eines administrativen Benutzers pro System.

Sobald der Image Server installiert ist, können Sie auch schon das erste System in ein Image umwandeln. Dazu müssen Sie im Kontextmenü des Quell-Systems (Abbildung 17.35) Convert to Image auswählen. Danach werden Sie nach dem Image Server zur Konvertierung gefragt (Abbildung 17.36). Ein sehr wichtiger Punkt hierbei ist, dass nur Steuerinformationen zwischen PowerP2V Server und Image Server bzw. Quell-System ausgetauscht werden. Die Daten beim Erstellen des Images fließen nur zwischen Image Server und Quell-System. Dadurch ist es möglich, in entfernten Standorten beispielsweise über WAN-Verbindungen eine Image-Erzeugung anzustoßen, ohne dabei die Leitung mit den eigentlichen Daten zu belasten.

Abbildung 17.36 Konvertierung eines Systems in ein Image auf dem entsprechenden Image Server

Abbildung 17.37 Konvertierungseinstellungen bei der Image-Erstellung

Wenn der Image Server ausgewählt ist, meldet sich der Assistent zur Image-Erstellung (Abbildung 17.37). Hier können Sie die Job-Konfiguration anpassen, indem Sie die administrativen Benutzerinformationen beider Systeme angeben oder die Erstellung per Scheduler zeitlich beeinflussen. Darüber hinaus können Sie hier unter Volumes die Partitionen auswählen, die in ein Image übernommen werden sollen. Sobald Sie die Image-Erzeugung aktivieren, wird das Quell-System vollautomatisch konfiguriert und danach heruntergefahren (falls gewünscht).

Abbildung 17.38 Installationsprotokoll bei der Erstellung des Images

Die Umwandlung selbst können Sie jederzeit in der Jobs-Ansicht (linke Seite) Schritt für Schritt verfolgen (Abbildung 17.38). Die Aufteilung der Gesamtaktion in kleinere Teilschritte erleichtert die Fehlersuche erheblich. Falls Fehler auftreten, kann man anhand der Step-Nummer auch sehr gut in der Platespin Knowledge Base nach Fehlern suchen.

Abbildung 17.39 Übersicht über alle Images auf einem Image Server

Unter jedem Image Server sehen Sie nun im Inventar die Images, die auf ihm vorhanden sind. Per Drag&Drop können die Images problemlos zwischen mehreren Image Servern verschoben werden. Sobald Sie das Kontextmenü eines Images aufrufen, können Sie das Image entweder löschen oder daraus eine neue virtuelle Maschine erstellen.

Abbildung 17.40 Assistent zur Erstellung einer neuen virtuellen Maschine mittels Image

Sobald eine Neuerstellung angestoßen wurde, erscheint ein Assistent, mit dem alle relevanten Einstellungen gemacht werden können. In Abbildung 17.40 sehen Sie diesen Assistenten bei der Neuerstellung einer VM auf einem VMware ESX Servers. Über die entsprechenden Links können Sie direkt zu den mit einer Warnung oder einem Fehler gekennzeichneten Sektionen wechseln. Diese Einstellungen werden variabel je nach Ziel-System angepasst. Als Ziel-System können virtuelle Maschinen auf VMware GSX/ESX Server und MS Virtual Server dienen.

Folgende Einstellungen können beispielsweise im VMware ESX Server gemacht werden (Quellserver ist eine Windows 2003-Maschine):

  • Name der virtuellen Maschine
  • Pfad der Konfigurationsdatei
  • Hauptspeicherzuordnung
  • Installation der VMware Tools
  • Netzwerkeinstellungen pro virtueller Netzwerkadapter
  • zugeordneter virtueller Netzwerkswitch (wird aktuell aus dem Virtualisierungsprodukt ausgelesen)
  • Ressourcenbeschränkungen
  • Generierung einer neuen SID
  • Mitgliedschaft in Arbeitsgruppe oder Domäne
  • endgültige Größe der einzelnen Festplattenpartitionen
  • Neuerstellung zusätzlicher Festplattendateien
  • Ablageort der Festplattendateien

Wie Sie sehen, wurde eigentlich an alles gedacht. Wegen dieser Vielzahl an konfigurierbaren Einstellungen der endgültigen virtuellen Maschine ist dieses Produkt sehr gut für den professionellen Einsatz auch in großen Umgebungen geeignet. Für Test- und Entwicklungsabteilungen ist dieses Tool geradezu prädestiniert, können doch ganze IT-Strukturen überaus schnell erstellt werden.

Stellen Sie sich eine Infrastruktur mit 20 virtuellen Maschinen vor, die zur Evaluierung einer Software genutzt werden. Weil diese VMs ständigen Veränderungen unterliegen und sehr schnell wieder in den Ursprungszustand zurückversetzt werden müssen, ist eine manuelle Neuinstallation ausgeschlossen. Hier könnte man mit PowerP2V alle Systeme imagen und auf einen Schlag komplett wiederherstellen. Dies könnte man zwar auch über das VirtualCenter realisieren, aber bei weitem nicht so komfortabel und nicht über VMware-Grenzen hinweg. Falls Platespin die Ankündigung zur Wiederherstellung physikalischer Maschinen aus einem Image realisiert, was laut Sales Departement sehr bald der Fall sein wird, wird dieses Produkt nicht nur im virtuellen Umfeld seine Vorteile ausspielen können.

Durch das Image-Verfahren kann zudem ein Disaster Recovery problemlos und schnell realisiert werden. Dieses Produkt setzt sich insofern von der Konkurrenz ab, als dass mit einer Oberfläche alle notwendigen Aktionen getätigt werden können, ohne dabei einen Administrator vor Ort bemühen zu müssen.

Bei all dem Lob sollte auch ganz klar sein, dass es immer Konstellationen geben wird, die das Produkt nicht migrieren bzw. abdecken kann. Daher sollten Sie sich vor der Anschaffung genau über die Kompatibilät mit Ihrer Infrastruktur informieren und sich mittels einer Testversion ein Look&Feel verschaffen.


Rheinwerk Computing - Zum Seitenanfang

17.1.5 Leostream P>V Direct topZur vorigen Überschrift

Leostream hat mit dem Produkt P>V Direct ein Werkzeug auf den Markt gebracht, mit dem eine automatisierte Migration eines Windows-basierten physikalischen Systems direkt in eine virtuelle Maschine möglich ist. Auf Boot-CD, Diskette oder Netzwerkboot wird ähnlich wie beim Platespin-Konkurrenten komplett verzichtet. Das Quell-System muss während des Migrationsprozesses nicht neu gestartet oder heruntergefahren werden, was schon für sich genommen ein Alleinstellungsmerkmal ist. Um dies zu bewerkstelligen, besteht das P>V Direct-Produkt aus drei Komponenten: einem Wizard, der auf dem Quell-System installiert wird, einem Host-Agenten auf dem Wirt-System und einem Converter in der virtuellen Maschine (Abbildung 17.41). Der Wizard des Quell-Systems kopiert in einem späteren Schritt dann alle Daten einer Festplatte auf Blockebene in die virtuelle Maschine. Offensichtlicher Nachteil dieser Methode ist es, dass die entstehende virtuelle Maschine in einem Zustand vorliegt, der dem nach einem Absturz ähnelt (harter Ausfall – z. B. nach Stromausfall). Zudem wird hier das System 1: 1 mit gleichem Computernamen, gleicher Netzwerkkonfiguration und gleicher SID migriert. Daher sollte die VM entweder direkt in einem Host-Only-Netzwerk gestartet oder das Quell-System nach der Migration abgeschaltet werden. In Tabelle 17.6 können Sie die unterstützten Betriebssysteme und Virtualisierungsprodukte nachlesen.


Tabelle 17.7 Unterstützte Betriebssysteme (Virtualisierungsprodukte)

P>V Direct Komponente unterstützte Produkte

Virtualisierungsprodukt

  • Microsoft Virtual Server 2005
  • Microsoft Virtual Server 2005 SP1
  • VMware GSX Server for Windows v3.1
  • VMware Workstation 4.5
  • VMware ESX Server v2.5

Quell-System

P>V Wizard

  • Windows NT 4 Workstation
  • Windows NT4 Server
  • Windows 2000 Professional
  • Windows 2000 Server
  • Windows 2000 Advanced Server
  • Windows XP
  • Windows 2003 Standard
  • Windows 2003 Enterprise
  • Windows 2003 Datacenter

Windows Host Agent

  • Windows XP
  • Windows 2003 Standard
  • Windows 2003 Enterprise
  • Windows 2003 Datacenter

Linux Host Agent

VMware ESX 2.5

Abbildung 17.41 Aubau der Leostream P>V Direct-Komponenten

Damit P>V Direct überhaupt funktionieren kann, sind erst einmal einige Vorbereitungen zu treffen. Auf dem Wirt-System, das die spätere virtuelle Maschine beherbergen soll, muss der Host-Agent installiert werden. Dieser stellt sich unter Windows als normale Setuproutine und unter VMware ESX als RPM-Datei dar, integriert sich als Dienst in das jeweilige Betriebssystem und steuert später die Erstellung und Konfiguration der zukünftigen VM.

Abbildung 17.42 Generierung des Lizenzschlüssels auf der Leostream-Webseite

Der nächste Schritt ist die Konfiguration des P>V Wizards auf dem physikalischen Quell-System. Sobald dieser Wizard startet, wird eine eindeutige Seriennummer für diesen Rechner generiert und nach einem Lizenzschlüssel gefragt. Mit der Seriennummer müssen Sie nun auf der Leostream-Webseite, wie in Abbildung 17.42 zu sehen, den Lizenzschlüssel erzeugen.

Abbildung 17.43 Partitionen und Hauptspeichergrößen des Ziel-Systems (virtuelle Maschine)

Im darauf folgenden Dialog müssen Sie die Netzwerkadresse des Wirt-Systems, auf dem der Host-Agent läuft, angeben. Falls der Wizard erfolgreich Kontakt zu dem Host-Agenten aufbauen konnte, wird zum Dialog in Abbildung 17.43 gewechselt, der schon die Partitions und Hauptspeicherangaben für das Ziel-System betrifft. Nach dieser Auswahl werden Sie direkt nach den Einstellungen der Netzwerkkarte und deren Zuordnung zum entsprechenden virtuellen Netzwerk gefragt. Hier können Sie auch mehrere virtuelle Netzwerkkarten erstellen lassen. Da die Hardwarekonfiguration der virtuellen Maschine problemlos zu einem späteren Zeitpunkt konfiguriert werden kann, rate ich allerdings in diesem Dialog von einer Erstellung mehrerer Netzwerke ab.

Als Nächstes wird über die Art der Datenübertragung entschieden, wobei die Option Leostream Direct die Standardauswahl ist. Dies ist auch die einzige Auswahl, mit der das Quell-System ohne Neustart migriert werden kann. Falls es mit dieser Methode zu Problemen kommen sollte, können Sie den Wizard einfach nochmals mit einer anderen Auswahl starten. Zur Auswahl stehen Ihnen dann die Tools von Drittanbietern wie Acronis True Image und Symantec (Ghost) oder Leostream Advanced. Letzteres benötigt drei Bootdisketten und bietet eine Abwärtskompatibilität zu früheren Versionen. Mit der Option Other wird eine eingelegte Diskette in ein Diskettenimage kopiert und bei der Ziel-VM »eingelegt«. Vorteil an den anderen Auswahlpunkten ist, dass das Quell-System zum Zeitpunkt der Datenmigration abgeschaltet ist und daher nicht in dem Zustand ist wie bei der Online-Migration (geringere Wahrscheinlichkeit für Datenkorruption).

Abbildung 17.44 Wie soll die Datenmigration erfolgen?

Abbildung 17.45 Die Ziel – VM wartet auf die Daten vom Wizard

Nachdem der letzte Dialog mit der Frage nach der temporären Netzwerkadresse zur Migration beantwortet wurde, wird die virtuelle Maschine auf dem Wirt-System erstellt, konfiguriert (Netzwerk, Leostream Diskettenimage) und gestartet. Wenn hier keine Netzwerkadresse eingetragen wird, muss die VM manuell bedient werden, ansonsten startet die virtuelle Maschine automatisch im Modus zum Datenempfang (Abbildung 17.45).

Auf beiden Systemen können Sie nun den Fortschritt der Datenübertragung nachvollziehen (Abbildung 17.46). Sobald der Datentransfer beendet ist, bekommen Sie eine Meldung auf dem Quell-System, und die Ziel-VM wird automatisch neu gestartet. Weil es sich um eine 1:1-Kopie handelt, sollten Sie es vermeiden, beide Systeme gleichzeitig im Netzwerk zu betreiben. Die Migration ist zu diesem Zeitpunkt allerdings erfolgreich abgeschlossen.

Abbildung 17.46 Fortschrittsanzeige der Datenübertragung



Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück
  Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Vmware und Microsoft Virtual Server
Vmware und Microsoft Virtual Server


 Ihre Meinung?
Wie hat Ihnen das Openbook gefallen?
Ihre Meinung

 Buchtipps
Zum Rheinwerk-Shop: Vmware vSphere 5.5






 Vmware vSphere 5.5


Zum Rheinwerk-Shop: Vmware vSphere 5.5






 Vmware vSphere 5.5


Zum Rheinwerk-Shop: Vmware View






 Vmware View


Zum Rheinwerk-Shop: Microsoft Hyper-V






 Microsoft Hyper-V


Zum Rheinwerk-Shop: Office 365






 Office 365


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2005
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern