Die Veröffentlichung des ersten vSphere8-Patches ESXi 8.0a am 08.12.22 – die GA-Version ist im Oktober letzten Jahres erschienen – ist für viele Unternehmen Anlass, das geplante Upgrade von Version 6.7 oder 7.x in Angriff zu nehmen. Lesen Sie hier, welche Überlegungen vor einem erfolgreichen Update anstellen müssen und wie Sie Konfiguration Ihrer alten Hosts vor dem Upgrade sichern. Ein Folge-Artikel erklärt den Upgrade-Prozess im Detail.
Die Frage nach dem richtigen Zeitpunkt für das Upgrade eine neuen vSphere-Haupt-Version stellt sich bei jedem neuen Major-Release. Viele Unternehmen lassen aus Prinzip die Finger von der GA-Version (General Available), was sicher auch vernünftig ist. Ganz generell können Sie aber, auch wenn das Support-Ende für vSphere 7 erst am 02.04.2025 droht (der Support für vSphere 6.7 ist schon im Oktober 22 ausgelaufen), nicht dauerhaft bei einem veralteten Hypervisor bleiben, weil Sie dann nicht von den neuesten Sicherheitsfunktionen profitieren, vom Support ganz zu schweigen.
Bevor Sie mit dem Upgrade starten müssen Sie sicherstellen, dass sämtliche Installations-Voraussetzungen erfüllt sind. Machen Sie sich also mit dem Release Notes der zu installierenden Version 8.0a vertraut und informieren Sie sich über die generellen Installationsvoraussetzungen, insbesondere den Hardware-Anforderungen. Oft wird beispielsweise unterschätzt, dass auch vermeintlich aktuelle Hardwaresysteme nicht (mehr) auf VMwares HCL stehen (dann haben Sie mindestens ein Support-Problem) oder, dass die Installierbarkeit an der CPU scheitert.
Sorgen Sie unbedingt dafür, dass Ihre gesamte Umgebung, einschließlich Ihrer Backup- und Überwachungsanwendungen (z. B Veeam) vollständig mit VMware ESXi 8.0 kompatibel ist. Bei einer Greenfield-Bereitstellung müssen Sie sich keine Gedanken über die Abwärtskompatibilität machen. Die meisten Unternehmen werden aber ein Upgrade in Erwägung ziehen. Stellen Sie vorher anhand der unterstützten Upgrade-Pfade für den Hypervisor sicher, dass ein Upgrade des Hypervisors überhaupt möglich ist. Das gilt z. B. nicht für die Version 6.5.
Wenn es an der Hardware scheitert
Lässt sich Ihre Infrastruktur nicht auf Version 8 aktualisieren, weil die Hardware nicht unterstützt wird, können Sie lediglich Side-by-Side ein neues System auf neuer Hardware aufsetzen, und dann nach und nach ihre Workloads nach einer angemessenen Testphase auf die neue Infrastruktur migrieren.
Das lässt sich einigermaßen schnell und schmerzfrei erledigen, wenn Ihre VMs auf Shared-Storage (SAN/VMFS oder NAS/NFS) liegen. Möchten Sie bei dem Upgrade auch gleich auf ein neues Speichersystem wechseln, müssen Sie aber zwangsläufig auch die VM-Datenträgerdateien (VMDKs) migrieren, was je nach Menge und Größe durchaus Zeit in Anspruch nehmen kann.
Verbleiben die VMs auf dem gleichen physischen SAN, wandern aber bei der Migration auf einen andere Datastore (VMware-seitig), der mit anderen LUNs im SAN konfiguriert ist, profitieren Sie ggf. davon, wenn Ihr Setup Storage vMotion unterstützt oder Ihre Speichersystem Dank VAAI-Support Blöcke selbständig kopieren kann ohne Umweg über den ESXi-Kernel.
Können Sie svMotion nicht nutzen, helfen Tools wie Veeam Backup and Replication, weil diese Systeme VMware Snapshots und CBT (Changed Block Tracking) unterstützen und damit etwaige Widerherstellungen auf ein anderes Speichersystem beschleunigen.
So sichern Sie die ESXi 7.x-Konfiguration
Bevor Sie mit dem Upgrade starten müssen Sie Ihre alte Konfiguration sichern, um Diese bei einem Problem wiederherstellen zu können. Es gibt mehrere Möglichkeiten, dies zu tun, etwa via vCLI, Powershell oder ESXi-Shell. Eine Weitere auf Basis der ESXI-Shell (verbunden via physischen Terminal, IPMI/iLO oder SSH/Putty) besteht in der Verwendung des Kommandos …
vim-cmd hostsvc/firmware/backup_config
Das Tolle hierbei ist, dass Sie als Ergebnis direkt eine URL erhalten, die Sie in ihrem Browser einfügen können, um das verknüpfte Backup direkt außerhalb des ESXi-Host speichern zu können.
Hierbei müssen Sie lediglich das *-Zeichen durch die IP-Adresse (oder den Hostnamen) Ihres Hosts ersetzen.
Für eine etwaige Widerherstellung muss dann gewährleistet sein, dass die Ziel-Build-Nummer des Hosts mit dem Build überein übereinstimmt, von dem Sie die Sicherung erstellt haben und dass die UUID des Hosts gleich bleibt.
Im nächsten Teil zeige ich Ihnen, wie Sie das Upgrade im Detail durchführen.