Unwirkliche Welten

www.vmaschinen.de
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 - Teil2
Physical to Virtual mit VMware – Teil2
Im Teil1 wurde die grundlegende Vorgehensweise erläutert, um eine
physische Maschine in eine VM zu klonen. Viele Anwender waren mit
Teil1 bereits erfolgreich. Für den Rest geht es im Teil2 ans
Eingemachte – die Behebung aller Fehler und Ursachen vieler
Bluescreens!
Hinweis: Dieses PDF-Dokument enthält Lesezeichen als Inhaltsverzeichnis!
Solche netten Überraschungen lauern bei einer Virtualisierung an einigen Ecken!
C’t-Artikel 24-2005, S. 208 „Seelenwanderung“
Als Ergänzung möchte ich auf meinen oben genannten Artikel in der
Zeitschrift C’t hinweisen. Er beschreibt ebenfalls die Vorgehensweise einer
Migration in eine VM. Schwerpunkt ist das Tool BartPE und es gibt einen
kleinen Zusatz zum Dual-Boot zwischen Hardware und VM.
Ergänzungen zum Teil1 des Workshops
Quellsystem liegt auf SCSI oder SAN
Gleich nach dem Erscheinen von Teil1 tauchte folgende Frage am
häufigsten auf: Was ist, wenn mein Quellsystem auf SCSI-Platten bzw. auf
einem RAID-Array liegt oder gar vom SAN bootet?
Das ist völlig egal! Die Anleitung aus Teil1 funktioniert auch dann. Die ZielVM bootet nach dem Zurückspielen des Images ohne Probleme von der
neuen IDE-Platte, wenn vorher im Quellsystem der Standard-IDE-Treiber
installiert wurde. Alte RAID- oder SCSI-Treiber können im Gerätemanager
der Ziel-VM später entfernt werden. Alle auftauchenden Probleme (sh.
unten) haben nichts mit der Art der Quellplatte zu tun!
Klonen auf eine virtuelle SCSI-Platte
Um das System direkt auf eine SCSI-Platte zu Klonen (z.B. ESX-Server),
ist einiges mehr zu beachten, als beim einfachen Weg über den Standard-
1
Copyright 2005 Sven Ahnert - www.vmaschinen.de
www.vmaschinen.de
Physical to Virtual mit VMware - Teil2
IDE-Treiber. Eine detaillierte Beschreibung zu den SCSI-Treibern unter
VMware finden Sie hier:
http://www.vmaschinen.de/cgi-bin/vmware.cgi?scsi
Image erstellen und zurückspielen mit einer BartPE-CD
Wer lieber mit einer BartPE-CD oder ähnlichem bootet, kann sich die
Wartungs-VM sparen. In die neu erstellte Ziel-Maschine wird dann einfach
ein ISO-Image der CD eingebunden. Wenn die Boot-CD auch
Netzwerkunterstützung bietet, kann das Image der Quellmaschine auf dem
Host abgelegt und von dort in die VM zurückgespielt werden. Auch ein
direktes Überspielen ist mit einigen Tools möglich.
virtuelle Ziel-Platte mit VMware-Disk-Mount
Die virtuelle Ziel-Platte kann auch am Host, völlig ohne VM gemountet
werden. So lässt sich z.B. die Boot.ini bearbeiten, die Registry editieren
oder die HAL ersetzen:
http://www.vmaschinen.de/download/vm_mount.pdf
Viele Wege führen nach Rom!
Fehler beim ersten Startvorgang der VM
Nun aber zu den Fehlern, die bei einer Virtualisierung lauern. Für die
häufigsten Probleme finden Sie hier eine Lösung.
Ziel-VM bootet nicht (keine aktive Partition)
Wenn das Zielsystem nach dem Klonvorgang nicht bootet, dann liegt das
im einfachsten Falle daran, dass die Partition nicht auf „aktiv“ gesetzt
wurde. Vor allem das in Teil1 vorgestellte DriveSnapshot aktiviert
Partitionen nicht automatisch! Am einfachsten geht das Aktivieren direkt in
der Datenträgerverwaltung der Hilfs-VM.
Ziel-VM bootet nicht (fehlender MBR)
Wurde die neue leere Zielplatte in der Datenträgerverwaltung nicht mit
einer Signatur versehen (letztendlich nichts weiter als der Master-BootRecord), dann kann von dieser Platte nicht gebootet werden.
2
Copyright 2005 Sven Ahnert - www.vmaschinen.de
www.vmaschinen.de
Physical to Virtual mit VMware - Teil2
Nachträglich lässt sich z.B. mit der Windows-CD booten. In der
Wiederherstellungskonsole ("R" wie Recovery) dann folgende
Kommandos eingeben:
C:>fixmbr /Device/Harddisk0
(fixboot oder fixmbr)
Ziel-VM bootet nicht (CHS-Geometrie)
Beim ersten Boot-Versuch der Ziel-VM erscheinen Fehler, wie "Ntldr is
missing", "A disk read error occurred" oder nur ein blinkender Cursor auf
einem schwarzen Bildschirm.
Ursache ist eine andere Plattengeometrie der Zielplatte. Da Windows
(immer noch!) den Einsprungpunkt seines Bootloaders direkt per CHS
angibt, wird eine falsche Stelle angesprungen, wenn die neue Platte
andere Geometriedaten liefert. Der Fehler taucht vor allem bei bestimmten
Quellplatten (IBM...) oder Raid-Systemen auf.
Mit dem Tool "Testdisk" kann der richtige Wert ermittelt und korrekt
geschrieben werden. Dazu ist die Ziel-Platte nochmals in die Hilfs-VM
umzuhängen.
http://www.cgsecurity.org/index.html?testdisk.html
Boot.ini anpassen
Wenn im Quellsystem die Systempartition nicht die erste Partition auf der
Platte war, dann führt das ebenfalls zu einem Bluescreen in der Ziel-VM.
Markengeräte der Serverhersteller haben z.B. oftmals eine kleine
Wartungspartition an erster Stelle, welche beim Klonvorgang nicht mit
kopiert wurde.
Nach dem Klonen ist die boot.ini auf der Ziel-Platte zu editieren. Da wir
eine separate Platte (disk0) mit nur einer Partition (partition1) als System
verwenden, sollte die Boot.ini etwa so aussehen:
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINNT
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows 2000 Server" /fastdetect
Achtung! Beachten Sie die Zählweise! Platten beginnen bei Nummer 0,
Partitionen bei Nummer 1!
Alte Treiber verursachen einen Bluescreen
Manchmal verursachen alte Treiber oder DLLs beim Start der Ziel-VM
einen Bluescreen.
3
Copyright 2005 Sven Ahnert - www.vmaschinen.de
www.vmaschinen.de
Physical to Virtual mit VMware - Teil2
Die fehlerhafte Treiber-Datei der Bluesreen-Meldung wird am besten
einfach umbenannt. Dazu die Platte wieder einmal in die Hilfs-VM
einhängen. Die VM müsste nach dem Entschärfen des Treibers oder der
DLL starten und der Treiber oder die Anwendung kann bei laufender VM
dann sauber deinstalliert werden.
Tipp: Sollte die Fehlermeldung zu schnell verschwinden, um den
Treibernamen zu lesen, kann unter Workstation oder GSX der Bluescreen
mittels Suspend eingefroren werden. Dann lässt sich im Verzeichnis der
VM die *.png-Datei mit einem Bildbetrachter öffnen.
Die Quelle ist ein Multiprozessor-System
Wenn die fertig geklonte Ziel-VM eine hohe CPU-Last des Hosts
verursacht, obwohl in der VM keinerlei Last im Task-Manager zu sehen ist,
dann war die Quelle wahrscheinlich ein Multiprozessor-System. Nur beim
ESX-Server mit Virtual SMP machen MPS-VMs keine Probleme. Aber
auch beim ESX ist es nicht sinnvoll, alle Maschinen mit SMP zu betreiben,
weswegen ein Downgrade nützlich sein kann.
Ein Multiprozessor-PC kann ab Windows2000 nach dem Klonen einfach in
einen Single-CPU-PC geändert werden über den Gerätemanager >
Computer. Wichtig ist hier, innerhalb der Klasse zu bleiben. Ein Wechsel
zwischen ACPI oder Nicht-ACPI führt bei dieser Methode zu einem
Bluscreen!
vorher: "ACPI Multiprocessor PC"
danach: "Advanced Configuration and Power Interface (ACPI) PC"
NICHT!: "ACPI Uniprocessor PC"
Oder:
vorher: "MPS Multiprocessor PC"
danach: "Standard PC"
NICHT!: "MPS Uniprocessor PC"
Achtung! "ACPI Uniprocessor PC", bzw. "MPS Uniprocessor PC"
adressieren ein Dual-Board mit nur einer CPU bestückt. Das wäre in einer
VM auch falsch!
4
Copyright 2005 Sven Ahnert - www.vmaschinen.de
www.vmaschinen.de
Physical to Virtual mit VMware - Teil2
Multiprozessor-Systeme unter NT4
Unter NT4 funktioniert der Wechsel von Multi- zu Single-CPU nur durch
direktes Ersetzen der HAL. Starten lässt sich NT mit Multiprozessor-HAL in
einer normalen VM nicht, es läuft sofort in einen Bluescreen! Hier müssen
VOR DEM ERSTEN START einige Dateien manuell kopiert werden.
Achtung!
Dieses Vorgehen wird von Microsoft nicht empfohlen (funktioniert aber)!
Am besten in einer VM vorher ein gleiches System mit gleichem ServicePack und Patch-Stand frisch installieren. Von dort aus System32 folgende
Dateien kopieren und dann über die Hilfs-VM auf der Ziel-Platte ersetzen:
Ntoskrnl.exe
Kernel32.dll
Winsrv.dll
Hal.dll
Ntdll.dll
Win32k.sys
Keine Anmeldung am DC: verschobene Transaction-Logs
Nach dem Klonen startet ein W2K-Domänen-Controller in der VM sauber
durch, aber es ist keine Anmeldung möglich. Das deutet darauf hin, dass
aus Performance-Gründen in der Quell-VM die Transaction-Logs oder die
Datenbank der ADS auf eine andere Partition verschoben wurde, welche
jetzt im Klon noch fehlt.
Der sauberste Weg ist natürlich, die Logs schon in der Quelle mittels
Wiederherstellungskonsole wieder zurück auf C: zu verschieben. Wer das
nicht kann (laufendes System bei erster Test-Migration), erreicht dies auch
nachträglich durch Patchen der Registry der Ziel-VM.
Eine Anleitung dazu gibt es bei mir per Mailanfrage.
Registry nachträglich ändern
Um Änderungen an der Registry des Zielsystems zu machen, wenn dieses
nicht läuft, kann die externe Registry direkt in der Wartungs-VM, mit einer
BartPE-CD oder per VMware-Disk-Mount bearbeitet werden:
regedt32 starten
Menü: Registrierung > Struktur laden
Dateien im Ordner "%SystemRoot%\system32\config" der virtuellen Zielplatte öffnen:
system für: HKEY_LOCAL_MACHINE\System
software für: HKEY_LOCAL_MACHINE\Software
einen beliebigen Key-Namen festlegen, z.B. „system_vm“
unter diesem Key kann die externe Registry nun direkt bearbeitet werden
Achtung! alle hier gemachten Änderungen werden sofort geschrieben!
5
Copyright 2005 Sven Ahnert - www.vmaschinen.de
www.vmaschinen.de
Physical to Virtual mit VMware - Teil2
Registry „impfen“
Um ganze *.reg-Dateien in eine fremde Registry zu importieren, können
Sie mit folgendem Beispiel-Script arbeiten:
rem „system_vm“ ist ein beliebig festzulegender Name
rem „winnt“ ist mit der %SystemRoot% des Zielsystems zu ersetzen
reg LOAD HKLM\system_vm winnt\system32\config\System
regedit /s regdatei.reg
reg UNLOAD HKLM\system_vm
Das benötigte Programm reg.exe ist bei XP/2003 schon dabei, bei W2K
befindet es sich auf der Windows-CD im Verzeichnis support\tools.
Eine passende *.reg-Datei, um z.B. den Standard-IDE-Treiber oder die
VMware-SCSI-Treiber nachträglich zu installieren, finden Sie in Kürze hier:
http://www.vmaschinen.de/cgi-bin/vmware.cgi?treiberreg
Eigentlich sollten solche Nacharbeiten eher die Ausnahme sein, wenn man
schon in der Quelle vor dem Klonvorgang die benötigten Treiber, wie im
Teil1 beschrieben, vorinstalliert hat.
Reparatur-Installation – letzter Notnagel
Zum Abschluss möchte ich noch auf die Möglichkeit einer ReparaturInstallation mit der Windows-Installations-CD mit nachträglichem
Aufspielen aller SPs und Patches hinweisen (wenn keine Slipstream-CD
verwendet wird). Diese etwas langwierige Methode kann ebenfalls viele
Fehler wieder bereinigen. Allerdings mit dem Risiko, doch hin und wieder
die eine oder andere DLL eines installierten Programms mit zu
überschreiben.
Nacharbeiten an der lauffähigen VM
Sind alle Fehler bereinigt und die Kopie des physischen Rechners startet in
einer VM, dann sind noch einige Nacharbeiten nötig, um den
Virtualisierungsvorgang abzuschließen.
Alte Treiber entfernen
Alten Gerätetreiber, welche Sie nach dem P2V gerne entfernen möchten,
sind im Gerätemanager oftmals nicht mehr sichtbar, z.B. die alte Netzkarte.
An sich ist das kein Problem, diese Geräte stören meist nicht. Nur bei
Netzkarten kommt immer wieder eine lästige Fehlermeldung, dass die IPAdresse schon vergeben ist, wenn man dem neuen virtuellen Adapter die
IP des alten Quell-Rechners geben will.
6
Copyright 2005 Sven Ahnert - www.vmaschinen.de
www.vmaschinen.de
Physical to Virtual mit VMware - Teil2
So spüren Sie verborgene Geräte auf:
Kommandozeile starten:
START > cmd
an der Kommandozeile folgende Kommandos eingeben:
(Achtung! Aus der gleichen DOS-Box starten!)
set devmgr_show_nonpresent_devices=1
start DEVMGMT.MSC
im so gestarteten Geräte-Manager:
"Ansicht > Ausgeblendete Geräte anzeigen"
Sonstiges - der Rest in Stichpunkten
VMware Tools installieren.
Defragmentierung des Laufwerkes C:
Optional eine zusätzliche virtuelle Platte für Swap einrichten, dann die
Auslagerungsdatei verschieben.
Ereignisprotokoll auf Fehler kontrollieren.
Netzkarte neu konfigurieren (sh. auch Newsletter)
Jetzt nützt Ihnen die Datei „IP.txt“, welche im Teil1 mittels ipconfig /all >
c:\ip.txt angelegt wurde. Das Konfigurieren sollte erst ganz zum Schluss
geschehen, da durch neue Hardware in wechselnden virtuellen PCI-Slots
ständig neue Netzkarten erkannt werden.
Wenn nötig, MAC-Adresse des Quellrechners einstellen (sh. NetzwerkNewsletter).
Daten mittels Datensicherung und Agents auf zusätzliche virtuelle Platten
zurückspielen.
Fertig! Herzlichen Glückwunsch, Ihr Server existiert nur noch virtuell in
seiner eigenen Matrix!
Sven Ahnert
7
Copyright 2005 Sven Ahnert - www.vmaschinen.de