DOS Problem nach Übertragung von Workstation --> ESxi 5.5

[rexxxx]

Hi an alle in dem Forum.

Ich hab ein Problem und hoffe, dass ich hier einen Lösungsansatz finden kann.

Folgende Situation:
Eine alte DOS Anwendung zur Steuerung einer Maschine CNC auf einem alten Rechner soll Virtualisiert werden.

Eine VM Workstation, die funktioniert wurde erstellt und gesichert.

Um den alten Rechner zu ersetzen soll die VM nun in einen Rechner mit ESxi 5.5 installiert werden. Beim Übertragen wurde Version 7 ausgewählt.
Aber sobald die alte Steuerungssoftware gestartet werden soll erscheint folgende felermeldung: „die ntvdm-cpu hat einen ungültigen befehl entdeckt“

Als OS der VM wird Windows XP eingesetzt, da dies das letzte OS war, auf dem die Steuerung problemlos gelaufen ist.

Hat jemand eine Idee was verändert worden ist bei dem Imigrationsprozess ins ESxi?
Eingesetzt wurde
VMware vConverter 5.0.1

Alternativ tendiere ich schon dazu ein Windows mit dem VM Ware Player neu zu installieren und es von da mittels Script automatisch zu starten.

[JustMe]

Die primaere Frage hier duerfte sein, wie denn die DOS-Anwendung aus der VM heraus mit der CNC-Maschine kommunizieren soll. Das duerfte in Workstation/Player als gehosteten Hypervisors einfacher gewesen sein als mit dem Bare-Metal-ESXi.

Aber moeglich koennte es schon sein; je nach benoetigten Schnittstellen.

Und wenn es wirklich 'ne DOS-Anwendung ist, koennte man es selbstverstaendlich auch mit einer DOS-VM statt einer XP-VM versuchen. Dabei fiele immerhin die 32->16 Bit Umsetzung von XP weg, und koennte *vielleicht* schon helfen.

Ich nehme an, dass die Fehlermeldung in der VM angezeigt wird, und nicht vom Hypervisor (bzw. vSphere Client), oder? Dann wuerde die Ausfuehrung der Anwendung einen CPU-Befehl erzeugen/verwenden, der in der Virtualisierung nicht unterstuetzt ist...

Hast Du den genauen Fehlertext mal ge-suchmaschine-t?
Was sagt eigentlich der Software-Hersteller dazu?

[Dayworker]

Sag der XP-VM unter "Systemeigenschaften" -> "Umgebungsvariablen" mal, daß der Temp-Pfad für TMP und TEMP in "C:\TEMP" zu finden ist. Im Normalfall sollte dort "%USERPROFILE%\Lokale Einstellungen\Temp" drinstehen. DOS kann mit längeren Verzeichnisnamen als die 8.3-Konvention und mehr als 7 Verzeichnisebenen sprich Unterordner, nicht umgehen.

[JustMe]

(erstaunt...)

Trotzdem ich keinesfalls anzweifeln moechte, dass Dayworker's Vorschlag das Problem zu loesen vermag (DOS, noch dazu in XP, geht manchmal verschlungene Wege), bin ich auf rexxxx's Antwort gespannt, denn die gleiche XP-VM unter VMware Workstation soll ja sauber funktionieren...

[Dayworker]

Unter Umständen kommt hier noch etwas zum Tragen, daß sich bereits bei XP64 zeigte. M$ hat die 16bit-Unterstützung meines Wissens in all seinen 64bittigen Betriebssystemen entfernt und selbiges könnte auch auf VMwares ESXi zutreffen.

[rexxxx]

Guten Morgen... (bin noch müde…),
Ich hab übernacht noch 2 weitere Test gestartet und jetzt die Ergebnisse.

1. Ich einen weiteren Abzug hoch geschoben, ohne dass der Konverter die Dienste und die VM Ware Tools verändert hat. Leider funktioniert die Anwendung auch hier nicht.

2. Ich hab den Stand von dem ESxi noch mal zurück zu Workstation konvertiert und hier läuft das Programm wieder normal. Also scheint es wirklich so zusein, dass ESxi keine 16 bit Anwendungen mehr kann.
Hat jemand ne Idee?

Zu den letzten Anstößen:
@JustMe
- DOS Pur wird glaube ich problematisch. Die Anwendung arbeitet zusammen mit einem Hardlook Dongel (LPT) und der Driver wird unter Windows installiert.

- Die Meldung wird von der XP VM-Ware ausgegeben, da nimmst du richtig an.

- Der Hersteller ist vor vielen Jahren in Rente gegangen und die Firma gibt es leider nicht mehr. Ich glaube das war laut Kunde so vor 10 Jahren .

- Kommunizieren tut die Software mit der CNC Maschine über die Serielle Schnittstelle COM1 und da neue Mainboards meiste keine Parallel Ports mehr haben bin ich hier zu einem Dongel Emulator übergegangen und hab den alten Dongel gedumt, das klappt auch soweit ganz gut.

- Es scheint wirklich so zu sein, dass ESxi keine 16 Bit mehr kann. Das macht es natürlich für alte Software wieder schwer…

[Supi]

Nun, so steht es ja auch in der Compatibility Matrix :

http://partnerweb.vmware.com/comp_guide ... _Guide.pdf



Also ggf auf esxi 5.1 zurück.

[rexxxx]

Das ist ein super Tipp.
Ich werde sobald ich zuhause bin direkt das System mal auf ESxi 5.1 downgraden.

Das Lustige an der Sache ist, dass ich mir erst die mühe gemacht habe ins ESxi 5.5 die fehlenden Realtekdriver für die Netzwerkkarten zu immigrieren.

Gibt es bei 5.5 eigentlich auch irgendwas was besser läuft? Oder wurde von 5.1 zu 5.5 nur gelöscht?

Ich hallte euch auf dem Laufenden, sobald ich das Ganze auf 5.1 habe.
Danke

[rexxxx]

Hi,
also System ist umgebaut auf 5.1 und jetzt klappt auch alles
Hier laufen die alten DOS Programme ab.

Jetzt habe ich aber noch ein anderes Problem, Wenn ESxi runterfahrt schaltet es nicht den Rechner ab sondern startet direkt wieder neu.

Eine Linux Live Disk schaltet den Rechner beim Runterfahren Sauber aus, hat jemand ne Idee?

[Dayworker]

Realtek deutet auf ein nicht offiziell unterstütztes sprich Whitebox-System hin. Was ist es bei dir genau?

[rexxxx]

Hallo noch mal,
Hat sich erledigt, das DOS Programm schaltet auf Vollbild und ändert die Auflösung in eine Auflösung die weder RDP noch VLC darstellt…

Also doch Windows mit VM Ware Player.

Kennt einer einen Konsolen befehl, mit dem man die Gastmaschiene runterfahren kann?

[mbreidenbach]

Gastmaschinen RUNTERFAHREN geht nur wenn der ESXi den VMware Tools sagen kann sie mögen doch mal dem OS sagen es möge sich verziehen.

DOS -> keine VMware Tools -> nix mit 'Gast runterfahren'

[rexxxx]

Hallo an alle, endlich, alles klappt.

Das Thema kann als gelöst markiert werden .

Folgende Punkte habe ich noch zuletzt herausgefunden:

- VMWare Payer 6 macht keine 16Bit Befehle mehr mit, ich musst zurück zu Version 5.

- Zum Starten und Stoppen der VM Ware muss zusätzlich zum Player VMware-VIX installiert werden. Die Befehle zum Stoppen und Starten sehen in etwa so aus (müssen angepasst werden)

Batch befehle
Player Stoppen und Laufende Maschiene Suspendieren.
"C:\Program Files (x86)\VMware\VMware VIX\vmrun.exe" -T player suspend C:\VMServers\SVN\SVN.vmx

Player Starten (es empfiehlt sich zuvor noch alle alle „*.lck“ Ordner zu löschen, da so der Start zuverlässiger wird.)
"C:\Program Files (x86)\VMware\VMware VIX\vmrun.exe" -T player start C:\VMServers\SVN\SVN.vmx

Die Scripte könne dann mit Start-> Ausführen -> „gpedit.msc“
Dort unter Windowseinstellungen -> Scripts(Anmelden,Abmelden)
Ausgeführt werden.

Großes Danke an Dayworker ohne seine Tips bei andere Beiträgen hätte ich noch viel länger gebraucht um das richtig zum laufen zu bringen.

[Dayworker]

Die prinzipielle Steuerung per "vmrun" hatte ich im November 2009 schon mal im Posting Schnellverwaltung des VMserver2 von der CMD oder Ba$h aus beschrieben. Wenn die VM sauber in den VMware-Suspend geht oder von Seite des Gast-OS runtergefahren wird, sollten keine lck-Ordner bzw -Dateien übrigbleiben.

Zumindest DOS würde ich nicht in den Suspend schicken, falls das aufgrund der fehlenden VMware-Tools überhaupt geht. Der Start dürfte trotz VMware-Bios schneller sein und DOS ist nicht wirklich mit einem Suspend vertraut. Als weitere Nicklichkeit kommt dann prinzipiell noch die durch DOS verursachte CPU- bzw hier genauer die Kern-Auslastung hinzu. Jeder mit der DOS-Ausführung betraute CPU-Kern läuft unter Volllast, da DOS selbst keinen HLT-Befehl mitbringt und gewohnheitsmäßig immer vollständig über die CPU geherrscht hat. Der HLT-Befehl konnte wohl "CPUidle" oder eines der damaligen Mitstreiter nachrüsten. Damit bekommt man dann auch auf einem Host mit einer schmalen Dualcore-CPU eine flüssige Gast-Ausführung hin.

[rexxxx]

Hi Dayworker,
ich weiß zwar nicht, wie du und mbreidenbach darauf kommt, es handelt sich um eine pure DOS Umgebung?

Der Host ist jetzt ein Windows 7 und nicht wie ursprünglich geplant ESxi.
Der Client ist ein XP der die DOS Anwendung ausführt.

Ist glaube ich irgendwo mittendrin vergessen gegangen und das XP hat ja die VM Ware Tool.
Oder hab ich jetzt einen Denkfehler?

[Dayworker]

DOS und DOS in WinNT/2000/2003 etc sind zwei paar Schuhe. Nur in reinem DOS bekommst du kompletten Zugriff auf die HW, zumindest solange du nicht in einer VM arbeitest. Das DOS unter allen neueren Windows nach Win98 ist im Grunde kein richtiges DOS mehr sondern nur noch ein DOS-Prompt. Das wird einem schmerzlich bewußt, wenn man unter XP einen älteren EPROM-Flasher weiternutzen will.

Das die VM mit XP läuft und dann darin der DOS-Prompt genutzt wird, ist uns durchgerutscht.
In diesem Sinne sind dann eigentlich auch die Worte zu CPUidle hinfällig... Trotzdem sei dir an dieser Stelle gleich gesagt, daß der VMware-Player im Gegensatz zur kostenpflichtigen VMware-Workstation keinerlei Gast-Skalierung beherrscht. Wenn dein DOS-Prompt nur 80x40 Zeichen groß ist, hast du keine Möglichkeit den VM-Bildschirminhalt vergrössert darzustellen. Das VM-Fenster hat in diesem Fall dann eine gefühlte Auflösung von 320x240 Bildpunkte und geht auf einem FullHD-Bildschirm komplett unter.

[leo]

Hier stellt sich auch die Frage, warum man das virtualisiert. Die DOS-Umgebung hat sich seit Windows XP nicht mehr geändert und ist bis heute noch in Windows vorhanden, wenn es sich um die 32-bit-Ausführung handelt. Ich habe ohne irgendeine Änderung DOS-Anwendungen von XP nach WIN 8 32-bit kopiert und sie laufen problemlos.

[Dayworker]

Es kommt auf die Art der DOS-Anwendung an. Während man hinterrücks an XP vorbei beispielsweise trotzdem noch fast ungebremsten Zugriff auf ältere HW wie den von mir bereits erwähnten Flash-Prommer bekommen kann, sind diese Möglichkeiten bei sämtlichen danach gefolgten Win-Versionen nicht mehr gegeben.

[leo]

Das liegt wahrscheinlich an der Hardware. Es gibt immer weniger Mainboards mit echten COM-Ports. Viele sind nur noch emuliert und brauchen dann einen speziellen Windows-Treiber. Die DOS-Umgebung in Windows will aber einen direkten Zugriff und kann mit dem emulierten Port nichts anfangen. Das ist bei Windows XP schon genauso gewesen. Es gibt bei HP aber noch eine große Auswahl an PC's mit echten COM-Ports.