VMware-Forum

Ich habe einen Rechner auf dem noch Windows NT4 SP6 läuft und bin dabei diesen per VMWare auf einem neuen Win7 Professional-Rechner zu virtualisieren.

Das alte Betriebssystem wurde per VMWare Converter boot CD in .vmdk konvertiert und sollte dann auf dem Hostrechner mit VMWare Player, bzw. Workstation zum Laufen gebracht werden.

Der OS-Loader des Gastsystems wird gestartet. man kann NT4 beim Bootvorgang auswählen, dann bleibt der Bootvorgang immer an der gleichen Stelle hängen:

http://i.imgur.com/SGFcsrE.jpg

Einmal das Log:
https://www.dropbox.com/s/18sjdhuernw1m99/vmware.log

Es wäre genial wenn mich jemand in die richtige Richtung weisen, bzw. mir einen Lösungsansatz geben könnte.

Danke

Frage:
- Ist die vHW vom Typ "4"?
- Wenn du die vmdk an eine andere VM haengst kannst du das Filesystem sehen und verwenden?
- Wie ist der Inhalt der Boot.ini

Gruss
Joerg

Beim Booten kommt er schon ziemlich weit, das Filesystem scheint in Ordnung. Den Bootloader und das Windows-Verzeichnis hat er gefunden.

Vermutlich ist es ein Treiberproblem.

Bitte folgende Optionen in der boot.ini aktivieren:
(dafür temporär die vmdk in ein anderen Windows-System einbinden)

/BASEVIDEO /SOS

Das deaktiviert den Grafiktreiber und zeigt die Treiber an, so wie sie geladen werden. Vielleicht kann man dann feststellen, welcher Treiber Ärger macht. Den kann man dann in der Registry deaktivieren.

Hallo und vielen Dank schonmal für die schnelle Antwort

- die vHW ist vers. 7
- auf das Filesystem der vmdk hab ich Zugriff
- der inhalt der boot.ini auf dem gastsystem ist wie folgt:



Gruß und schönes Wochenende

Was passiert, wenn du den 2. Eintrag aus der boot.ini auswählst?
"Windows NT Workstation, Version 4.0 [VGA-Modus]"

leo hat geschrieben:Was passiert, wenn du den 2. Eintrag aus der boot.ini auswählst?
"Windows NT Workstation, Version 4.0 [VGA-Modus]"

Nach Auswahl des VGA-Modus lädt das OS nach und nach Treiber ( http://i.imgur.com/GXW6EsQ.jpg ) und wechselt danach auf die blaue Anzeige aus dem ersten Screenshot. Bis dahin verhält sich die Vm identisch mit den originalen NT4-System auf dem Ursprungsrechner.

2014-07-25T12:25:37.806+02:00| vmx| I120: DICT virtualHW.version = "6"

Keine Ahnung ob es damit zusammenhängt, aber der Vollständigkeit halber sei dir gesagt, daß du keine vHW-Version 7 hast.

2014-07-25T12:24:29.229+02:00| vmx| I120: DICT ide0:0.present = "TRUE"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT ide0:0.autodetect = "FALSE"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT ide0:0.filename = "D:"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT ide0:0.deviceType = "atapi-cdrom"
...
2014-07-25T12:25:37.806+02:00| vmx| I120: DICT usb.present = "TRUE"

Die Einbindung eines Host-Laufwerks ist immer mit zusätzlichen Wartezeiten verbunden und kann unter Umständen auch zu einer unwilligen VM führen.
NT4 mag ja vielleicht noch USB1.1 unterstützen, aber USB2.0 wage ich zu bezweifeln. Ich würde daher den USB-Controller deaktivieren (rauswerfen macht keinen Sinn, da dann wieder unbekannte Voreinstellungen gelten) und dadurch hoffentlich auch die Bluetooth-Meldungen ersparen:

2014-07-25T12:24:31.272+02:00| vmx| I120: USB: Found device [name:Virtual\ Bluetooth\ Adapter vid:0e0f pid:0008 speed:full family:wireless,bluetooth deviceType:virtual-bluetooth version:2]

Er bleibt beim Booten am class2.sys hängen, nachdem er versucht hat, den buslogic-Treiber zu laden.

Setze mal folgende Zeile in die .vmx-Datei der VM:

@leo
Das ist bereits eingestellt und wurde im Eröffnungspost verlinkten "vmware.log" auch wie folgt gelistet:

2014-07-25T12:24:29.229+02:00| vmx| I120: DICT scsi0.present = "TRUE"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT scsi0.virtualDev = "buslogic"
2014-07-25T12:24:29.229+02:00| vmx| I120: DICT buslogic.noDriver = "FALSE"

leo hat geschrieben:Er bleibt beim Booten am class2.sys hängen

Könnte es an soetwas liegen:
"Der Fehler beim Booten kommt daher, da du versuchst, eine NT-Version für Single-Prozessoren auf einer Multiprozessormaschine laufen zu lassen. Das wird so nicht funktionieren, da es bei den beiden Versionen Unterschiede in der HAL.dll und dem Kernel gibt. Entweder musst du diese gegen die richtigen Austauschen oder neu installieren. "

Grüße
Christoph

Der Tipp mit dem falschen HAL könnte passen. Die Frage ist jetzt natürlich, über wieviel CPUs das NT4-SP6 vorher geherrscht hatte.

Unabhängig davon ist das die aus dem "vmware.log" kopierte VM-Config:

2014-07-25T12:24:30.227+02:00| Worker#0| I120: DISKLIB-LINK : Opened 'C:\Users\STSAdmin\Desktop\NT_Rechner\NT2.vmdk' (0xa): monolithicSparse, 1677312 sectors / 819 MB.

Wieviel freien Platz hast du eigentlich noch auf dem NT4-Datenträger von 819MB?
Keine Ahnung wieviel Plattenplatz ein NT4 mit SP6 braucht, aber bei 256MB konfiguriertem vRAM legt NT4 sicherlich eine mindestens gleichgrosse Auslagerungsdatei an und somit würden nur noch 563MB frei sein.

NT 4.0 SP6 braucht ca. 110 MB. Die Auslagerungsdateigröße setzt NT auf 1,1 bis 1,5 mal die RAM-Größe. Also sollten rund 390 MB belegt sein.

Die hal.dll kann man an der Dateigröße feststellen:



halm....dll sind Multiprozessor, ohne m sind es Uniprozessor-Versionen.

In seinem verlinktem Screenshot sieht man "hal.dll" und das wuerde auch passen zu dem vmware.log welches sagt NumVCPUs=1. Das passt doch erstmal zusammen oder hab ich das falsch verstanden?

Gruss
Joerg

Die für die Hardware zutreffende HAL wird vom Setup als "hal.dll" ins system32-Verzeichnis kopiert.

Ah.. also muesste man ueber die Groesse heraus bekommen was es genau fuer eine ist oder halt mal der VM 2 vCPUs geben um zugucken obs wirklich daran liegt.

Gruss
Joerg

Wenn man die MPS-HAL auf einer single-CPU-VM fährt, sollte das erscheinen:
https://forums.virtualbox.org/download/file.php?id=7500&sid=5d78127f86a22f9770ba421724dd6d31

Hallo und schonmal vielen Dank für die zahlreichen Antworten.

"Der Fehler beim Booten kommt daher, da du versuchst, eine NT-Version für Single-Prozessoren auf einer Multiprozessormaschine laufen zu lassen. Das wird so nicht funktionieren, da es bei den beiden Versionen Unterschiede in der HAL.dll und dem Kernel gibt. Entweder musst du diese gegen die richtigen Austauschen oder neu installieren. "

Der Tipp mit dem falschen HAL könnte passen. Die Frage ist jetzt natürlich, über wieviel CPUs das NT4-SP6 vorher geherrscht hatte.

Sollte sowas nicht auch durch die Einstellungen in der Workstation, bzw. dem Player behoben werden? Die Einstellungen sind bei beiden auf 1 Prozessor, 1 Kern eingestellt. Das Gastsystem ist in der Tat ein alter single-core AMD-Sempron, auf dem Host-System ein i3.

Wieviel freien Platz hast du eigentlich noch auf dem NT4-Datenträger von 819MB?
Keine Ahnung wieviel Plattenplatz ein NT4 mit SP6 braucht, aber bei 256MB konfiguriertem vRAM legt NT4 sicherlich eine mindestens gleichgrosse Auslagerungsdatei an und somit würden nur noch 563MB frei sein.

Die Größe der original-NT4-Installation plus die darauf installierte Software beträgt in etwa 210 MB (identisch mit der Größe der vmdk-Datei). In vorherigen Versuchen hab ich auch schon sowohl den Speicher auf 1024 MB als auch den Festplattenplatz auf mehrere GB angehoben, mit dem gleichen "Erfolg".

Ah.. also muesste man ueber die Groesse heraus bekommen was es genau fuer eine ist oder halt mal der VM 2 vCPUs geben um zugucken obs wirklich daran liegt.

Wenn man die Anzahl der Prozessoren im Player auf "2" hochstellt bekommt man folgendes log:
https://www.dropbox.com/s/k5wp84k13ewi0e6/vmware3.log
der Fehler, bzw. das Resultat ist identisch mit dem aus dem Ursprungspost.

Waren eigentlich in NT4 vorher irgendwelche AMD-CPU-Treiber installiert?
AMD war ja bisweilen etwas zu fix für einige ältere Windows-Versionen und erzeugt dann einen Timerüberlauf.