blog.bartlweb - a technologist's external brain

vmrun von VMWare Workstation 12 kann sich nicht mit dem Host verbinden

Nach dem Upgrade von VMWare Workstation 9 auf die aktuelle Version VMWare Workstation 12 haben meine Automatisierungsskripte mit vmrun (siehe: vmrun zur Automatisierung von VMWare Workstation nutzen) gestreikt. Es war mir nicht mehr möglich meine geteilten virtuellen Maschinen (Shared VMs) über vmrun zu steuern. Stattdessen erhielt ich bei jedem Verbindungsversuch nur die folgende Fehlermeldung zurück:

Unable to connect to host.
Error: The specified service provider was not found

Den Befehl mit Administratorrechten ausführen brachte keine Abhilfe und die Firewall hat weder vmrun noch die Authentifizierungs- bzw. Server-Dienste von VMWare Workstation blockiert. Nach langen Recherchen bin ich auf folgenden Blog-Artikel gestoßen, der die Lösung brachte: http://vcojot.blogspot.ca/2015/11/workaround-for-vmrun-under-vmware.html

Lösung

Anscheinend hat VMWare in der aktuellen Version die Skripting-Schnittstelle bzw. das dazu notwendige Tool vmrun vermurkst. Tatsächlich ist die Skriptingschnittstelle allerdings so flexibel, dass sich dort auch noch funktionierende Libraries von Vorgängerversionen einbinden lassen.

  1. Laden Sie von der Website von VMWare die letzte Version von VMWare Workstation 11 herunter (dort funktioniert vmrun noch wie es sollte) und installieren Sie diese am besten in einer virtuellen Maschine oder auf einem anderen Rechner als jenen auf dem die aktuelle defekte Version von VMWare Workstation läuft.
  2. Kopieren Sie den Ordner Workstation-11.0.0-and-vSphere-6.0.0 aus dem Ordner C:\Program Files (x86)\VMware\VMware VIX von der 11er-Installation in die 12er-Installation.
  3. Bearbeiten Sie die Datei vixwrapper-config.txt im Ordner C:\Program Files (x86)\VMware\VMware VIX in der 12er-Installation und fügen Sie zum Abschnitt # Workstation 12.0.0 und # Workstation 12.0.1 die Zeile ws-shared 19  none  12.0.1 Workstation-11.0.0-and-vSphere-6.0.0 hinzu.
  4. Ab sofort sollte der Zugriff wieder reibungslos funktionieren.

Die gesamte Datei vixwrapper-config.txt sieht dann wie folgt aus:

#@Version-Info
#
# VixAllProducts revision mapping
#
# This file translates product version specifications into the appropriate Vix
# implementations.
#
# Each @Version-Info line has 5 white-space seperated entries:
#
#    provider-type: ws, esx, viserver, etc
#    apiVersion: the apiVersion supported, as passed in from VixHost_Connect()
#    ipc-type: none, vmdb, vmodl, cim
#    product-version: the product version string
#
#    implementation-directory: the path to the library that implements the
#          version described by the first 4 parameters
#
#
# The configuration is based on the first 4 fields, which describe
# the product.  The 5th field is the location.  To force it to try
# multiple location, the same configuration can be repeated.  Note that
# list is built in LIFO order, so the latest entry in the configuration
# will be the first used.  If for some reason that value fails, it will
# continue through any other matches.
 
# Workstation 12.0.0
ws        19  vmdb  12.0.0 Workstation-12.0.0
player    19  vmdb  12.0.0 Workstation-12.0.0
ws-shared 19  none  12.0.0 Workstation-11.0.0-and-vSphere-6.0.0
 
# Workstation 12.0.1
ws        19  vmdb  12.0.1 Workstation-12.0.0
player    19  vmdb  12.0.1 Workstation-12.0.0
ws-shared 19  none  12.0.0 Workstation-11.0.0-and-vSphere-6.0.0
 
# Workstation 12.1.0
ws        19  vmdb  12.1.0 Workstation-12.0.0
player    19  vmdb  12.1.0 Workstation-12.0.0
ws-shared 19  none  12.0.0 Workstation-11.0.0-and-vSphere-6.0.0
 
# EOF

Zugriffsberechtigungen setzen

So ganz wollte der Zugriff dann immer noch nicht klappen. Hin und wieder wurden meine Verbindungsversuche abgelehnt, mit der Begründung der Zugriff auf die virtuelle Maschine ist nicht möglich (Die genaue Fehlermeldung muss ich mangels Reproduzierbarkeit schuldig bleiben).

Die Verbindung habe ich bisher mit den Zugangsdaten des Adminstrator-Accounts, der in VMWare automatisch vollen Zugriff auf die Sharing-Funktionalität hat, hergestellt. Abhilfe hat das Erstellen eines eignenen Windows-Benutzers für den Zugriff auf VMWare Workstation gebracht. Diesen müssen Sie im Punkt Permissions... des Kontextmenüs von Shared VMs hinzufügen und mit den entsprechenden Rechten ausstatten. Teilweise konnte ich das Fehlschlagen des Zugriffs über vmrun auch damit in Verbindung bringen, dass die GUI der VM zum Zeitpunkt des Ausführens des Befehls gerade in der geöffneten Konsole von VMWare Workstation aktiv gewesen ist.

Dieser Artikel hat dir deinen Tag gerettet?
... und mühevolles Probieren, Recherchieren und damit Stunden an Zeit gespart? ... oder einfach nur dein Problem gelöst?

Dann würde ich mich freuen, wenn Du meine Zeit für die Erstellung dieses Blogartikels mit einer kleinen Spende honorierst:

Kommentare

Noch kein Kommentar vorhanden.
Sei der Erste - ich freue mich über deine Anmerkungen, Kritik und Fragen.

Kommentar schreiben

Deine E-Mailadresse wird nur für Benachrichtigungen und Rückfragen verwendet und wird nicht veröffentlicht.

Benachrichtigungen können jederzeit wieder abbestellt werden.

Bitte tippe die Zahlenkombination "2101" ein, nur dann kann ich deinen Kommentar entgegennehmen.

Bitte fülle dieses Feld nicht aus, nur dann kann ich deinen Kommentar entgegennehmen.