Borns IT- und Windows-Blog

Von Sysinternals wird das kleine Programm disk2vhd [1] zum Klonen von Betriebssystemen in .vhd-Dateien angeboten. Auf den ersten Blick ein geniales Tool, was aber hinter den Kulissen mächtig Ärger bereitet.

Eigentlich sollte es ja nur ein kurzer Test für mein neues Windows 7-Buchprojekt werden. Schnell die aktuelle Version der Sysinternals Tools heruntergeladen, das Internetzonen-Bit des ZIP-Archivs über Eigenschaften und anklicken der Schaltfläche Zulassen gelöscht und dann alles entpackt. Danach disk2vhd gestartet und ein Abbild des parallel zum laufenden Windows 7 Ultimate (64 Bit) installierten Windows 7 Home Premium (32 Bit) in eine .vhd-Datei erstellen lassen.

Probleme mit der Version 1.6 unter 64 Bit Windows

Umso größer war mein Staunen, als sich nach einem Doppelklick auf disk2vhd nichts tat. Die Kontrolle im Taskmanager zeigte, dass da zwei Prozesse liefen. Aber es kam kein Bedienfenster zum Vorschein.

Also das Ganze in einer 32-Bit-Windows 7-Umgebung (in einer VM) gestartet, und siehe da: das Programmfenster wurde angezeigt. Schnell in meiner Download-Sammlung gewühlt und flugs eine frühere Ausgabe der Sysinternal-Tools ausgegraben. Ein Doppelklick auf die disk2vhd – schon war das Programmfenster vorhanden.

Offenbar hat die aktuelle Version 1.6 einen Bug, der die Anzeige der Programmversion unter einem 64-Bit-Windows 7 verhindert. Nachdem ich den Bug im Sysinternals-Forum eingetragen habe ([2]), meldete sich noch ein zweiter Anwender, der das Gleiche beobachtet. Ich selbst habe nach ein wenig Probieren noch einen einfachen Workaround für das Problem gefunden: Rechtsklick auf die disk2vhd.exe, im Kontextmenü den Befehl Eigenschaften wählen und dann auf der Registerkarte Kompatibilität den Kompatibilitätsmodus auf “Windows Vista SP2” gesetzt – schon läuft disk2vhd wie erwartet.

Das garstig Ding clont die komplette Partitionsstruktur

Noch kritischer ist aber das generelle Verhalten von disk2vhd. Bisher hatte ich das Tool immer in einer virtuellen Maschine mit einem Laufwerk (enthielt nur eine Partition) getestet. Daher war mir die Feinheit in der Sysinternals-Beschreibung “Disk2vhd is a utility that creates VHD (Virtual Hard Disk – Microsoft’s Virtual Machine disk format) versions of physical disks for use in Microsoft Virtual PC or Microsoft Hyper-V virtual machines (VMs).” nicht so richtig aufgefallen. Nett, das Teil klont also keine logischen Datenträger (die ja die Windows-Installation enthalten), sondern die physikalische Festplatte.

Nachdem ich nun auf einer realen Maschine disk2vhd einsetzen wollte kam daher die böse Überraschung. Das Tool ermöglicht im Bedienfenster das Abwählen der unerwünschten Partitionen und erstellt die .vhd-Datei. Als ich die Größe der .vhd-Datei überprüfte, sah auch alles gut aus – aus der 70 GByte Systempartition und der 100 MByte “System reserviert”-Partition war lediglich eine 15 GByte große .vhd-Datei geworden. Also alles im “grünen Bereich”?

Also ich diese .vhd-Datei einsetzen wollte, fingen die Probleme an. Der Versuch, die .vhd-Datei in der Datenträgerverwaltung ins Dateisystem einzuhängen, endete damit dass die virtuelle Disk nicht online genommen wurde. Eine Inspektion in der Datenträgerverwaltung zeigte dann die Ursache: disk2vhd überträgt zwar nur die markierten Partitionen über den VSS-Dienst, schreibt aber das Abbild der kompletten Partitionsstruktur in die .vhd-Datei. Dies wurde zwischenzeitlich unter [4] bestätigt.

Wird die .vhd-Datei auf der Maschine, unter der sie erstellt wurde, per Datenträgerverwaltung ins Dateisystem eingehängt, kommt es zu einem Signaturkonflikt mit der physikalischen Festplatte (beide Laufwerke besitzen die gleiche Signatur – den ClassID-Code der Art {xxxx-xxxx-xxxx-xxxx} – und Partitionsstruktur). Der eingehängte Datenträger wird nicht online genommen.

Anmerkung: An dieser Stelle sei erwähnt, dass ich wohl besser vorab den unter [8] verlinkten Beitrag der Entwickler gelesen hätte. Mark Russinovich beschreibt ganz klar, dass die virtuellen Datenträger einer VM maximal 127 GByte groß sein dürfen. Das Clonen größerer Festplatten ist also nicht möglich – und das Einbinden des Datenträgers auf der Maschine, auf der die .vhd-Datei erstellt wurde, führt zu einem Signaturkonflikt. Der Clone lässt sich also auch nicht nativ booten – was ich auf die harte Tour gelernt habe.

Scheibenkleister – denn  der Datenträger lässt sich vordergründig nicht in der Datenträgerverwaltung bearbeiten. Ich habe dies oben in einer Bildmontage dargestellt. Glücklicherweise lässt sich das Einbinden des Datenträgers in das Dateisystem erzwingen. Man muss nur den Datenträger in der Datenträgerverwaltung mit der rechten Maustaste anklicken und den Kontextmenübefehl Online wählen. Je nach Partitionszustand kann es dann aber bereits eng mit den frei verfügbaren Laufwerksbuchstaben werden – was das nächste Problem aufwirft.

Virtualisierung? – Pustekuchen mit Hundekacke!

Auch der Versuch, eine solche .vhd-Datei in Windows Virtual PC einzubinden, endet mit einer Fehlermeldung. Windows Virtual PC meldete, dass eine so große Festplatte nicht per IDE-Schnittstelle eingebunden werden könne (siehe auch [9]). In der Tat zeigte die Datenträgerverwaltung die Größe der .vhd-Disk mit 931,51 GByte an – was genau der Größe der physikalischen Festplatte entsprach. Willkommen in der realen Welt!

Als ich dann die so erstellte .vhd-Datei im Bootmenü eintrug, um das geclonte Windows 7 nativ zu booten, kam es beim Neustart kurz nach der Anzeige des Windows 7-Bootlogos zu einem Blue Screen und der Rechner stürzte ab. Also ließ sich der Clone nicht aus der virtuellen Disk booten. Ursache ist vermutlich der identische Signatureintrag, wodurch der Windows-Bootmanager nicht weiß, welches Laufwerk zu verwenden ist. Einzig denkbares Szenario wäre dann, die vhd-Datei auf einem zweiten Rechner einzusetzen (was ich aber nie probiert habe – und was auch nicht meine Intension war).

Lediglich ein Versuch, die vhd-Disk mit der geclonten Windows 7-Version in VirtualBox einzubinden, brachte Erfolg. Ich konnte Windows 7 auf Anhieb in VirtualBox booten. Allerdings war die betreffende Windows 7-Variante grottenlangsam in der Bedienung. Sobald der Desktop erschien, wurden zig Treiber neu eingerichtet und es gab Warnungen, dass bestimmte Java-Module nicht aufrufbar wären. Dies deckt sich mit meinen Erfahrungen beim Clonen von diversen Windows XP-Systemen – die virtuellen Maschinen liefen äußerst zäh.

Ein Test im VMware Player endete damit, dass sich der Windows 7-Klon nicht aus der vhd-Datei booten ließ. Es wurde ein Disk-Zugriffsfehler gemeldet.

Mit Trick 17 in’s Knie geschossen?

Meine nächste Idee, die erstellte .vhd-Disk etwas aufzuhübchen, scheiterte ebenfalls kläglich. Zuerst wurde der Datenträger zwangsweise in der Datenträgerverwaltung online genommen. Dann konnte ich zumindest einen Teil der Partitionen, deren Inhalt beim Clonen nicht übernommen wurde, löschen. Die OEM-Partition ließ sich auf diesem Weg aber nicht entfernen. Hierzu habe ich die Eingabeaufforderung im administrativen Modus gestartet und dann diskpart aufgerufen. Mit der Befehlssequenz:

diskpart
select disk 5
select partition 6
delete partition override

gelang es mir, die geschützte Partition aus der .vhd-Disk zu entfernen. Anschließend habe ich das virtuelle Laufwerk entladen und mit dem Programm VHD Resizer ([7]) auf 100 GByte reduziert.

Das Ergebnis war allerdings ernüchternd: Zwar konnte ich die .vhd-Disk sofort in der Datenträgerverwaltung einhängen. Die Disk wurde direkt online gestellt und ich konnte über das Ordnerfenster Arbeitsplatz auf die betreffenden Ordner und Dateien zugreifen. Eine Datenträgerprüfung ergab keine Probleme.

Selbst das Einbinden der vorher in der Datenträgerverwaltung entladenen .vhd-Datei klappte nun. Leider ließ sich die so “bereinigte” .vhd-Datei weder in Windows Virtual PC, noch in VMware noch in VirtualBox booten. Es wurde sofort ein Zugriffsfehler auf den Datenträger gemeldet. Nachdem ich ein Windows PE gebootet und die Eingabeaufforderung geöffnet hatte, wurde eine Kurzanalyse durchgeführt. Der Befehl chkdsk meldete, dass der Datenträger beschädigt sei. Der Versuch einer Reperatur mit chkdsk C: /f führte zur Meldung, dass die Master-File-Table beschädigt sei und nicht repariert werden könne.

Da sich die gleiche .vhd-Disk in der Datenträgerverwaltung des Hosts einbinden lässt und das Laufwerk zugreifbar ist, kann der Zugriffsfehler nur auf das Einbinden in der VM zurückzuführen sein. Bereits die in der Datenträgerverwaltung um die nicht benötigten Partitionen bereinigte Fassung der .vhd-Datei war nicht mehr bootfähig. Ich habe die .vhd-Datei in VirtualBox sowohl als IDE-Festplatte, als SCSI-Disk als auch über einen SATA-Controller eingebunden – in allen Fällen wurde der Zugriffsfehler auf das Systemlaufwerk gemeldet. Ein nochmaliges Laden per Datenträgerverwaltung mit anschließender Fehlerprüfung zeigte aber, dass die Laufwerke intakt waren.

Aus die Maus – und die Moral von der Geschicht?

An dieser Stelle habe ich erst einmal abgebrochen, da mir der Ansatz zum Clonen doch etwas “steinig” erschien. Eigentlich erwarte ich von solchen Tools, dass möglichst das gewünschte Laufwerk in die .vhd-Datei kommt. Die Startdateien für Windows 7 kann man ja mit den Reparaturoptionen oder anderen Tricks restaurieren (oder man kopiert die Partition “System reserviert” gleich mit in die .vhd-Datei). Das Szenario, dass ein Rechner nur eine Festplatte mit 100 GByte und einer Windows 7-Partition enthält, die dann zum Clonen verwendet wird, scheint mir nicht so häufig in der realen Welt vorzukommen. Mein Fazit: disk2vhd ist alles andere als praxistauglich bzw. auf Szenarios begrenzt, die in meinem Umfeld nicht oder kaum vorkommen (ich baue keine 40 GByte Festplatte in einen alten Rechner ein, installiere dann Windows XP, Windows Vista oder Windows 7, nur um anschließend diese Installation mit allen Seiteneffekten in eine .vhd-Datei zu clonen). Da ist die direkte Installation in einer virtuellen Maschine zielführender!

Nun grübele ich darüber, wieso disk2vhd in zahlreichen Blogs als “das Tool” zum Clonen von Windows-Installationen (oder zum Partitions-Backup) dargestellt wird. Eine mögliche Erklärung wäre, dass die betreffenden Leute nie mit dem Tool experimentiert haben. Erkenntnis: Traue niemals einer Aussage Dritter, die Du nicht selbst verifiziert hast. Der unter [10] verlinkte Artikel zeigt mir, dass zum Erstellen des Tutorials eine virtuelle Maschine verwendet wurde – denn niemand arbeitet heute mit einer 16 GByte großen Festplatte. Lediglich in [9] bin ich auf einen Beitrag gestoßen, wo der betreffende Autor die Probleme korrekt adressiert und angeblich mit Hyper-V auf Windows Server 2008 R2 gelöst hat (aber diesen Test habe ich mangels Masse nicht gefahren).

Fazit: Zwischenzeitlich bin ich daher dazu übergegangen, in den virtuellen Maschinen eine virtuelle Disk im Format der betreffenden Virtualisierungslösung (z. B. VirtualBox .vdi oder VMware .vmdk) anzulegen und dann eine Neuinstallation des Betriebssystems vorzunehmen. Diese Lösungen laufen zufriedenstellend. Zum Klonen von Betriebssystemen setze ich auf andere Lösungen wie den VMware Konverter oder die unter [5] genannte Lösung. Auch der Paragon Virtualisierungs Manager, der mir in einer Vorabversion zur Verfügung steht, erledigte das Clonen von Festplatten. Ein vielversprechender Ansatz findet sich bei VMLite, die das Tool MyOldPC für diese Zwecke entwickeln [6]. Ich werde MyOldPC demnächst testen und die Ergebnisse berichten.

Weiterführende Links:

[1] www.sysinternals.com (Downloadseite für das Tool)

[2] Forenbeitrag bei Sysinternals von mir

[3] Forenbeitrag mit Problemen

[4] Forenbeitrag mit weiteren Problemen

[5] Diskcloning für virtuelle Maschinen

[6] www.vmlite.com

[7] http://vmtoolkit.com/

[8] Beitrag zu disk2vhd von Mark Russinovich

[9] Problembeschreibung mit Lösung in Hyper-V

[10] Tutorial zum Clonen bei How to Geek

---

Weitere Infos zu Windows 7 finden sich in meinen Windows 7-Titeln.

(c) by Günter Born www.borncity.de

The source of smart computer books

Schlagworte: Betriebssystem cloning, disk2vhd

Dieser Beitrag wurde vor am Samstag, 17. Juli 2010 um 22:30 Uhr veröffentlicht und unter Problemlösung, Virtualisierung, Windows 7 gespeichert. Sie können Kommentare zu diesem Eintrag über den RSS-2.0-Feed verfolgen. Sie können einen Kommentar hinterlassen oder einen Trackback von Ihrer Website hierher setzen.