Die Foren-SW läuft schon geraume Zeit ohne erkennbare Probleme. Sollte etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!

Erfahrungsbericht: Herunterfahren als Dienst gestarteter VM

Hilfe bei Problemen mit der Installation und Benutzung der VMware Workstation und VMware Workstation Pro.

Moderatoren: continuum, irix, Dayworker

Member
Beiträge: 42
Registriert: 20.10.2005, 16:54

Erfahrungsbericht: Herunterfahren als Dienst gestarteter VM

Beitragvon tomasf » 20.10.2005, 19:14

HOSTSYSTEM: WINDOWS mit VM Workstation 5.0

VM Workstation als Dienst:
Pro:

-Server Funktionalität wie GSX
-Performance der VM-Workstation
-Remote-Konsole mit RDP /console
Kontra:
- keine VMware Scripting API wie GSX
Problem:
- Herunterfahren der Guest bei Stromausfall etc.

In http://www.vmaschinen.de/newsletter/vm_als_dienst.pdf hat Sven Ahnert den Weg beschrieben, VM Workstation als Dienst zu starten. Bemerkenswert ist die Eigenschaft:
Beim Abmelden läuft die VM weiter. Beim nächsten Anmelden ist der Bildschirm wieder da. Man kann auch noch an der Konsole weitere VM-Workstation (als zusätzliche Karteikarte) starten, sich abmelden und die laufen auch weiter!

Weiterhin kann mit dem RDP-Parameter %SystemRoot%\system32\mstsc.exe /console die Remote-Console (bei XP/W2K3 etc) im Netzwerk herübergeholt werden.

Die Einrichtung des Dienstes geht am bequemsten mit der nicht mehr unterstützten Freeware FireDaemon Lite. Zum Download einfach googeln nach:
FireDaemon-Lite-1_6-GA.exe -firedaemon.com

vmstart.cmd anlegen (wie von Sven Ahnert beschrieben) und als Dienst aktivieren.
Hinweis: Auf der zweiten Karteikarte von FireDaemon
-den Schalter "Interact with Desktop" aktivieren
-Show Window: normal
-Start Up Mode: automatic
-Upon Program Exit: No Action

alternativ auch in W2K3 einfach mit sc.exe:

Code: Alles auswählen

C:\>sc
BESCHREIBUNG:
        SC ist ein Befehlszeilenprogramm für die Kommunikation mit dem
        Dienststeuerungs-Manager und Diensten.
SYNTAX:
        sc <Server> [Befehl] [Dienstname] <Option1> <Option2>...

C:\>sc create VMGUEST binpath= "vmstart.cmd" type= own type= interact


Jetzt kommt die entscheidende Frage "Wie kann man die Guests herunterfahren, wenn der Host herunterfährt?"
Antwort: Ich habe dafür keine Lösung gefunden!

Die VM läuft wegen des Dienstes auf dem Systemkonto. Ein Cmd.exe wird mit "vmrun list" keine (!) laufenden VM sehen.
Dankbarerweise laufen die Shutdown-Scripte des Host auf dem Systemkonto!
Einfach Script ablegen in C:\WINDOWS\system32\GroupPolicy\Machine\Scripts\Shutdown
und mit "Start/Ausführen.../ gpedit.msc / Computerkonfiguration / Windows-Einstellungen / Scripts" das Script zum Herunterfahren zuordnen.

Jetzt beginnen die Probleme! Nachfolgend Listing einer CMD.exe, die als Shutdown-Script zugeordnet wird.

Code: Alles auswählen

C:\>whoami
nt-autorität\system

... wie zu erwarten

jetzt ein erster Test

Code: Alles auswählen

C:\>"C:\VMware Workstation\vmrun.exe" stop E:\VMWare\winnetstandard.vmx
Powered Off, result: The operation was successful

...der Schein trügt, da beim Aufruf "vmrun.exe stop" vom Systemkonto das Gastsystem immer hart beendet und nicht heruntergefahren wird (auch wenn es vom anderen Konto prima funktioniert)

alternativ:

Code: Alles auswählen

C:\>"C:\VMware Workstation\vmrun.exe" suspend E:\VMWare\winnetstandard.vmx
Suspend, result: The operation was successful

...das hat prima funktioniert - ist aber kein Shutdown

jetzt ein Versuch mit PsShutdown v2.50 von Sysinternals:

Code: Alles auswählen

C:\>C:\util\psshutdown.exe \\GUESTVM -u User -p Password -s -t 3
Couldn't access GUESTVM:
Zugriff verweigert

... die Authentifizierung geht leider nicht vom Systemkonto aus

jetzt ein Test mit den Windows-Bordmittel shutdown.exe:

Code: Alles auswählen

C:\>shutdown
HOSTPC: Das System konnte die eingegebene Umgebungsoption nicht finden.(203)

... shutdown.exe arbeitet nicht unter einem Systemkonto. (Shutdown.exe kann auch keine Passwörter mit Parameter übergeben)

Hat noch jemand eine Idee, wie die VM heruntergefahren werden können, wenn auf dem Host keine Konsole läuft und der Host heruntergefahren wird (z.B. bei Stromausfall)?

Member
Beiträge: 152
Registriert: 17.06.2005, 08:18

Beitragvon ioman » 24.10.2005, 07:23

Hast Du schon mal versucht den FireDaemon Dienst als anderer User laufen zu lassen?
Verwaltung->Dienste->Fire...->Anmelden->Anmelden als "Dieses Konto" (Username/Kennwort angeben)

Dann sollte auch ein Shutdown funktionieren.

Vielleicht hilfts.

Gruß
ioman

Member
Beiträge: 42
Registriert: 20.10.2005, 16:54

Beitragvon tomasf » 25.10.2005, 00:44

ioman hat geschrieben:Verwaltung->Dienste->Fire...->Anmelden->Anmelden als "Dieses Konto" (Username/Kennwort angeben)

Leider verliert man dann die Eigenschaft "Datenaustausch zwischen Dienst und Desktop zulassen", d.h. das VMware-Fenster ist unerreichbar.
Das ist aber gerade das entscheidende Feature, wenn man VMware als Dienst startet ;-(
Kommunikation Dienst<->Desktop geht nur mit dem Systemkonto.

Als Workaround wäre noch die kommerzielle Version von FireDaemon-Pro (ab Version 1.7) im Angebot. Diese kann auch bei Kontoanmeldung einen Datenaustausch zwischen Dienst und Desktop zulassen.
Dazu hängt sich Firedaemon an den Dienst an:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DienstXYZ]
"ImagePath"="...Firedaemon.exe -s"

Experte
Beiträge: 1425
Registriert: 11.08.2004, 17:08
Wohnort: Paderborn

Beitragvon MSueper » 25.10.2005, 17:53

Der Dienst implementiert doch eine VM, die VM wird nicht "heruntergefahren" sondern "gekillt", wenn der Dienst beendet wird.
Du müsstest also immer eine Verbindung zum Gast aufbauen und zunächst den stoppen, dann den Service.

Vorschlag:
installier im Gast einen sshd, erzeuge einen Key ohne Passphrase und logge Dich mit diesem ein und rufe im Gast "shutdown" auf. Cygwin bietet ein shutdown auch für Windows an.
Den ganzen Vorgang kann man als Batch-File auf den Desktop packen.

Member
Beiträge: 383
Registriert: 03.10.2005, 03:29

Beitragvon al!ve » 26.10.2005, 00:14

Leider verliert man dann die Eigenschaft "Datenaustausch zwischen Dienst und Desktop zulassen", d.h. das VMware-Fenster ist unerreichbar.
Das ist aber gerade das entscheidende Feature, wenn man VMware als Dienst startet ;-(

könntest du das evtl kurz erklären? ob ein am system angemeldeter benutzer das vmware fenster sieht oder nicht tut doch vmware nichts. gut, die konfiguration per mausclick wäre nur möglich, wenn ich den vmware-dienst prozess abschieße, dann vmwre per hand neu starte, alle einstellungen mache, vmware per hand schließe und den vmware dienst neu starte möglich. wenn ich aber meinetwegen meine platten die ich in die vm einbinden will auf nem anderen rechner erzeuge und dann per lan rüber schiebe und meine einstellungen dann im jeweiligen .vmx file per texteditor mache spielt das ja keine rolle. solange ich aber für die konfiguration auf das fenster verzichten kann -- auch eine änderung der konfiguration über ein webinterface inkl. start/stop/restart/suspend buttons ist ohne große probleme realisierbar -- kann ich doch beruhigt nen beliebigen anderes konto nehmen. ich könnte mir sogar für jede vm n eigenes konto anlegen, dann kann ich auch bei mehreren vms die ja jeweils als prozess der dummerweise nur "vmware-vmx.exe" heißt laufen unterscheiden welcher prozess zu welcher vm gehört, weil eben der angemeldete benutzer ein anderer ist.

alternativ könnte jemand mal ne wächter anweisung schreiben der quasi als vmstart.exe wrapper fungiert (was start und stop angeht und suspend angeht) aber seine instruktionen nicht über die console bezieht sondern meinetwegen alle 10ms prüft, welchen zustand ein entsprechender dienst gerade enthält.

config-file könnte man als xml oder sowas realisieren, dann könnte der benutzer bequem im config-file des wächter prozesses zuordnungen zwischen
- dienstname
- vmware-file
- startscript für die konkrete vm
- stopscript
- suspendscript
eintragen.

vorteil daran für mich: ich könnte endlich die vms per "net start" und "net stop" anhalten und weiter laufen lassen.

vorteil für den threadersteller: der wächterprozess kann unter einem beliebigen konto laufen, hat damit auch die möglichkeit, das windows shutdown zu verwenden und trotzdem bleibt das vm fenster sichtbar, die vm selbst beruhigt unter system mit dem parameter "datenaustausch mit lokal" laufen darf.


wer zu viel zeit hat darf sich mal ans tippen machen.
große schwierigkeiten seh ich da jetzt eigentlich keine.
- xml file für die konfiguration parsen
- status des jweiligen dienstes auslesen
- anhand des statuses ein im config-file definiertes script ausführen

was mir da schwierigkeiten bereiten würde wäre die tatsache dass diese wächter ansendung selbst ja als dienst arbeiten müsste, wobei ich da durchaus damit leben könnte, wenn man das per windows zusatz tools genauso wie die vm selbst als dienst einbinden müsste.


ein solches script könnte aber auch schon existieren, da die anwendung wenn man es wie gerade beschrieben nicht auf vmware beschränkt sondern algemein formuliert sicher an mehreren stellen einsetzen kann. die möglichkeit dass jemand vor mir auf die idee gekommen ist besteht also.

Member
Beiträge: 152
Registriert: 17.06.2005, 08:18

Beitragvon ioman » 26.10.2005, 07:19

al!ve hat geschrieben:alternativ könnte jemand mal ne wächter anweisung schreiben der quasi als vmstart.exe wrapper fungiert (was start und stop angeht und suspend angeht) aber seine instruktionen nicht über die console bezieht sondern meinetwegen alle 10ms prüft, welchen zustand ein entsprechender dienst gerade enthält.


Aber was willst Du damit erreichen? Wenn einer Deiner VMWare Dienste beendet wird, dann kannst Du ja kein Script mehr ausführen, da die VM hart abgeschalten wird?!? Oder hab ich Dich da falsch verstanden?

@tomasf:
Da hast Du recht mit dem Kommunikation<->Desktop Problem.
Es gibt aber ein paar Workarounds :
- Wie Du schon geschrieben hast die Pro Version von Firedaemon kaufen
- Selber so einen Dienst schreiben (ist nicht so schwer ;-))
- Oder aber nicht den VMWare Dienst beenden sondern einen neuen Dienst erstellen der mit rechten des angelegten Benutzers läuft und diesen über die Grouppol automatisch beenden lassen bei abmeldung. Dieser Dienst benötigt keine Desktop Kommunikation sondern muss nur :
- shutdown für den gast aufrufen...
- warten

Wäre mal ein Versuch wert.

Gruß
ioman

Member
Beiträge: 42
Registriert: 20.10.2005, 16:54

Beitragvon tomasf » 26.10.2005, 21:25

Kurz bevor ich es mit SSH versuchen wollte, habe ich eine schlanke Lösung gefunden.
Es war der klassische Fehler :oops: bei psshutdown muss in diesem Fall der Username vollständig angegeben werden:

Nachfolgend noch einmal die falsche und richtige Variante:

Code: Alles auswählen

C:\>whoami
nt-autorität\system

C:\>psshutdown.exe \\GUESTVM -u User -p Password -s -t 3
Couldn't access GUESTVM:
Zugriff verweigert

C:\>psshutdown.exe \\GUESTVM -u GUESTVM\User -p Password -s -t 3
Copyright (C) 1999-2005 Mark Russinovich Sysinternals - www.sysinternals.com

GUESTVM is scheduled to shut down in 00:00:03.

Beim Experimentieren habe ich noch eine andere Lösung gefunden, wie man solche Authentifizierungsprobleme vom "Local System Account" umgeht (zB für Befehle, die keine Passwordübergabe kennen).

Code: Alles auswählen

C:\>whoami
nt-autorität\system

C:\>net use \\GUESTVM\Freigabe Passwort /user: GUESTVM\User_Name
Der Befehl wurde erfolgreich ausgeführt.

C:\>psshutdown.exe \\GUESTVM -s -t 3
Copyright (C) 1999-2005 Mark Russinovich Sysinternals - www.sysinternals.com

GUESTVM is scheduled to shut down in 00:00:03.


Wenn man jetzt der GUESTVM im Shutdownscript noch etwas Zeit zum Herunterfahren geben will:

Code: Alles auswählen

C:\>ping -n 15 localhost  > nul

Danke an Euch für die Hilfe :-)


Zurück zu „VMware Workstation und VMware Workstation Pro“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 0 Gäste