3
Disk2VHD ergibt BSOD bei Windows 2008 SP2
Hallo zusammen,
habe schon häufig mal Desktops mit Disk2VHD migriert und noch nie beim Konvertieren Schwierigkeiten gehabt.
Gestern dann, in einem überschaubaren Netz mit einem SBS und einem Terminalserver (beides Windows Server 2008 mit nun SP2) kam es reproduzierbar bei der Testmigration des Terminalservers direkt nach ein paar GB zum BSOD mit 0x00000003.
Testmigration deshalb, da VOR der Anschaffung eines neuen Servers mit 2012R2 geprüft werden sollte, ob die Altmaschinen virtuell laufen würden um die komplette Umstellung auf eine neue Landschaft nicht im Zeitraffer machen zu müssen
Genutzt wurde sowohl die Version 1.64 als auch die Version 2.01 von Disk2VHD. Die Standardoptionen VSS zu nutzen und VHDX zu nutzen waren aktiviert. Aber egal ob ich auf die Systemplatte (70 GB von 400 GB genutzt) oder auf eine USB-Platte (1TB) schreiben möchte, es kommt immer der gleiche Fehler.
Da der Fehler bereits beim Terminalserver kommt, habe ich bislang keinen Test zum SBS selbst durchgeführt, ob dies dort auch so wäre.
Auch ein komplettes Patchen des OS hat keine Verbesserung ergeben.
Hat jemand eine Idee, woran es liegen mag?
Gibt es Tools, die zu empfehlen wären um eine Konvertierung hin zu Hyper-V zu realisieren. Schön, wenn es kostenlos wäre, muss aber nicht. Aber funktionieren sollte es
Gruß
Manfred
habe schon häufig mal Desktops mit Disk2VHD migriert und noch nie beim Konvertieren Schwierigkeiten gehabt.
Gestern dann, in einem überschaubaren Netz mit einem SBS und einem Terminalserver (beides Windows Server 2008 mit nun SP2) kam es reproduzierbar bei der Testmigration des Terminalservers direkt nach ein paar GB zum BSOD mit 0x00000003.
Testmigration deshalb, da VOR der Anschaffung eines neuen Servers mit 2012R2 geprüft werden sollte, ob die Altmaschinen virtuell laufen würden um die komplette Umstellung auf eine neue Landschaft nicht im Zeitraffer machen zu müssen
Genutzt wurde sowohl die Version 1.64 als auch die Version 2.01 von Disk2VHD. Die Standardoptionen VSS zu nutzen und VHDX zu nutzen waren aktiviert. Aber egal ob ich auf die Systemplatte (70 GB von 400 GB genutzt) oder auf eine USB-Platte (1TB) schreiben möchte, es kommt immer der gleiche Fehler.
Da der Fehler bereits beim Terminalserver kommt, habe ich bislang keinen Test zum SBS selbst durchgeführt, ob dies dort auch so wäre.
Auch ein komplettes Patchen des OS hat keine Verbesserung ergeben.
Hat jemand eine Idee, woran es liegen mag?
Gibt es Tools, die zu empfehlen wären um eine Konvertierung hin zu Hyper-V zu realisieren. Schön, wenn es kostenlos wäre, muss aber nicht. Aber funktionieren sollte es
Gruß
Manfred
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 235570
Url: https://administrator.de/contentid/235570
Ausgedruckt am: 22.11.2024 um 12:11 Uhr
3 Kommentare
Neuester Kommentar
Hallo.
Ich hab' noch nie mit Disk2Vhd gearbeitet, kenne aber einen anderen Weg, der zwar kompliziert klingt, aber trotzdem gut funktioniert:
- nimm Dir den Offline-Konverter von VMware (richtig gelesen, VMware) und wandle Deine physikalische Maschine ins *.vmdk-Format, die dabei entstehende vmdk-Datei einfach aufbewahren, nicht versuchen, diese mit VMware Player oder ESX(i) zu starten, einfach liegenlassen/aufbewahren(http://www.vmware.com/de/products/converter)
- nimm danach den V2V-Konverter von Starwind (http://www.starwindsoftware.com/converter) und wandle die vmdk ins vhd-Format.
Ich habe auf diesem Weg schon mehrere phys. Maschinen nach HYPER-V gebracht, der "Umweg" über VMware schadet der späteren HYPER-V-Maschine nicht, meine so umgewandelten Maschinen laufen alle einwandfrei.
Edit: Ich lese jetzt gerade noch, daß es hier auch um einen Terminalserver geht. Da ist eine Besonderheit zu beachten: Gerade dann, wenn die bisherige physikalische Hardware schon etwas schwachbrüstig war (dies ist ja oft ein Grund für den Virtualisierungswunsch), ist es reizvoll, dann der umgewandelten, virtuellen Maschine bessere/mehr virtuelle Hardwareressourcen zuzuweisen. Beim Terminalserver wäre ich da vorsichtig. Mehr RAM und mehr Festplattenspeicher sind kein Problem, aber bei der CPU wäre ich vorsichtig. Meine Erfahrung ist, daß man einem P2V-umgewandelten Terminalserver die genau gleiche Anzahl virtueller CPU's geben sollte, wie vorher logische CPU-Kerne vorhanden waren, wenn also vorher bspw. ein 2-Kern-XEON ohne HT im Einsatz war, würde ich dem virtuellen TS auch nur 2 virtuelle CPU-Kerne geben. Bei einem 2-Kern-XEON mit HT dann entsprechend 4 undsoweiter. Die angezeigte Anzahl von CPU's im Taskmanager der physikalischen Maschine sagt es Dir eigentlich ganz genau. Andernfalls riskierst Du merkwürdige Phänomene bei der Performance, zum Beispiel, das in der TS-Sitzung eines Users plötzlich minutenlang nichts mehr reagiert u. w. m..
Viele Grüße
von
departure
Ich hab' noch nie mit Disk2Vhd gearbeitet, kenne aber einen anderen Weg, der zwar kompliziert klingt, aber trotzdem gut funktioniert:
- nimm Dir den Offline-Konverter von VMware (richtig gelesen, VMware) und wandle Deine physikalische Maschine ins *.vmdk-Format, die dabei entstehende vmdk-Datei einfach aufbewahren, nicht versuchen, diese mit VMware Player oder ESX(i) zu starten, einfach liegenlassen/aufbewahren(http://www.vmware.com/de/products/converter)
- nimm danach den V2V-Konverter von Starwind (http://www.starwindsoftware.com/converter) und wandle die vmdk ins vhd-Format.
Ich habe auf diesem Weg schon mehrere phys. Maschinen nach HYPER-V gebracht, der "Umweg" über VMware schadet der späteren HYPER-V-Maschine nicht, meine so umgewandelten Maschinen laufen alle einwandfrei.
Edit: Ich lese jetzt gerade noch, daß es hier auch um einen Terminalserver geht. Da ist eine Besonderheit zu beachten: Gerade dann, wenn die bisherige physikalische Hardware schon etwas schwachbrüstig war (dies ist ja oft ein Grund für den Virtualisierungswunsch), ist es reizvoll, dann der umgewandelten, virtuellen Maschine bessere/mehr virtuelle Hardwareressourcen zuzuweisen. Beim Terminalserver wäre ich da vorsichtig. Mehr RAM und mehr Festplattenspeicher sind kein Problem, aber bei der CPU wäre ich vorsichtig. Meine Erfahrung ist, daß man einem P2V-umgewandelten Terminalserver die genau gleiche Anzahl virtueller CPU's geben sollte, wie vorher logische CPU-Kerne vorhanden waren, wenn also vorher bspw. ein 2-Kern-XEON ohne HT im Einsatz war, würde ich dem virtuellen TS auch nur 2 virtuelle CPU-Kerne geben. Bei einem 2-Kern-XEON mit HT dann entsprechend 4 undsoweiter. Die angezeigte Anzahl von CPU's im Taskmanager der physikalischen Maschine sagt es Dir eigentlich ganz genau. Andernfalls riskierst Du merkwürdige Phänomene bei der Performance, zum Beispiel, das in der TS-Sitzung eines Users plötzlich minutenlang nichts mehr reagiert u. w. m..
Viele Grüße
von
departure
Hi departure,
das hört sich gut an. Ich werde heute Abend mal versuchen, diesen Weg zu beschreiten. Ich melde mich dann mit Ergebnissen.
Ich habe gerade mal den VMware vCenter Converter 5.5.0 runtergeladen. Ist denn damit eine OFFLINE-Konvertierung möglich? Ich konnte dort nur Hinweise zum HOT Cloning finden...
Beste Grüße
Manfred
das hört sich gut an. Ich werde heute Abend mal versuchen, diesen Weg zu beschreiten. Ich melde mich dann mit Ergebnissen.
Ich habe gerade mal den VMware vCenter Converter 5.5.0 runtergeladen. Ist denn damit eine OFFLINE-Konvertierung möglich? Ich konnte dort nur Hinweise zum HOT Cloning finden...
Beste Grüße
Manfred
Ups, Du hast Recht, der kann das nur online, leider kein Coldclone. Den "großen", vollwertigen "Coldcloner" (ist eine ISO) kriegt man nur, wenn man ein Enterprise-Produkt von VMware kauft. Der Online-Konverter sollte zwar auch funktionieren, aber ein Restrisiko wg. Konsistenz bleibt.
Schreib' mir mal ne PN.
Schreib' mir mal ne PN.
