Nachdem Sie die Edge Services Gateways erfolgreich migriert haben, können Sie die NSX-V-Hosts auf NSX -Host-Transportknoten migrieren.

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.
    Screenshot des Bildschirms der Hostmigration

    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.
  3. (Optional) Ab NSX 4.1.1 können Sie nach Abschluss der Migration und vor dem Klicken auf Fertigstellen auf Migrationsbericht abrufen klicken, um zu prüfen, ob bestimmte Objekte ordnungsgemäß migriert wurden. Wenn der Bericht bereit ist, klicken Sie auf Bericht herunterladen.
    Der Bericht enthält die folgenden Informationen:
    • VMs mit Sicherheits-Tags in NSX-V und nach der Migration. Wenn Unterschiede bestehen, werden diese aufgelistet.
    • Sicherheitsgruppen in NSX-V und nach der Migration. Wenn Unterschiede bestehen, werden diese aufgelistet.

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

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