Nach der Installation des aktuellen Windows 10 Creators Update ist mir aufgefallen, dass meine virtuellen Maschinen in VMware Workstation ohne Netzwerkverbindung gestartet wurden. Ein kurzer Blick in den Virtual Network Editor zeigt, dass das Bridged-Network VMnet0 nicht mehr vorhanden ist. Beim Versuch ein neues Bridged-Network zu erstellen wurde mir folgende Fehlermeldung präsentiert:

Durch das Update scheinen wohl die notwendigen virtuellen Netzwerkadapter und Treiber durcheinander gekommen zu sein. Eine Lösung ist es VMware Workstation neu zu installieren. Viel einfacher und schneller: Im Virtual Network Editor die Option Restore Defaults nutzen. Diese installiert alle notwendigen Netzwerkschnittstellen neu und setzt die Konfiguration zurück. Danach ist auch das Bridged-Network VMnet0 wieder vorhanden.

Updates sind wichtig: Es gibt Fehlerbehebungen, gestopfte Sicherheitslücken und eventuell sogar neue Funktion. Bei VMware Workstation ist das Update aber jedes Mal aufs Neue ein kleiner Kampf.

Während beim Update zwar alle Einstellungen erhalten bleiben, muss zumindest einer der vmrun nutzen möchte, sich jedes Mal erneut um das Modifizieren des VIX Wrappers kümmern (siehe vmrun von VMWare Workstation 12 kann sich nicht mit dem Host verbinden) und auch dann ist die korrekte Funktionsweise nicht immer gewährleistet (siehe vmrun funktioniert nach Update auf VMware Workstation 12.5.2 nicht mehr zuverlässig).

Nach der Aktualisierung meiner Installation von VMware Workstation auf die neuste verfügbare Version 12.5.2, habe ich wieder einmal getestet ob vmrun wie eigentlich zu erwarten funktioniert.

Leider ist das noch immer nicht der Fall und daher muss auch weiterhin das Skrpting-Interface VMware VIX wie im Artikel vmrun von VMWare Workstation 12 kann sich nicht mit dem Host verbinden beschrieben modifiziert werden.

Allerdings erhalte ich auch danach immer noch sporadische aber durchaus reproduzierbar Fehlermeldungen, die auf Fehler in der Kommunikation hindeuten:

VMware erlaubt es mit sogenannten thin-provisined Virtual Maschine Disks (VMDK-Dateien) virtuelle Festplatten zu erstellen, die den Speicherplatz der angegebene Festplattengröße nicht sofort am Hostsystem reservieren, sondern nur bei Bedarf bis zur maximal angegebenen Größe anwachsen. Bei vielen Festplattenaktivitäten mit großen Dateien oder auch regelmäßigen Windows-Udpates wachsen diese VMDK-Dateien mit der Zeit an, obwohl in der virtuellen Maschine in Wirklichkeit nur ein Bruchteil des Festplattenspeicherplatzes genutzt wird, als jener der am Hostsystem durch die VMDK belegt ist.

Um nicht belegten aber reservierten Speicherplatz einer VMDK-Datei auf dem Host freizugeben, muss eine Shrink-Aktion aus der laufenden virtuellen Maschine heraus über die installierten VMware Tools gestartet werden. Das Tool wird über die Kommandozeile bedient und ist je nach Gastbetriebssystem etwas anders zu nutzen:

Wer unter VMWare mit langsamen Netzwerkzugriffen, sowohl aus der virtuellen Maschine heraus oder auch bei Zugriff von außen auf die virtuelle Maschine, zu kämpfen hat, dem sollen meine Erfahrungen und Anhaltspunkte als Hilfestellung dienen.

Typ der virtuellen Netzwerkkarte

VMWare kann unterschiedliche Hardware-Netzwerkadapter emulieren, die unterschiedliche Unterstützung der zu virtualisierenden Betriebssysteme erfahren, aber vor allem auch unterschiedliche Performance aufweisen.

Der Kartentyp kann durch Manipulation der Konfigurationsdatei .vmx geändert werden. Achten Sie darauf, dass die Netzwerkadapter danach in den virtualisierten Systemen erneut installiert werden müssen.

Die folgenden Adapter stehen zur Auswahl:

• e1000: Standard-Intel-Adapter (native Betriebssystemunterstützung, solide Performance)

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:

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

Für kleinere Server oder den Heimgebrauch ist nach wie vor VMWare Workstation für die Virtualisierung das Mittel der Wahl. Wer des Öfteren virtuelle Maschinen starten und beenden muss, um z.B. Backups zu machen, wird sich schnell nach einer Möglichkeit der Automatisierung dieser Vorgänge sehnen.

VMWare Workstation stellt dazu das Kommandozeilen-Tool vmrun zu Verfügung. Über dieses lassen sich sowohl lokal laufende VMs als auch auf entfernten Rechnern laufende VMs (Sharing) steuern.

vmrun

Das Tool liegt bei einer Windows-Installation unter C:\Program Files (x86)\VMware\VMware VIX\vmrun.exe bzw. auch unter C:\Program Files (x86)\VMware\VMware Workstation\vmrun.exe.

Aufbau der Befehle

Befehl für die Steuerung von lokalen VMs:

Im Gegensatz zu den Serverprodukten von VMWare gibt es in VMWare Workstation keine Möglichkeit sich eine Übersicht der aktuell verwendeten Ressourcen (Prozessorauslastung, Arbeitsspeicher, etc.) der laufenden virtuellen Maschinen anzeigen zu lassen. Findige Personen würden jetzt sagen: "Kein Problem, jede VMWare läuft als eigener Prozess und der Windows Taskmanager liefert mir die notwendigen Informationen." Das ist prinzipiell richtig, nur lassen sich, insofern mehrere virtuelle Maschinen gleichzeitig laufen, die einzelnen vmware-vmx.exe-Prozesse nicht so einfach einer virtuellen Maschine zuordnen.

Nach einem der letzten Windows Updates quittiert VMWare Workstation 9, auf meinem Windows 8.1-System, plötzlich den Start einer virtuellen Maschine mit folgender Fehlermeldung:

Bei mehr als 10GB verfügbaren RAM und zugewiesenen 2GB an die virtuelle Maschine eigentlich ein Ding der Unmöglichkeit. Eine kurze Google-Recherche und ein Blogeintrag von VMWare bringen Licht in die Sache. Das Windows-Update KB2995388 verursacht das beschriebene Problem und die vorgeschlagene Lösung von VMWare ist die Deinstallation des erwähnten Updates. Für sicherheitsbewusste Nutzer keine zufriedenstellende Lösung.

http://blogs.vmware.com/workstation/2014/10/workstation-10-issue-recent-microsoft-windows-8-1-update.html

In meinem Server stecken 2 Netzwerkkarten die im selben Netz hängen, um den Datentransfer der virtuellen Maschinen von dem mit dem physischen Host zu trennen und somit den virtuellen Maschinen immer vollen Netzwerkzugriff auch bei größeren Dateitransfers mit dem Host zu ermöglichen.

Gerade nach der Neuinstallation oder einem Update von VMWare Workstation fällt mir regelmäßig auf, dass die Geschwindigkeit der Netzwerkverbindung zu meinen virtuellen Maschinen massiv einbricht.

Das Problem liegt darin, dass im Virtual Network Editor für das verwendete Netzwerk VMnet0 (bridged) die Einstellung bei Bridged to auf Automatic gesetzt ist. Das Setzen einer dezidierten Netzwerkkarte behebt das Problem. Hier scheint VMWare Workstation Probleme bei der automatischen Zuordnung der Netzwerkkarte zu haben.