VMware ESX auf ARM

- Lesezeit: 8 Minuten

Als Vorbereitung für meinen Einsteig in Ansible, wollte ich zunächst eine kleine Umgebung für die Virtualisierung Zuhause aufbauen, um dort später schmale VMs automatisiert auf- und abzubauen. Da ich beruflich viel mit VMware zu tun habe, lag es nahe dies mittels ESX zu bewerkstelligen. Mittlerweile läuft diese Software sogar auf einem Raspberry Pi, was auf der VMworld 2020 offiziell veröffentlicht wurde. Ganz so einfach war es dann aber doch nicht, weshalb ich dachte, ein Artikel hierzu wäre ganz passend.

Auf die eigentliche Installation auf dem Raspberry Pi werde ich nicht genauer eingehen, da es bereits etliche Artikel im Internet gibt, wobei mir die Anleitung von VMware selber, vollkommen ausgereicht hat. Über die offizielle Seite lassen sich die Softwarepakete und die Anleitung beziehen - hierfür wird ein VMware Account benötgt (kostenlos). Hinweis: Die Anleitung (PDF) befindet sich ebenfalls im Dropdown-Feld für den Download.

Sobald man ESX auf dem Pi4 laufen hat, sind natürlich einige Basiskonfigurationen nötig. Die meisten werden, so wie ich, zusätzlichen Storage für die VMs an den Pi anschließend wollen. Hier war für mich auch schon der erste Stolperstein: Mein Plan war es, einfach eine 256GB SDCard im Pi für den erweiterten Storage zu verwenden. Leider kann ESXi aber keine SD Karten lesen bzw. damit arbeiten. Alles muss über USB laufen. Daher habe die bereits gekaufte SDCard einfach mit einem USB Adapter (siehe Bild) angeschlossen.

Bei der Einrichtung des Storage bin ich auf mehrere Wege gestoßen. Die häufigste Lösung beinhaltet die Vorbereitung per Kommandozeile und partedUtil. Wie ich feststellen musste, ist dies aber gar nicht notwendig. Lediglich der USB arbitrator musste wie in den Beschreibungen deaktiviert werden, damit das Device erkannt wird. Dies erfolgt direkt auf dem Host:

/etc/init.d/usbarbitrator stop
chkconfig usbarbitrator off

Anschließend wurde die SDCard im Device-Management angezeigt und konnte eingerichtet werden.

Damit war der ESX Host auch bereits einsatzfähig und VMs ließen sich installieren.

Wie erwähnt ist es mein Ziel VMs vollautomatisch zu deployen. Die erste VM, welche später auch als Template dienen sollte, habe ich aber zunächst manuell per ISO Datei installiert. Als Basis diente eine Debian 10 minimal Installation.

Etwas tricky war hier dann auch die Installation der VMware-Tools, welche auf der VM gebaut (kompilliert) werden müssen. William Lam hat es in einem Artikel ausführlich beschrieben.

Nachdem die erste VM funktionsfähig war, ging es nun darum von dieser ein Template zu erzeugen, welches später für neue VMs genutzt werden kann. Und hier kommen wir zu dem größten Stolperstein: Der ESX Host alleine ist extrem limitiert was dies angeht. Für den vollen Funktionsumfang braucht man ein vCenter und vSphere - aber wer stellt sich sowas Zuhause hin? Vor allem für einen einzigen Raspberry Pi4.

Wie ihr euch nun aber vorstellen könnt, habe ich nicht so schnell aufgegeben.
Zunächst musste die VM exportiert und in den DataStore auf dem ESX wieder importiert werden:

Ich habe die Dateien hier ganz bewusst in vm00* umbenannt, um diese somit als Template zu kennzeichnen.

Auf der Webconsole ist man hiermit dann leider auch am Ende angekommen. Man könnte nun neue VMs auf Basis der VMDK erstellen - allerdings lässt sich als Quelle hier nur der eigene Rechner verwenden und nicht der DataStore (wieder ein Stolperstein). Also musste alles ab diesem Punkt über die Kommandozeile laufen. Aber...

Der ESX Host bietet out of the box auch auf der Kommandozeile kein ordentliches Set an Befehlen an. Man kommt also nicht drum, sich das ovftool herunterzuladen und auf den ESX Host zu kopieren. Mit diesem Tool ist es anschließend möglich neue VMs auf Basis der VMDK und OVF zu deployen. Natürlich stammt dieser Weg auch wieder von niemand geringerem als William Lam.

Um das Ganze dynamischer zu machen bzw. wie mit einem echten Template zu arbeiten, sind noch ein paar Vorbereitungen nötig. In meinem DataStore befindet sich wie oben zu sehen nun das Template "20210327-deb10-vm00-template" mit den benötigten Dateien. Die exportierte OVF muss extra angepasst werden (VM Name auf vm00 ändern, sowie die größe der vmdk und nvram Datei setzen).

Bei mir lief das ovftool auf Fehler, sofern ich nicht alle "<vmw:ExtraConfig" Zeilen entfernt hatte.

Dieses Verzeichnis dient als Basis und wird temporär vervielfältigt, angepasst, zur Erstellung der neuen VM verwendet und wieder gelöscht. Beispiel:

  1. Kopiere "20210327-deb10-vm00-template" nach "vm02"
  2. Benenne alle Dateien im Ordner "vm02" entsprechend um (vm00-0.vmdk nach vm02-0.vmdk usw.)
  3. Ändere überall in der Datei vm02.ovf "vm00" in "vm02" um

Sofern alles richtig geändert wurde, sollte ein

ovftool vm02.ovf

keine Fehler liefern, sondern die Informationen der VM bzw. ovf-Datei.
Das Deployen der VM erfolgt mit

ovftool -ds=DataStore1 vm02.ovf "vi://root:yourpassword@192.168.1.20"

Ein weiterer Stolperstein kann hier die Manifestdatei sein, welche die SHA1 Summen der Dateien beinhaltet. Entweder passt man diese an, oder lässt sie weg. Sofern die Anpassung nicht stimmt, schlägt das Deployment fehl. Daher habe ich auf die Nutzung der Manifestdatei verzichtet. Das ovftool spuckt hier nur eine Warnung aus, die aber ignoriert werden kann. Ich würde so übrigens nicht in einer produktiven Umgebung vorgehen ;)

Das letzte Problem war dann, dass die neue VM nicht starten konnte. Das ist ein bekannter Fehler, welcher sich beheben lässt, indem man die nvram-Datei aus dem Template erneut kopiert.

  1. Starte neue VM (Boot funktioniert nicht)
  2. Stoppe neue VM
  3. Lösche nvram-Datei der neuen VM
  4. nvram-Datei aus dem Template neu kopieren und wieder umbennen
  5. Starte neue VM (Boot sollte funktionieren)

Da das ganze nun natürlich noch automatisiert passieren sollte, habe ich hierzu ein schnelles kleines Script geschrieben.

Im nächsten Schritt geht es dann rüber zu Ansible und einem Weg, dieses Script zu nutzen...