Nachdem die Infrastruktur für die Erweiterung von Layer-2-Netzwerken vorbereitet wurde, können Sie Ihre NSX-V-Hosts auf NSX-T-Hosttransportknoten migrieren.
Voraussetzungen
- Konfigurieren Sie mehrere Einstellungen im Zusammenhang mit der Hostmigration, einschließlich Migrationsreihenfolge und Aktivierung von Hosts. Stellen Sie sicher, dass Ihnen die Auswirkungen dieser Einstellungen bekannt sind. Weitere Informationen hierzu finden Sie unter Konfigurieren der NSX-V-Hostmigration. Die Kenntnis der Einstellungen für die Hostmigration ist besonders wichtig, wenn Sie die verteilte Firewall oder vSphere Distributed Switch 7.0 verwenden.
- Navigieren Sie auf der vCenter Server-Benutzeroberfläche zur Seite Hosts und Cluster und stellen Sie sicher, dass alle ESXi-Hosts betriebsbereit sind. Beheben Sie alle Probleme mit Hosts, einschließlich getrennter Zustände. Für den Wechsel in den oder aus dem Wartungsmodus dürfen weder ausstehende Neustarts noch ausstehende Aufgaben vorhanden sein.
Prozedur
- Klicken Sie auf der Seite Migrieren der Hosts auf Starten.
Wenn Sie für alle Hostgruppen den Migrationsmodus Direkt oder Automatisierte Wartung ausgewählt haben, wird die Hostmigration gestartet. Beachten Sie, dass der Migrationskoordinator im Modus Automatisierte Wartung die ausgeschalteten VMs nicht neu konfiguriert. Nach der Migration müssen Sie diese VMs vor dem Einschalten manuell konfigurieren.
- Wenn Sie für Hostgruppen den Migrationsmodus Manuelle Wartung ausgewählt haben, müssen Sie für jede virtuelle Maschine eine der folgenden Aufgaben ausführen, damit die Hosts in den Wartungsmodus wechseln können.
| Option |
Aktion |
| Schalten Sie VMs aus oder halten Sie sie an. |
- Klicken Sie mit der rechten Maustaste auf die VM und wählen Sie , oder aus.
- Nachdem der Host migriert wurde, hängen Sie die VM-Schnittstellen an die entsprechenden NSX-T-Segmente an und schalten Sie die VM ein.
|
| Verschieben Sie VMs mit vMotion. |
Klicken Sie mit der rechten Maustaste auf die VM und wählen Sie „Migrieren“ aus. Folgen Sie den Eingabeaufforderungen, um die VM auf einen anderen Host zu verschieben. Beachten Sie, dass der Migrationskoordinator die Sicherheit während der Migration aufrechterhält, indem VMs mit vMotion an bestimmte Ports verschoben werden, die durch temporäre Regeln geschützt werden. Bei einem manuellen vMotion-Vorgang werden die VMs nicht an diese Ports verschoben und es kann zu einem Sicherheitsverstoß kommen. Um vMotion manuell auszuführen, müssen die VMs mithilfe der vSphere-API migriert werden. Dabei muss das Netzwerk-Backing bei Verwendung von VDS 7 auf die OpaqueNetwork-ID verweisen, die dem NSX-Segment entspricht. In beiden Fällen muss für die externalId des Netzwerkgeräts die Zeichenfolge „VM_UUID:vNIC_ID“ festgelegt werden, wobei VM_UUID die UUID der VM-Instanz und vNIC_ID der vNIC-Index der VM ist (die erste vNIC ist 4000). |
| Verschieben Sie VMs mit der Cold-Migration. |
- Klicken Sie mit der rechten Maustaste auf die VM und wählen Sie , oder aus.
- Klicken Sie mit der rechten Maustaste auf die VM und wählen Sie „Migrieren“ aus. Folgen Sie den Anweisungen, um die VM auf einen anderen Host zu verschieben, indem Sie die VM-Schnittstellen mit den entsprechenden NSX-T-Segmenten verbinden.
|
Im Folgenden finden Sie Python-Code, mit dem Sie für jede vNIC in einer VM eine externe ID angeben können, um anschließend eine vMotion-Migration der VM durchzuführen, bei der die vNICs eine Verbindung mit einem
NSX-T-Segment mit der ID „ls_id“ an den passenden Ports herstellen:
devices = vmObject.config.hardware.device
nic_devices = [device for device in devices if isinstance(device, vim.Vm.device.VirtualEthernetCard)]
vnic_changes = []
for device in nic_devices:
vif_id = vmObject.config.instanceUuid + ":" + str(device.key)
vnic_spec = self._get_nsxt_vnic_spec(device, ls_id, vif_id)
vnic_changes.append(vnic_spec)
relocate_spec = vim.Vm.RelocateSpec()
relocate_spec.SetDeviceChange(vnic_changes)
# set other fields in the relocate_spec
vmotion_task = vmObject.Relocate(relocate_spec)
WaitForTask(vmotion_task)
def _get_nsxt_vnic_spec(self, device, ls_id, vif_id):
nsxt_backing = vim.Vm.Device.VirtualEthernetCard.OpaqueNetworkBackingInfo()
nsxt_backing.SetOpaqueNetworkId(ls_id)
nsxt_backing.SetOpaqueNetworkType('nsx.LogicalSwitch')
device.SetBacking(nsxt_backing)
device.SetExternalId(vif_id)
dev_spec = vim.Vm.Device.VirtualDeviceSpec()
dev_spec.SetOperation(vim.Vm.Device.VirtualDeviceSpec.Operation.edit)
dev_spec.SetDevice(device)
return dev_spec
Ein Beispiel für ein vollständiges Skript finden Sie unter https://github.com/dixonly/samples/blob/main/vmotion.py
Der Host wechselt in den Wartungsmodus, nachdem alle VMs verschoben, ausgeschaltet oder angehalten wurden. Wenn Sie die Cold-Migration verwenden möchten, um die VMs auf einen anderen Host zu verschieben, bevor der migrierte Host in den Wartungsmodus wechselt, muss während des Verschiebens von VMs mindestens eine VM weiter ausgeführt werden. Wenn die letzte VM ausgeschaltet oder angehalten wurde, wechselt der Host in den Wartungsmodus und die Migration des Hosts zu
NSX-T wird gestartet.
Ergebnisse
Nachdem ein Host im Migrationsmodus Direkt zu NSX-T migriert wurde, wird möglicherweise ein kritischer Alarm mit der Meldung Netzwerkkonnektivität unterbrochen angezeigt. Dieser Alarm tritt auf, wenn ein vSphere Distributed Switch (VDS) 6.5 oder 6.7 auf einen N-VDS migriert, weil der Host nicht mehr über eine physische Netzwerkkarte verfügt, die mit dem VDS verbunden ist, mit dem er zuvor verbunden war. Um den Status „Verbunden“ der migrierten Hosts wiederherzustellen, klicken Sie auf jedem Host auf Auf Grün zurücksetzen und schließen Sie ggf. die Warnungen.
Wenn bei der Migration eines Hosts ein Fehler auftritt, können Sie die Hostgruppe an das Ende der Liste der Gruppen verschieben. Die Migration anderer Hostgruppen kann fortgesetzt werden, während Sie das Problem mit dem fehlgeschlagenen Host beheben.
Wenn bei der Migration eines Hosts ein Fehler auftritt, stoppt die Migration, nachdem alle laufenden Hostmigrationen abgeschlossen sind. Wenn Sie das Problem mit dem Host behoben haben, klicken Sie auf Wiederholen, um die Migration des fehlgeschlagenen Hosts erneut zu starten. Wenn die Migration des Hosts weiterhin fehlschlägt, können Sie NSX-T auf dem Host manuell konfigurieren oder den Host aus dem System entfernen. In diesem Fall wird am Ende des Schritts zur Hostmigration die Schaltfläche Fertigstellen aufgrund des nicht migrierten Hosts nicht aktiviert. Sie müssen den REST API POST https://<nsx-mgr-IP>/api/v1/migration?action=finalize_infra (<nsx-mgr-IP> ist die IP-Adresse des NSX Manager, auf dem der Migrationsdienst ausgeführt wird) mithilfe eines REST API-Clients (z. B. "postman" oder "curl") aufrufen, um die Migration abzuschließen, und dann die Aufgaben nach der Migration ausführen.
Nächste Maßnahme
- Stellen Sie sicher, dass alle erwarteten Konfigurationselemente auf die NSX-T-Umgebung migriert wurden. Prüfen Sie beispielsweise, ob die folgenden Konfigurationen erfolgreich migriert wurden:
- Benutzerdefinierte Regeln für verteilte Firewall.
- Alle Gruppierungsobjekte, wie z. B. IP Sets, Gruppen, Tags usw.
- Effektive Mitglieder werden in den dynamischen Gruppen angezeigt.
- Tags werden auf migrierte Arbeitslast-VMs angewendet.
Stellen Sie sicher, dass die VMs, die auf den
NSX-T-Hosts ausgeführt werden, mit dem richtigen
NSX-T-Overlay-Segment verbunden sind und prüfen Sie die folgende Konnektivität:
- Konnektivität von VM zu VM im NSX-T-Netzwerk.
- Konnektivität der VMs zu den externen Maschinen außerhalb des NSX-T-Netzwerks, sofern die DFW-Regeln dies zulassen.
- Klicken Sie auf der Seite Hosts migrieren auf Fertigstellen.
Ein Dialogfeld wird angezeigt, um die Beendigung der Migration zu bestätigen. Wenn Sie die Migration abgeschlossen haben, werden alle Migrationsdetails gelöscht. Sie können die Einstellungen dieser Migration nicht mehr überprüfen. Wie beispielsweise, welche Eingaben auf der Seite Konfiguration auflösen vorgenommen wurden oder welche Hosts von der Migration ausgeschlossen wurden.
