
Beim Umstieg auf vSphere 7 werden die meisten Benutzer eine vorhandene vCenter Appliance von Version 6.5. bzw. 6.7 auf 7 aktualisieren. Der Installer kann zudem ein Windows vCenter ab Version 6.5 auf das vCSA 7 migrieren. Unser Beispiel aktualisiert ein im Embedded Linked Mode verknüpftes Linux-Appliance.
Nachdem man die Voraussetzungen für das Upgrade geprüft hat, empfiehlt es sich, die vCenter-Datenbank vor dem Upgrade zu sichern. Wir haben darüber hinaus ein Backup der kompletten Quell-Maschine und deren Konfiguration samt Tasks und Events erstellt. Dies würde es uns im Ernstfall jedoch nur erlauben, relativ schnell zur bisherigen Version zurückzukehren.
Snapshots zur Sicherung des bestehenden Status
VMware selbst empfiehlt, zumindest einen Snapshot der vCenter-Quell-Appliance für den Fall eines Fehlers während des Upgrades anzulegen. Erfolgt dieses von einem vCenter mit einem externen Platform Services Controller (PSC), soll man laut VMware auch einen Snapshot der PSC-Appliance anfertigen.
Allerdings gibt es die Gefahr einer Beschädigung der Quell-Appliance eigentlich nicht, da es sich beim Upgrade streng genommen um eine Migration auf eine komplett neue VM handelt. Diese startet mit temporären Netzwerkeinstellungen und erhält dann die Postgres-Datenbank aus dem Quellsystem.

Der Prozess schaltet danach die unveränderte Quell-Appliance aus und startet die neue VM mit den ursprünglichen Netzwerkeinstellungen des Quellsystems (Hostname, IP, FQDN usw.). Geht etwas schief, kann man jederzeit das Quellsystem wieder starten. Man muss lediglich darauf achten, Quell- und Ziel-VM niemals gleichzeitig einzuschalten.
Systemuhren synchronisieren
Außerdem muss man unbedingt sicherstellen, dass auf allen Komponenten im vSphere-Netzwerk die Systemuhren synchronisiert sind. Ist das nicht der Fall, werden SSL-Zertifikate und SAML-Token bei der Kommunikation zwischen Maschinen möglicherweise nicht anerkannt, was verhindert, dass der vmware-vpxd-Dienst startet.
Deshalb sollten sowohl der ESXi-Ziel-Host, der die Ziel-Appliance ausführen wird, als auch der ESXi-Host, auf dem das Quell-vCenter läuft, mit NTP oder PTP synchronisiert sein. Ist die Quell-Appliance mit einem externen PSC verbunden, dann gilt diese Empfehlung auch für den ESXi-Host, auf dem der externe PSC läuft.
DRS prüfen
Wird der Ziel-Host für das Appliance bereits von einem vCenter verwaltet, was der Normalfall sein wird, dann darf zudem DRS nicht im vollautomatischen Modus konfiguriert sein. Selbstverständlich sollte sich der ESXi-Ziel-Host auch nicht im Sperr- oder Wartungsmodus befinden.
SSH-Verbindung erlauben
Außerdem muss sichergestellt sein, dass Port 22 (SSH) auf der ursprünglichen vCenter-Appliance geöffnet ist, weil im Verlauf des Upgrades eine eingehende SSH-Verbindung zum Transfer der Daten zum neuen vCenter eingerichtet wird.
Ferner stellt der Upgrade-Assistent eine HTTPS-Verbindung zum ESXi-Quell-Host her, um zu überprüfen, ob die alte Appliance für das Upgrade bereit ist, und um die erwähnte SSH-Verbindung zu etablieren.
Netzwerkeinstellungen anpassen
Möchte man bei den temporären Netzwerkeinstellungen der Appliance eine statische IP-Adresse und einen FQDN als Systemnamen verwenden, muss man sicherstellen, dass Forward- und Reverse-DNS-Datensätze für die IP-Adresse eingerichtet sind. Allerdings ist ein auflösbarer FQDN für diesen Zwischenschritt eigentlich nicht erforderlich.
Zudem muss der ESXi-Host, auf dem die neue Appliance bereitgestellt wird, mit einem Netzwerk verbunden sein, das mit einer Portgruppe verknüpft ist, die in den Sicherheitsrichtlinien der Portgruppe Änderungen an MAC-Adressen akzeptiert (MAC Adress Changes). Bei einem Standard vSwitch ist das bekanntlich der Default, nicht aber bei einer Distributed-Switch-Portgruppe.
Upgrade starten
Sind alle Vorbereitungen getroffen, dann kann man den Installer starten. Wir verwenden für diesen Beitrag den GUI-Installer für Windows und wählen am Start-Bildschirm die Option Upgrade.
Das Upgrade gliedert sich wie eine Neuinstallation in zwei Phasen, wobei sich die erste der Verbindung zum Quell-vCenter und dem Deployment der neuen Ziel-VM widmet. Stage 2 verwaltet dann die Datenübernahme.
Interessant wird es erst im Schritt 3 des Upgrade-Assistenten, in dem man die Verbindung zur Quell-Appliance konfiguriert.

Hier benötigt man den FQDN des Quell-Systems, dessen administrativer SSO-User inklusive Passwort und den FQDN des ESXi-Hosts, auf dem das Quell-System läuft sowie dessen root-Credentials.
Im Schritt 4 gibt man dann den gewünschten Ziel-Host und dessen root-Credentials an.

Erst im Schritt 5 richtet man dann die Ziel-Appliance ein. Diese benötigt einen Inventarnamen und ein root-Passwort.

Aber Achtung: Nachdem der Hostname des Quellsystems im Gast-OS beibehalten und erst im Verlauf des Upgrades vom Zielsystem übernommen wird, kann der Inventarname zu diesem Zeitpunkt natürlich nicht identisch mit dem Hostname sein.
Wer sich wie ich angewöhnt hat, für Host- und Inventarnamen identische FQDN zu verwenden, kann an dieser Stelle nur einen temporären Inventarnamen benutzen, die VM nach Fertigstellen des Upgrades umbenennen und danach ein Storage-vMotion durchführen.
Anschließend legt man die Größe der Target-VM und ihres Storage fest, genau wie bei der Neuinstallation.