Am 30. Oktober 2020 veröffentlichte VMware NSX-T Version 3.1 (Release Notes).
Upgrade von Version 3.0
Ich zeige hier den Ablauf des Upgrades von Version 3.0.x auf Version 3.1. Im gezeigten Bespiel wird eine Version 3.0.2 aktualisiert, jedoch ist der Ablauf für alle Versionen ab 3.0 gleich.
Voraussetzungen
Wir benötigen ein Upgrade Bundle (MUB) zur neuen Version aus dem Download Bereich von VMware.
Upgrade
Zunächst öffnen wir den NSX-T Manager und gehen über Lifecycle Management zu Upgrade. Dort sieht man wie im Bild unten dargestellt die aktuelle Version und startet den Prozess mit „Upgrade NSX“.
VMware vSphere 7 hat die Bearbeitung und Organisation von Templates stark vereinfacht, indem man diese in Content Libraries ablegen kann. Von dort läßt sich das Template ableiten oder aktualisieren.
Hat man noch herkömmliche Templates in vCenter, so kann man auch diese recht einfach in eine Content Library übertragen.
Das Template soll als neues Teplate in die Library übertragen werden.
Failed to export OVF package
Nach Klick auf OK wird der Fehler ausgegeben: „Failed to export OVF package“. In der Regel kommt eine zweite Meldung die schnell zur Ursache des Problems führt.
File ds:///vmfs/volumes/vsan:527a6824b9bfa7ad-36f48a2cd78b9685/1f40b55e-f88d-e569-9d66-002590bb2ed0/b02cb65d-e81b-49cb-a654-ef26ea21b2f7/ubuntu-20.04-live-server-amd64_5696e54c-c62a-4fa8-b007-0192a28ff53d.iso was not found
Interessant sind nur die letzten vier Worte: „iso was not found„. Die VM hatte ganz offensichtlich noch ein iso eingebunden, bevor sie zum Template konvertiert wurde. Das lässt sich schnell lösen, indem man das Template in eine VM verwandelt und in den Einstellungen das CD-ROM von Datastore ISO auf z.B. Client-Device umstellt. Danach die VM wieder zum Template konvertieren und den Vorgang erneut versuchen. Ohne eingebundenes ISO funktionier der Transfer fehlerfrei.
Aktualisierungen der vCenter Server Appliance (VCSA) gelingen in der Regel problemlos aus der VAMI Oberfläche. In seltenen Fällen kann es hier jedoch zu Problemen beim Update kommen. Kürzlich versuchte ich im Lab, die VCSA von Version 7.0.0 (16386335) auf 7.0.0 U1 (16858589) zu aktualisieren. Das Update wurde über ein lokal eingehängtes ISO gestartet. Es wurde zwar erkannt, dass ein Update verfügbar ist, jedoch scheiterte das Update gleich nach dem Start. Das im Link oben referenzierte Problem traf in diesem Fall jedoch nicht zu.
In solchen Fällen lohnt sich der Versuch über die VCSA Shell. Dazu muss diese zunächst in VAMI erlaubt werden, anschließend kann die Verbindung über SSH Client aufgebaut werden.
Wichtig ist hierbei, daß wir uns NICHT auf der BASH shell befinden. Falls dies so ist, können wir mit folgendem Befehl zurückkehren.
appliancesh
Im ersten Schritt werden die Update Pakete bereitgestellt. Das ISO sollte zu diesem Zeitpunkt eingebunden sein.
software-packages stage --iso --acceptEulas
Der Prozess prüft einige Parameter, wie Quell- und Zielversion und ob das ISO eingebunden ist.
software-packages list --staged
Mit dem oben dargestellten Befehl sehen wir Informationen zum bereitgestellten Paket.
Wenn alles stimmt, kann der Updateprozess gestartet werden.
software-packages install --staged
Der Vorgang lief ohne Probleme bis zum Ende durch und aktualisierte die Appliance auf Version 7.0 U1.
VMware vSphere und weitere Produkte aus dem Ökosystem sind sehr stark abhängig von korrekter Namensauflösung im DNS. Ohne DNS geht in der virtuellen Welt gar nichts. Das führt so weit, daß sich unter Troubleshootern das Motto etabliert hat: „Wenn die Ursache nicht DNS sein kann, dann prüfe nochmals DNS.“
Im Unternehmensbereich sind in der Regel DNS Server verschiedenster Art vohanden. Entweder Hardware Appliances mit DNS Funktion, oder ganze Microsoft Active-Directory Server. Wer jedoch ein Homelab einrichten möchte der hat im Büro meist nur einen kleinen DSL-Router mit DHCP Server mit eher schlechter als rechter DNS Funktionalität. Zwar kann man DNS-Server, oder ganze ADS-Domaincontroller in einer VM betreiben, jedoch haben wir hier das Henne-Ei Problem. Die VM startet erst nachdem Cluster und vCenter online sind. Bis dahin passiern ohne DNS wilde Dinge im vSphere Cluster. Gesucht ist also eine kleine, energiesparende, preiswerte und konfigurierbare Hardware-Lösung als DNS Server für das Homelab. Klingt wie die Eierlegende-Wollmilchsau, ist aber mit einem Raspberry Pi gut realisierbar.
Ich werde in diesem Artikel erklären was man hierfür benötigt und wie man ein Subnetz für das Lab konfiguriert.
Raspi als DNS-Server
Für dieses Projekt brauchen wir nicht das allerneueste Modell des Raspberry Pi. Ein Modell Raspi 3b ist hierfür vollkommen ausreichend und auch das Zubehör ist günstig zu bekommen.
Raspberry Pi 3b+ / 1GB / 4-Core / 1,4 GHz
35 €
Micro SD Karte 32 GB
9 €
Gehäuse (optional)
8 €
Netzteil 2,5A (optional)
10 €
HDMI Kabel
5 €
Stückliste mit Durchschnittspreisen Juli 2020
Für deutlich unter hundert Euro bekommt man somit einen kleinen Server, der darüber hinaus auch noch andere Aufgaben übernehmen kann, wie zum Beispiel die Steuerung der Heim-Automation, oder als Werbeblocker Pi-hole.
Ein paar kleine Dinge sind zu beachten. Prinzipiell kann man den Raspi per USB mit Strom versorgen. Man muss aber darauf achten, dass die Quelle mindestens und zuverlässig 1,2A liefert. Empfohlen werden Stromquellen mit 2,5A. Meine ersten Bootversuche scheiterten, weil mein USB-Netzteil nicht genügend Strom lieferte.
Der Raspi benötigt ein dauerhaftes Boot- und Speichermedium in Form einer Micro-SD Karte. Hier sollte man nicht die allerbilligste Ware nehmen, aber für unter 10 € bekommt man schon 32 GB eines Markenherstellers.
