Als ersten Schritt starten wir das Notebook, melden uns an und starten das Programm Disk2VHD. Es erscheint das folgende Fenster

Das Notebook hat nur einer Festplatte verbaut mit einer Partition, und diese Partition wird nun in eine VHD-Datei auf das Laufwerk E: gespeichert. E: ist in meinem Fall eine USB-Festplatte. Wichtig ist die Auswahl der Option “Prepare for use in Virtual PC”. Nach einem Klick auf “Create” startet das Kopieren

Nach einer kurzen Zeit ist die Erstellung fertig und das Tool meldet einen erfolgreichen Export

Als Nachweis, das es sich bei dieser Migration wirklich um ein physikalisch vorhandenes Notebook handelt, hier ein Auszug aus einer “systeminfo”-Anzeige

Nun entfernt man die USB-Festplatte von dem Quell-Gerät, schließt sie an das Gerät mit Windows 7 an und kopiert die soeben erstellte VHD-Datei auf die Festplatte des Gerätes. Auf dem Windows 7 geht man nun über Start – Benutzername – Virtuelle Computer in die Verwaltung des Virtual PC. Dort legt man einen neuen virtuellen Computer an, wählt einen Namen und die Größe des Arbeitsspeichers und navigiert bei der Auswahl der virtuellen Festplatte zu der im vorherigen Schritt kopierten Datei. Nachdem die Maschine komplett eingerichtet wurde ist sie als Eintrag in dem Ordner sichtbar

Die virtuelle Maschine kann nun gestartet werden, das erste was man in dem neu auftauchenden Fenster sieht ist eine Boot-Auswahl

Das Windows XP startet nun, und ein knapp einer Minute sieht man das Anmelde-Fenster

Die virtuelle Maschine hat nun noch einiges an Altlasten, die wir in den nächsten Schritten entfernen

Der erste Schritt sollte die Installation der Integrationskomponenten sein

Nach einer erfolgreichen Installation bietet der Installation an, passende Updates herunterzuladen

Nach einem Klick auf “Fertig stellen” öffnet sich ein Internet Explorer mit einem Link zu dem betreffenden Update

Nach einer erfolgreichen Installation startet der Installer das System automatisch neu

Nach einem Neustart erwartet uns das folgende Bild

Die Maschine hat nun die Integrationskomponenten installiert und stellt die Auflösung automatisch so ein, dass der Benutzer nicht mehr scrollen muss bei einer zu großen Auflösung. Das System ist nun nutzbar, man kann es an dieser Stelle allerdings noch optimieren. Aktuell sind noch eine Menge Treiber für Komponenten installiert, die nicht mehr existieren, da sich die Hardware geändert hat. Wir fügen nun unter “Systemsteuerung” – “System” – “Erweitert” – “Umgebungsvariablen” eine neue Systemvariable “devmgr_show_nonpresent_devices” mit dem Wert “1” hinzu

Wenn man nun im Geräte-Manager unter “Ansicht” die Option “Ausgeblendete Geräte anzeigen” auswählen, werden uns all die Geräte angezeigt, die aktuell nicht angeschlossen oder vorhanden sind (erkennbar an der Ausgrauung)

Man kann nun nahezu alle ausgegrauten Geräte entfernen. In meinem Fall waren dies knapp 50 Stück, allerdings macht sich diese Mühe später bei der Performance des Systems positiv bemerkbar.

Eine Ausführung von “systeminfo” zeigt nun, das es sich um das gleiche System, allerdings auf unterschiedlicher Hardware handelt

Wenn man die virtuelle Maschine nun herunterfährt ist man sogar in der Lage, die installierten Programme in der virtuellen Maschine seamless zu starten

• Acronis erkennt in einer virtuellen Maschine nur die “Ältere Netzwerkkarte”, mit einer “Netzwerkkarte” unter Hyper-V kommt Acronis nicht klar, da die Treiber fehlen
• Ebenso werden keine Festplatten an dem virtuellen SCSI-Controller erkannt
• Wenn man per RDP auf den Hyper-V Host zugreift, kann man keine Maus in der virtuellen Maschine nutzen (während Acronis genutzt wird). Grund sind die fehlenden Integrationsdienste.

Nachdem man nun den Server von der Acronis-CD gestartet hat, kann die Wiederherstellung beginnen. Nachdem man sein Image ausgewählt hat, wählt man die Partitionen aus, die man wiederherstellen will.

Als nächstes wählt man die Ziel-Festplatte aus

Hier ist es wichtig, die “Universal Restore”-Option auszuwählen. Falls nicht, werden die alten Treiber und systemspezifischen Dateien nicht entfernt bzw. ausgetauscht.

Falls man noch spezielle Treiber unbedingt installieren will bzw. muss, dann kann man hier den Pfad dazu angeben. Bei einer P2P-Migration ist dies meist notwendig, bei einer P2V-Migration wird kein spezieller Treiber benötigt.

An dieser Stelle könnte man angeben, ob während der Migration direkt die SID des Systems geändert werden soll. Falls es eine P2V-Migration ist muss die SID nicht geändert werden, wenn das System dabei noch geclont oder multipliziert werden soll, dann ist diese Option vielleicht hilfreich. Alternativ kann “NewSID” genutzt werden nach der erfolgreichen Migration. Achtung: Wie bereits in dem Kommentar von Michel Lüscher angemerkt, ist sowohl diese Variante der Erstellung einer neuen SID als auch die Variante mit NewSID nicht mehr von Microsoft unterstützt. Die unterstützte Variante ist Sysprep. Vielen Dank an Michel für den Hinweis.

An dieser Stelle fordert er einen Treiber an. Wir sehen in dem Screenshot, das es sich um “*VMBus” handelt. Die Komponente ist eine emulierte Hyper-V Hardware, der Treiber dafür ist in den Integrations-Komponenten enthalten.

Nach der Migration sollte die Netzwerkverbindung getrennt werden, um Kontakt des Servers während der weiteren “Bearbeitung” mit der Domäne o.ä. unterbunden wird.

Der Server startet und fährt auch komplett hoch. Dies dauert noch recht lange, darum kümmern wir uns später…

Der Server ist hochgefahren und ich habe mich angemeldet, sofort erscheint ein Fenster mit der Meldung, das neue Hardware gefunden wurde und das für diese Hardware Treiber installiert werden müssen. Wir brechen alle auftauchenden Fenster ab.

Über das Hyper-V-Menü wird der Installationsdatenträger für die Integrationsdienste eingelegt.

Die Treiber werden installiert, danach muss der Server neugestartet werden.

Nach dem Neustart ist der Server schon ein wenig schneller, allerdings müssen noch alle nicht benötigten Programme und Treiber deinstalliert werden. In dem folgenden Screenshot sehen wir das “HP Array Configuration Utility”. Da wir keinen RAID-Controller mehr haben, kann dieses Programm problemlos entfernt werden. Falls noch weitere Tools, unterstütztende Programme oder Dienste installiert sind (in der Regel Software vom Hersteller) => runter damit wenn nicht mehr benötigt.

Als nächstes lassen wir uns alle Hardware-Komponenten anzeigen, auch die die nicht aktiv bzw. gerade im Moment enthalten sind. Hierzu öffnen wir unter System => Erweitert die “Umgebungsvariablen”.

Dort erstellen wir einen neuen Wert

Dieser Wert lautet

devmgr_show_nonpresent_devices

und hat den Wert “1”

Danach öffnen wir den Geräte-Manager und aktivieren unter “Ansicht” => “Ausgeblendete Geräte anzeigen”

Nun können wir eigentlich alle Einträge, die ausgegraut sind, löschen. In den beiden Screenshots sehen wir als Beispiel die alten physikalisch vorhandenen Netzwerkkarten und die CPUs.

Wichtig: Da wir eine virtuelle Maschine haben, ist es ein leichtes VOR dem Entfernen einen Export zu machen oder wenigstens einen Snapshot (lieber einen Export), damit wir im Falle eines Fehlers nicht den kompletten Migrations-Vorgang wiederholen müssen.

Nachdem alles entfernt wurde, kann der Server neugestartet werden. Ich habe es bisher immer erlebt, das nach dem Entfernen der Komponenten / Treiber die Maschine deutlich schneller startet und betriebsbereit ist als vorher.

In einem cmd-Fenster mit Administrator-Rechten diese beiden Befehle eingeben

set devmgr_show_nonpresent_devices=1

devmgmt.msc

Im Geräte-Manager unter “Ansicht” die Option “Ausgeblendete Geräte anzeigen” auswählen. Nun taucht in der Liste der Geräte die “alte” Netzwerkkarte auf. Diese kann nun deinstalliert werden. Nach der Deinstallation in dem cmd-Fenster folgenden Befehl eingeben

set devmgr_show_nonpresent_devices=0

Nun ist die alte Karte deinstalliert und es kommt keine Warnung mehr.

Unter Windows Server 2008 und Windows Vista (und wahrscheinlich auch unter Windows 7) wird dieser “Fehler” automatisch behoben. Nach dem Einstellen kommt eine Abfrage, ob man die alte Karte entfernen möchte.

Nach ca. 2 Minute kam dann folgendes Bild:

Dieses Problem tritt auf, wenn man unter “Virtual Server 2005″ eine SCSI-Festplatte angelegt hat und das System auf dieser Festplatte installiert hat. Unter Hyper-V müssen Boot-Festplatten an den IDE-Controller angeschlossen werden. Lösung des Problems:

Nach dem Starten, wenn der GRUB lädt, “e” drücken, um den Startbefehl zu ändern. Wie man in folgendem Bild erkennen kann, ist das root-device mit “/dev/sda1″ angegeben. Dieser Pfad existiert nicht in unserem Hyper-V, der Pfad der Festplatte hat sich verändert auf “/dev/hda1″. Diese Änderung führt man durch, speichert das ganze und drückt “b” zum booten.

Wie man an dem unteren Screenshot erkennt, startet das System nun sauber, ohne das es in einer minimalen Konsole hängenbleibt, weil es kein root-System erkennt.

Wir sind nun aber noch nicht fertig, wichtig ist das man weiß das die eben durchgeführten Änderungen nur temporär für diesen Bootvorgang ist. Man muss nun diese Änderung noch dauerhaft eintragen.

vi /boot/grub/menu.lst

In dieser Datei führt man die eben gemachten Änderungen ebenfalls durch (Am Dateiende) und speichert die Datei. Nun startet das System jedes mal mit den geänderten Einstellungen.

Ja