Die Tage kam ein Kollege auf mich zu, „Du, ich hab da ne VM die ich nicht mehr einschalten kann.“ Des Weiteren zeigte vSphere an dass für die VM eine Konsolidierung der Snapshots nötig sei, was mit der gleichen Fehlermeldung fehl schlug.
Failed to open ‚/vmfs/volumes/datastore/vm/vm-000004.vmdk‘ with flags 0xa The system cannot find the file specified (25).
Sie beschwerte sich dass eine .vmdk-Datei nicht vorhanden sei, ein kurzer Blick auf den Datastore zeigte jedoch dass die Datei vorhanden war.
Wie ich gerade feststellen musste funktioniert das Client Integration Plugin für den vSphere Web Client nicht mit der neuen 64bit-Version von Chrome. Bis eine passende Version des Plugins verfügbar ist muss also, wer die 64bit-Version nutzen möchte, entweder damit leben dass ein paar Funktionen nicht funktionieren, den Web Client in einem anderen Browser nutzen oder stattdessen den klassischen vSphere-Client verwenden.
Betroffene Funktionen die ohne das Client Integration Plugin im Web Client nicht funktionieren:
anmelden mit Windows-Sitzungsdaten
Zugriff auf die Konsole der VM
das Verbinden von lokalen .iso-Dateien und optische Laufwerken
Nachdem ich jetzt das zweite Mal bei einer Komplettabschaltung vom Rechenzentrum aufgrund von Arbeiten an der Stromversorgung beteiligt war schreibe ich mal ein paar Notizen dafür herunter.
Bei einer Virtuellen Maschine hatte ich nach dem Umzug von ESXi 4.1 auf ESXi 5.1 Probleme die VMware Tools zu aktualisieren. Sowohl die automatische als auch die interaktive Installation schlug fehl, natürlich ohne hilfreiche Fehlermeldung.
Ich habe dann die Maschine von den alten Tools bereinigt indem ich wie in KB1012693 empfohlen setup64 /c ausgeführt habe, danach ließen sich die VMware Tools installieren. Leider kam dann bei der nächsten Anmeldung die nächste Überraschung:
Der Prozedureinsprungpunkt „GuestApp_OpenUrl“ wurde in der DLL „vmtools.dll“ nicht gefunden.
Mein erster Gedanke war „Das ist ja ne super Lösung, einfach die Tools aus dem Autostart rausschmeißen“, nach dem Motto Aus den Augen, aus dem Sinn. Anscheinend hat sich aber mit den neueren Tools die Datei geändert, die ausgeführt wird. Tatsächlich tauchen in der Registry an der Stelle auch zwei Einträge auf, der besagte den man löschen soll und ein weiterer, der auf vmtoolsd.exe -n vmusr zeigt. Dieser Eintrag ist korrekt und startet beim nächsten Anmelden auch brav dir VMware Tools.
Ich habe endlich meinen mittlerweile in die Jahre gekommenen alten Fileserver durch einen modernen Server ersetzt auf dem alles in einer ESXi-Umgebung laufen soll. Meine Wahl fiel auf den HP Proliant MicroServer N54L, den ich schon einmal in der Hand hatte und von dem ich recht begeistert war. Hier soll der Fileserver als VM laufen und ich habe die Möglichkeit je nach Bedarf weitere VMs anzulegen und wieder zu löschen, ein kleines Homelab sozusagen.
Die vier Festplatteneinschübe sollen ausschließlich Festplatten für Daten enthalten, also habe ich für das System und als Datastore für VMs eine zusätzliche 1,5 TB-Festplatte in den Schacht für das optische Laufwerk eingebaut. Zusätzlich zu dem eSATA-Anschluss auf der Rückseite befindet sich noch ein freier SATA-Anschluss auf dem Mainboard, so dass man dafür nur ein Kabel verlegen muss. Hier empfiehlt sich ein SATA-Kabel mit abgewinkeltem Stecker, wie man auf dem Foto sieht ist nicht wirklich viel Platz da. Ein Stromanschluss mit Molex-Stecker liegt schon bereit, dafür wird nur ein Adapter für den SATA-Stromanschluss benötigt (sowie ein Einbaurahmen auf 5,25″). ESXi 5.1 auf einem HP Proliant MicroServer N54L weiterlesen
Nachdem ich einen USB-Stick für die ESXi-Installation nach der Anleitung von VMware erstellt hatte konnte ich nicht davon booten. Ich bekam immer die Fehlermeldung
boot:
menu.c32 not a COM32R image
Keine Ahnung was die Ursache war, in diesem Blogbeitrag schrieb jemand einen Kommentar, dass neuere syslinux-Versionen problematisch seien (ich hatte meinen Stick mit syslinux 4.05 unter Mint Linux 13 erstellt). Mit der Version 494 von UNetbootin solle es gehen. Also probierte ich das aus und erstellte einfach mal einen Stick mit der angegebenen Version, aber ohne weitere Anpassungen zu machen die in dem Beitrag aufgelistet werden.
UNetbootin lief durch, ich habe den Stick in einen Rechner gesteckt, davon gebootet und siehe da, der Installer vom ESXi startet vollkommen problemlos. Die Methode hat auch noch den Vorteil dass man den Stick unter Windows erstellen kann und nicht unbedingt eine Linux-Installation zur Hand haben muss (was die Anleitung von VMware zwingend voraussetzt).
Update 07.10.2013
Mit Version 5.5 vom ESXi funktioniert diese Methode bei mir leider nicht mehr.
Seit gestern habe ich auf Einmal das Problem, dass mir der vSphere Client einfriert wenn ich beim Performance-Tab eines bestimmten ESXi Servers auf „Advanced“ klicke. Es passiert nur bei einem Host, bei den anderen ging es problemlos. Einen Hinweis zur Lösung fand ich in diesem Thread. Unter
c:\Users\<username>\AppData\Roaming\VMware
findet sich eine Datei vcenter.igd.fraunhofer.de-charts.xml. Nachdem ich diese Datei gelöscht und den vSphere-Client wieder gestartet hatte ging es schlagartig wieder. Es war nicht nötig weitere Dateien dort zu löschen.
Besonders interessant ist dieser Beitrag in dem Thread, der genau erklärt was die Ursache für das Problem ist.
Zur Zeit habe ich die Gelegenheit mit XenDesktop herumzuspielen. Die VM läuft auf einem ESXi 4.1 Server, sie wird mit Citrix XenDesktop gestreamt. Ich kann von Desktop, XenClient, Tablet oder sogar Handy aus darauf zugreifen und ihn nutzen. Das ganze funktioniert erstaunlich performant, selbst über eine UMTS-Verbindung.
Hier Windows 7 auf einem Asus Eee Pad Transformer:
![VMware vSphere: Install, Configure, Manage [V6] abgeschlossen](https://schneidr.de/wp-content/uploads/2016/02/cert_vsphere_6_install_configure_manage-825x510.png)
