Wenden Sie dieses Verfahren an, wenn "Angewendet auf" in einer der DFW-Regeln konfiguriert ist (dies bedeutet, dass "Angewendet auf" nicht auf "DFW" festgelegt ist).

Hinweis: Weitere Informationen NSX-V zur NSX-Migration finden Sie im KB-Artikel https://kb.vmware.com/s/article/56991.

Für NSX zur NSX-V-Migration funktioniert die Migration einer Arbeitslast-VM zurück zu NSX-V möglicherweise nicht, da der Filter für die verteilte Firewall in NSX immer höher ist als in NSX-V. Die Problemumgehung besteht darin, die Arbeitslast-VM vor vMotion in der NSX-Ausschlussliste zu platzieren.

Voraussetzungen

  • Stellen Sie sicher, dass folgende Voraussetzungen erfüllt sind:
    • vSphere vMotion ist auf dem VMkernel-Adapter jedes Hosts in dem Cluster aktiviert, der an dieser Migration beteiligt ist. Ausführliche Schritte zum Aktivieren von vMotion auf dem VMkernel-Adapter finden Sie in der Produktdokumentation zu vSphere.
    • Der Zielhost in NSX verfügt über ausreichende Ressourcen, um die migrierten VMs aufzunehmen.
    • Die Quell- und Zielhosts befinden sich im betriebsbereiten Zustand. Beheben Sie alle Probleme mit Hosts, einschließlich getrennter Zustände.

Weitere Informationen zu vMotion finden Sie unter Migration mit vMotion in der vSphere-Produktdokumentation.

Prozedur

  1. Führen Sie ein Skript aus, um eine externe ID für jede vNIC in einer VM anzugeben und die VM mit vMotion auf den richtigen logischen Port zu verschieben.
    Der logische Port wurde bereits vom Migrationskoordinator erstellt. Der folgende Beispielcode (und das Skript in github) bestimmt die external-id für jede vNIC, sodass die vNIC eine Verbindung mit dem erstellten logischen Port herstellt. 
    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

  2. Wenden Sie die Sicherheits-Tags und die statische VM-Mitgliedschaft auf die migrierten VMs an.
    POST https://{nsxt-mgr-ip}/api/v1/migration/vmgroup?action=post_migrate
    Der vmgroup-API-Endpoint mit der post_migrate-Aktion wendet die NSX-V-Sicherheits-Tags auf die migrierten Arbeitslast-VMs im NSX-Overlay-Segment an.

    Ein Beispiel für einen Anforderungstext dieser API finden Sie im Abschnitt Lift and Shift-Migrationsvorgang des NSX Tech Zone-Artikels.

  3. Stellen Sie die Infrastruktur fertig, um die Migration abzuschließen.
    POST https://{nsxt-mgr-ip}/api/v1/migration?action=finalize_infra
    Diese Migrations-API löscht alle temporären Objektkonfigurationen, die während der Migration erstellt wurden, und stellt sicher, dass sich die NSX-Infrastruktur in einem bereinigten Zustand befindet. Beispielsweise werden temporäre IP Sets aus den Gruppen entfernt.

    Diese POST-API hat keinen Anforderungstext.

  4. Stellen Sie sicher, dass alle erwarteten Konfigurationselemente auf die NSX-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.
  5. (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.
  6. Klicken Sie auf der Seite Arbeitslasten 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. So können Sie beispielsweise nicht mehr nachvollziehen, welche Eingaben auf der Seite Konfiguration auflösen vorgenommen wurden.

Nächste Maßnahme

Nachdem die Migration der Arbeitslast-VMs und der Konfiguration nur für die DFW erfolgreich und gründlich verifiziert wurde, entfernen Sie die Layer-2-Bridge, um die NSX Edge freizugeben, die Sie für das Bridging verwendet haben.