Nachdem Sie Edge-Dienst-Gateway-VMs zu NSX-Edge-Knoten migriert und sichergestellt haben, dass das Routing und die Dienste ordnungsgemäß funktionieren, können Sie Ihre NSX-V-Hosts zu Transportknoten des NSX-Hosts migrieren.

Sie können verschiedene Einstellungen in Bezug auf die Hostmigration, einschließlich der Migrationsreihenfolge oder der Aktivierung von Hosts konfigurieren. 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 oder höher verwenden.

Weitere Informationen über die Vorgänge während der Hostmigration finden Sie unter Änderungen, die während der Hostmigration im Rahmen einer End-to-End-Migration vorgenommen wurden.

Wenn die Sicherheitsrichtlinien in Ihrer NSX-V-Umgebung für Guest Introspection oder Netzwerk-Introspektion oder beide einen Partnerdienst verwenden, wählen Sie den in der folgenden Tabelle angegebenen Hostmigrationsmodus aus.
Partnerdienst Hostmigrationsmodus
Nur Guest Introspection

Die Modi „Direkt“ und „Wartung“ werden unterstützt.
Nur Netzwerk-Introspektion

Der Wartungsmodus wird unterstützt. Es wird jedoch empfohlen, den Modus „Automatisierte Wartung“ zu verwenden.

Der Modus „Direkt“ wird nicht unterstützt.
Sowohl Guest Introspection als auch Netzwerk-Introspektion

Der Wartungsmodus wird unterstützt.

Der Modus „Direkt“ wird nicht unterstützt.
Wichtig: Konsultieren Sie den VMware-Partner, bevor Sie den Dienst migrieren, der auf den NSX-V-Arbeitslasten ausgeführt wird. Prüfen Sie mit dem Partner, ob sein Dienst für die Migration zu NSX unterstützt wird, und suchen Sie vor der Migration die erforderlichen Eingaben heraus. Partner besitzen eine eigene Anleitung, um ihre Dienste zu NSX zu migrieren.
Vorsicht: Die Hostmigration sollte während desselben Wartungsfensters wie die Edge-Migration abgeschlossen werden.

Sie müssen IPFIX deaktivieren und die ESXi-Hosts neu starten, bevor Sie diese migrieren.

Wenn der Partnerdienst in Ihrer NSX-V-Umgebung Guest Introspection oder sowohl Guest Introspection als auch Netzwerk-Introspektion bereitstellt, befolgen Sie die in diesem Thema beschriebenen Schritte, um die Cluster nacheinander zu migrieren. Nachdem alle Hostcluster zu NSX migriert wurden, führen Sie in jedem NSX-Cluster eine hostbasierte Dienstbereitstellung durch.

Wenn der Partnerdienst in Ihrer NSX-V-Umgebung nur den Netzwerk-Introspektionsdienst bereitstellt, verwenden Sie die unter Migrieren von Hosts mit Netzwerk-Introspektionsdienst erläuterte Hostmigration.

Voraussetzungen

  • Stellen Sie sicher, dass die Edge-Migration abgeschlossen ist und das gesamte Routing und die Dienste ordnungsgemäß ausgeführt werden.
  • Navigieren Sie auf der VMware vCenter-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

  1. 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.

  2. 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.
    1. Klicken Sie mit der rechten Maustaste auf die VM und wählen Sie Stromversorgung > Ausschalten, Stromversorgung > Gastbetriebssystem herunterfahren oder Stromversorgung > Anhalten aus.
    2. Nachdem der Host migriert wurde, hängen Sie die VM-Schnittstellen an die entsprechenden NSX-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.
    1. Klicken Sie mit der rechten Maustaste auf die VM und wählen Sie Stromversorgung > Ausschalten, Stromversorgung > Gastbetriebssystem herunterfahren oder Stromversorgung > Anhalten aus.
    2. 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-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-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 wird gestartet.

Ergebnisse

Nachdem ein Host im Migrationsmodus Direkt zu NSX 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 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.

Informationen zur Fehlerbehebung bei anderen Problemen während der Hostmigration finden Sie unter Beheben von Migrationsproblemen.

Nächste Maßnahme

Laden Sie die endgültige Ausgabezuordnungsdatei herunter, nachdem alle Hosts im Cluster erfolgreich zu NSX migriert wurden. Laden Sie die endgültige Zuordnungsdatei herunter, bevor Sie auf Fertigstellen klicken.

Wichtig: Prüfen Sie, ob alles ordnungsgemäß funktioniert, bevor Sie auf Fertigstellen klicken. Führen Sie dann die Aufgaben nach der Migration aus. Führen Sie vSphere-Lebenszyklusvorgänge wie ein Upgrade von ESXi-Hosts, VDS oder VC erst durch, nachdem die Aufgaben nach der Migration abgeschlossen wurden.

Weitere Informationen zur Zuordnungsdatei finden Sie unter Ausgabezuordnungsdatei.

Wenn die migrierten Sicherheitsrichtlinien einen Partnerdienst von Drittanbietern verwenden, stellen Sie in NSX eine Instanz des Partnerdienstes bereit. Eine detaillierte Anleitung finden Sie unter: