Schlagwort-Archive: vmware

Kommentar: VMware vSphere Web Client – Welch ein Fluch

Es war einmal vor langer Zeit, als einzig und allein der vSphere Client für Windows existierte, um einen ESX-Host bzw. einen vSphere Cluster zu verwalten. Und die vSphere-Admins waren glücklich und froh.

In dieser guten und glücklichen Zeit war der einzige Wermutstropfen, dass der vSphere Client nur für Microsoft Windows existierte und man als Linux-Liebhaber darauf angewiesen war, für die Administration der vSphere-Umgebung ein anderes Betriebssystem zu booten. Doch konnte dies die Freude nicht mindern. Und alle freuten sich und waren froh.

Doch in dieser Welt des Frohsinns und der Glückseligkeit gab es einen Dämon, dem dies alles gar nicht gefiel. Und dieser Dämon beeinflusste die guten Software-Engineers bei VMware und veranlasste sie dazu, den vSphere Web Client auf Basis von Flash zu entwickeln. Dies war der Beginn von dunklen Zeiten, welche bis in die Gegenwart anhalten.

Wer den vSphere Client kennt und sich den Web-Client ansieht, fragt sich vermutlich: „Warum? Warum investiert man Zeit, um so einen Mist zu entwickeln?“

Der vSphere Web Client ist langsam, kann nichts besser als der Fat-Client, bietet keine neuen Funktionen und basiert auf Flash. Letzteres sorgt dafür, dass es für Linux weiterhin keinen nutzbaren Client gibt. Doch den Göttern sei Dank, wir konnten weiterhin den althergebrachten Fat-Client nutzen und das Flash-Gespenst links liegen lassen. Und nachdem wir uns alle von dem Schreck erholten hatten, waren wir wieder glücklich und froh.

Dies gefiel dem Dämon nicht und so lies er verkünden, dass die Entwicklung des guten etablierten vSphere Client eingestellt wird, da man sich in Zukunft auf den Web-Client konzentrieren will. Dachte man anfangs noch an einen Aprilscherz, so wurden die Zeiten nun richtig finster. Denn der vSphere Web Client war immer noch mies und unbenutzbar. Der Unmut vieler Nutzer entlädt sich seit April 2014 in diesem Thread, welcher bis in die aktuelle Zeit Updates erfährt. Denn das Grundproblem ist immer noch nicht gelöst. Der vSphere Web Client ist immer noch nicht zu gebrauchen.

Um es noch einmal zusammenzufassen, der vSphere Web Client:

  • Ist so langsam, dass ich meinen Bart wachsen höre
  • Zwingt mich Flash auf meiner Admin-Workstation zu installieren, um ihn überhaupt nutzen zu können
  • Funktioniert nicht in allen Browsern
  • Funktioniert mal in dem einen, mal in dem anderen Browser (scheint mit der Mondphase zu wechseln)
  • Benötigt für volle Funktionalität das Client Integration Plugin (CIP), welches noch bescheidener funktioniert, als der Rest des Clients

Dieser Drecks-Web-Client raubt mir den letzten Nerv. Warum beschäftige ich mich überhaupt damit? Weil Client-Probleme im Web-Client reproduziert werden müssen, damit der VMware-Support helfen kann. Dies zieht einen Service Request nicht selten in die Länge, da man mit dem Support erstmal den Web-Client zum Laufen bringen muss, bevor man das eigentliche Problem analysieren kann. Eine echte Lösung gab es für den Client nie. Ein Workaround folgte dem Nächsten.

Unter uns, die Arbeit im VMware-Support kann doch auch keinen Spaß machen, wenn man so ein Drecks-Werkzeug supporten muss. Die Aussage eines Supporters dazu: „Ich gehe groß feiern, wenn der HTML5-Client endlich fertig ist.“

Der neue vSphere Client (HTML5) verspricht Licht am Ende des Tunnels. Die Kritik am verhassten vSphere Web Client scheint VMware erreicht zu haben. Doch offensichtlich muss es erst noch einmal schlechter werden, bevor es besser werden kann. Denn mit vSphere 6.5 hat uns VMware eine Version spendiert, in der sich der ausgereifte vSphere Client nicht mehr verwenden lässt, der vSphere Web Client immer noch totaler Mist ist und der vSphere Client (HTML5) noch nicht voll funktionsfähig ist. Super. Ganz toll. Statt eines gut funktionierenden Clients gibt es jetzt einen gammeligen und einen erst teilweise fertiggestellten.

Was bleibt ist die Hoffnung, dass der HTML5-Client in der nächsten vSphere-Version voll funktionsfähig ist und ein würdiger Nachfolger des guten alten Clients wird, welchen VMware so lieblos sterben lies. Und vielleicht kommt das VMware-Marketing auf der Suche nach Innovationen dann ja auf die Idee, einen schnellen, stabilen Fat-Client zu entwickeln. Und damit sind wir Admins wieder glücklich und zufrieden, bis ans Ende unserer (Arbeits-)Tage.

TLDR;

VMware vSphere ist ein gutes Produkt. Auch im Fall von Störungen in der IT-Infrastruktur lässt einen diese Lösung nur selten im Stich. Virtuelle Maschinen werden bis zuletzt korrekt ausgeführt, während der sie umgebene Rest schon am Boden liegt.

Warum das Unternehmen die Admins über die letzten Jahre mit einem vSphere Web Client straft, der einem jeglichen Spaß an der Arbeit nimmt, wird vielleicht für immer ein Rätsel bleiben.

Hoffentlich bekommt das Unternehmen mit dem neuen vSphere Client (HTML5) endlich die Kurve. Denn die Mitbewerber haben bereits aufgeschlossen und sind einen Blick wert, wenn einem bei Nutzung der Client-Anwendung übel wird.

Nun, wo der Frust einmal raus ist, geht es mir schon besser und ich wünsche euch ein schönes und erholsames Wochenende.

vSphere PowerCLI: Snapshots nach Namen suchen und löschen

In diesem Beitrag möchte ich kurz dokumentieren, wie vSphere Snapshots mit Hilfe der PowerCLI nach Namen gesucht und gelöscht werden können.

Anwendungsfall

Beruflich betreue ich mehrere vSphere-Cluster mit einigen hundert virtuellen Maschinen (VMs). Um diese VMs zu sichern, kommt eine Image-Backup-Software zum Einsatz. Diese erstellt zum Zeitpunkt der Sicherung von jeder VM einen Snapshot, sichert die zur VM gehörenden Dateien und löscht den Snapshot anschließend wieder.

Läuft es mal nicht so gut und das Backup wird unterbrochen oder schlägt fehl, werden diese Snapshots nicht immer von allen VMs entfernt. Diese liegengebliebenen Snapshots von Hand suchen und löschen zu müssen, macht keinen Spaß. Zum Glück lässt sich diese Aufgabe automatisieren.

Alle Snapshots mit einem bestimmten Namen löschen

Mit der folgenden Befehlszeile wird der verbundene vCenter Server angewiesen, alle Snapshots, die dem spezifizierten Namensmuster entsprechen, zu löschen:

Get-VM | Get-Snapshot | Where {$_.Name -like "SNAPSHOTNAME*"} | Remove-Snapshot -Confirm:$false

Es wird dabei immer ein Snapshots nach dem anderen gelöscht. Dies kann durch Angabe des Parameters RunAsync beschleunigt werden. Es ist jedoch zu beachten, dass durch die Parallelisierung eine hohe I/O-Last im Storage erzeugt wird. Damit besteht das Risiko, den gesamten Cluster lahmzulegen.

Möchte man statt des Namens des Snapshots dessen Beschreibung verwenden, ist dies mit folgendem Befehl ebenfalls möglich:

get-vm | get-snapshot | where {$_.Description -match "Snapshot generated for backup"}| Remove-Snapshot -Confirm:$false

Quellen und weiterführende Links

Installation von VMware Tools in einer Ubuntu VM

Um den Netzwerkadapter VMXNET31 in einem virtuellen Ubuntu verwenden zu können, müssen die VMware Tools installiert sein.

Dieser Artikel beschreibt zwei Methoden, wie dies getan werden kann. Ich gehe dabei ausschließlich auf die Installation unter Verwendung der Kommandozeile (CLI) ein.

Methode 1 – Open-VM-Tools

Dieser Abschnitt basiert auf dem VMware Knowledge Base Artikel KB20738032.

Bei den open-vm-tools handelt es sich um die Open Source Implementierung der VMware Tools. Die Vorteile dieser Implementierung sind:

  • Die Open-VM-Tools sind in den offiziellen Paketquellen von Ubuntu enthalten. Dadurch wird das Deployment von virtuellen Ubuntu VMs entschieden vereinfacht. Die Installation kann direkt aus den Quellen durchgeführt werden. Es muss nicht auf separate Quellen zurückgegriffen werden.
  • Keine Downtime für das Update der VMware Tools. Das Paket open-vm-tools wird automatisch über die Paketverwaltung aktualisiert.
  • Keine Kompatibilitätsprüfung erforderlich. Aus den Paketquellen wird automatisch das zum Betriebssystem passende Paket installiert.

Die Installation der Tools ist denkbar einfach und geschieht z.B. mittels:

sudo apt-get install open-vm-tools

VMware empfiehlt ausdrücklich die Verwendung der Open-VM-Tools.3 Wer sich über den aktuellen Entwicklungsstand der Open-VM-Tools informieren möchte, kann dies auch direkt auf GitHub tun. 4

Methode 2

Diese Methode verbleibt der Vollständigkeit halber im Artikel. Es wird ausdrücklich Methode 1, wegen der dort genannten Vorteile, empfohlen.

Dieser Abschnitt basiert auf dem VMware Knowledge Base Artikel KB10225255 und führt die einzelnen Schritte auf, die benötigt werden, um die VMware-Tools in einer VM mit Ubuntu zu installieren.

Abhängigkeiten der VMware-Tools

Um die VMware Tools installieren zu können, müssen folgende Pakete auf dem System installiert sein:

  • gcc
  • binutils
  • make
  • kernel sources

Installation auf der Kommandozeile

Als Erstes wird ein Rechtsklick auf die VM in der Bestandsliste des vSphere-Clients ausgeführt. Aus dem Kontextmenü wählt man „Gast -> VMware Tools installieren/aktualisieren“.

In der laufenden Ubuntu-VM werden nun die folgenden Kommandos ausgeführt:

sudo mkdir /mnt/cdrom
sudo mount /dev/cdrom /mnt/cdrom
tar xzvf /mnt/cdrom/VMwareTools-.tar.gz -C /tmp/
cd /tmp/vmware-tools/distrib/
sudo ./vmware-install.pl -d

Nach Abschluss der Installation ist ein Neustart auszuführen. Nun kann anstatt des veralteten E1000 auch der aktuelle Netzwerkadapter VMXNET3 zur VM hinzugefügt und verwendet werden.

VirtualBox VDI Datei in VMware VMDK Datei konvertieren

Schon 2012 habe ich im Artikel Virtualbox und das Open Virtualization Format darüber berichtet, dass sich ins OVF bzw. OVA Format exportierte VMs nicht in einer VMware vSphere Umgebung importieren lassen. Leider hat sich an diesem Umstand bis heute nichts geändert. Daher habe ich mir einen neuen Weg gesucht, um VMs von Virtualbox nach vSphere zu migrieren.

Auf dem ESXi ist zuerst eine neue virtuelle Maschine ohne Festplatte zu erstellen. Um nun die VDI aus VirtualBox nutzen zu können, muss diese zuerst in eine VMDK Datei konvertiert werden.

Eine Lösung fand ich in diesem englischsprachigen Blogpost. Zur Konvertierung nutzen wir das Tool „vboxmanage“ auf der Komandozeile. Der folgende Codeschnipsel zeigt einen Beispielaufruf:

C:\Program Files\Oracle\VirtualBox>vboxmanage clonehd "Pfad zur VDI Datei\quelldatei.vdi" "Pfad zur VDI Datei"\zieldatei.vmdk --format VMDK --variant Standard
vditovmdk

Beispiel einer Konvertierung von VirtualBox zu VMware.

Mit dem obigen Aufruf wird im selben Verzeichnis, in dem die VDI Datei liegt eine VMDK Datei erzeugt. Diese kann nun in den Datastore eines ESXi Hypervisor hochgeladen und als virtuelle Festplatte einer VM hinzugefügt werden.

Anschließend kann man die VM starten und sie weiter nutzen.

Update 16.3.2014: Hier kommt ein wichtiger Nachtrag aus der Praxis. Er soll ich davor bewahren, die gleichen Erfahrungen wie ich machen zu müssen. Die oben beschriebene Migration von VirtualBox zu vSphere führte zu einem wahren Härtetest von vSphere HA.

Nach dem Start der VM im vSphere Cluster sollten im nächsten Schritt die VBox Guest Additions deinstalliert und die VMware Tools installiert werden. Doch soweit bin ich gar nicht erst bekommen.

Denn die migrierte VM hängte sich auf und lies sich nicht mehr steuern. Auch ein Zurücksetzen der VM zeigte keinerlei Wirkung. Nur kurze Zeit später stürzte der ganze Hypervisor ab und der Cluster führte einen Failover durch. Dadurch wurde leider auch die fehlerhafte VM auf einen anderen Host übertragen und brachte diesen ebenfalls zum Absturz, bevor ich die VM stoppen und löschen konnte.

Zwei Hypervisor-Abstürze innerhalb von 30 Minuten sind eindeutig zwei zu viel. Für den VMware Support war dieses Verhalten ebenfalls neu. Hier bekam ich den Rat zukünftig die VirtualBox Guest Additions zu deinstallieren, bevor ich die VDI Datei konvertiere.

Für unseren Betrieb haben wir hingegen festgelegt keine weiteren VMs auf diesem Weg zu migrieren. Wir werden VMs nach einer Testphase durch Neuinstallation ins Cluster überführen. So können wir durch Konvertierung verursachte Fehler ausschließen und erstellte Dokumentationen überprüfen, indem wir das System nach der Dokumentation erneut bereitstellen.

vSphere: Virtuelle Festplatte klonen

Möchte man mehrere gleichartige Server bereitsellen, lässt sich die Bereitstellung beschleunigen, indem man einen Server installiert und die Festplatte klont.

Man erstellt dazu weitere VMs ohne Festplatte über den vSphere Client. Eine VMDK kann über die SSH-Shell mit folgendem Befehl geklont werden:

vmkfstools -i /path/old/vm/foo.vmdk /path/new/foo.vmdk