Die meisten kennen es, der Kunde möchte seine vSphere Umgebung gern auf den aktuellen Stand gebracht haben oder von einer alten Umgebung auf die neue migrieren, aber fast alle VMs sind Business-Critical, oder dürfen aus anderen Gründen nicht ausgeschaltet werden.

Eigentlich kein Problem, wenn man die Umgebung von 5.5 auf 6.5 upgraded, möchte man allerdings direkt von 5.5 auf 6.7 oder von einer 5.5 auf 6.7 migrieren, ist das nicht möglich da die älteste unterstützte Version bei vSphere 6.7 die Version 6.0 ist.

Nun könnte man die Umgebung erst umständlich auf 6.0 upgraden um dann weiter auf 6.7 zu gehen, oder man räumt sich ein oder zwei Hosts frei, rollt ein 6.7 vCenter aus, upgradet die Hosts und registriert die VMs im 6.7er vCenter neu. Das selbe würde natürlich auch für eine neue Umgebung funktionieren. Dafür wäre dann allerdings die unerwünschte Downtime der VMs nötig. In den folgenden Zeilen versuche ich einen Weg aufzuzeigen mit dem Ihr ohne eine komplette Umgebung erst auf eine Zwischenversion zu bringen oder eine VM-Downtime zu benötigen dieses Migrationsszenario zu bewältigen.

Ich möchte noch anmerken, dass sich dieser Beitrag an Administratoren und System-Engineers richtet, die sich in der Materie VMWare vSphere schon ein wenig auskennen. Falls eine exaktere Beschreibung gewünscht ist, hinterlasst bitte einen entsprechenden Kommentar und ich werde versuchen das Thema noch etwas detaillierter zu beschreiben.

Durchführung

Im ersten Schritt braucht ihr ein 6.0er vCenter ohne Domainbeitritt, Updatemanager oder ähnlichem. Es reicht eine einfache unkonfigurierte Appliance. Einzige Voraussetzung ist natürlich: Sie muss via IP und DNS erreichbar sein. (Anleitung VCSA Installation)

Der zwote Schritt ist im Prinzip eben so simpel. Räumt euch in der alten 5.5er Umgebung einen Host via vMotion frei und upgraded den Host, via iLo, IDRAC, iRMs oder welchen Servertyp Ihr auch immer einsetzt, auf ESXi 6.0 die, Buildnummer spielt dabei keine Rolle, sie sollte nur zu eurer Hardware passen. Dieser Host wird euer “Ship” und kann nun mit dem 6.0er Migrations-VCenter verbunden werden. (Exemplarische Anleitung des Upgrades)

Schritt drei. Je nach dem ob die neue Umgebung andere VLANs hat oder sich die Netze für vMotion und/oder Management geändert haben, muss nun dafür gesorgt werden, dass euer “Ship” Zugriff auf das neue vMotion oder Management Netz bekommt. Ihr könnt vMotion für den Migrationszeitraum z.B. auch auf den Managementkernel legen, wenn das die einzige Möglichkeit ist, alte und neue Welt zusammen zu bringen. Umgedreht geht es natürlich auch, sprich einen der neuen Hosts Zugriff auf die alten Netze verschaffen. Falls dvSwitche zum Einsatz kommen sollten diese natürlich auch entsprechend in der Migrationsumgebung erstellt werden, oder auf vSwitche umkonfiguriert werden. (VMDocs Beschreibung)

Wichtig: Achtet darauf, dass Ihr im Cluster der neuen 6.7er Umgebung den EVC Modus für das entsprechende Prozessormodell der alten 5.5er Umgebung aktiviert sonst ist die Live-Migration nicht möglich. (VMDocs Beschreibung)

Schritt vier. Nun da alles vorbereitet ist, kann die Migration beginnen. Verbindet einen der Hosts aus der alten 5.5er Umgebung (mit angeschalteten virtuellen Maschinen) zum 6.0er Migrationsvcenter. Ihr könnt hier einfach ein Cluster erstellen und beide Hosts darin verbinden. Nun könnt ihr die auf dem 5.5er Host befindlichen Maschinen auf den 6.0er Host migrieren. Danach verbindet Ihr den 6.0er Host zum 6.7er vCenter (außerhalb des Clusters direkt unter das Datacenter). Nun führt ein Storage-VMotion auf einen der Hosts durch. Falls Ihr einen neuen Host Zugriff auf das alte Netz der 5.5er Umgebung gegeben habt, migriert Ihr natürlich auf diesen. Achtet beim migrieren darauf die richtigen Netze zuzuweisen, falls sich etwas geändert hat.

Und somit habt ihr eine VM Live von 5.5 auf 6.7 geholt ohne die gesamte alte Infrastruktur zu upgraden. Nun verbindet ihr die Hosts entsprechend Rückwärts mit dem 5.5er und dem 6.0er vCenter und beginnt die Prozedur von neuem, bis alle Maschinen migriert sind.

Schlusswort

Mir ist klar, dass auch dieser Migrationsweg aufwändig ist, aber jeder der schon Upgrades in diesem Bereich durchgeführt hat weiß, dass es sehr oft zu Problemen kommen kann, vor allem wenn die Version 6.0 involviert ist. Ich habe diese Art der Migration nun schon einige Male erfolgreich durchgeführt und halte Sie für eine praktikable Alternative. Nichtsdestotrotz, wenn Ihr die Möglichkeit habt die VMs auszuschalten, sprich eine Downtime zu organisieren, ist das neu Registrieren der VM der einfachste Weg, sofern ihr die Möglichkeit habt das alte Storagesystem an die neue Umgebung, auf die migriert werden soll, anzuschließen.

Bei Fragen meldet euch gern in den Kommentaren.