Migrieren von Arbeitslast-VMs (komplexer Fall)

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

Rufen Sie die Instanz-UUID aller zu migrierenden VMs ab.
Die Instanz-UUIDs werden benötigt, wenn Sie den API-Aufruf im nächsten Schritt durchführen. Im Beispiel unten in diesem Abschnitt finden Sie Informationen zum Abrufen der Instanz-UUID einer VM.
Führen Sie die folgende POST-API-Anforderung aus:
```
POST https://{nsxt-mgr-ip}/api/v1/migration/vmgroup?action=pre_migrate
```
Diese API erstellt einen logischen Segment-Port (VIF), der der VM-Instanz-UUID jeder NSX-V-Arbeitslast-VM in der VM-Gruppe entspricht, die Sie über die Layer-2-Bridge in das NSX-Overlay-Segment migrieren werden. Ein Beispiel für einen Anforderungstext dieser API finden Sie im Abschnitt Lift and Shift-Migrationsvorgang des NSX Tech Zone-Artikels.

Rufen Sie die API GetVmGroupExecutionDetails auf.

Rufen Sie die API GetVmGroupExecutionDetails auf, um das Ergebnis des API-Aufrufs vor der Migration mit derselben group_id (und federation_site_id für die VC-übergreifende Migration) abzurufen. Sie erhalten eine Liste (logical_switch_id_to_vm_instance_id_and_vnics_map) und eine optionale Liste (failedVmInstanceIds), die die UUIDs von VMs enthält, die im Quell-VC nicht gefunden wurden. Beispiel:

GET /api/v1/migration/vmgroup/actions/get_vm_group_execution_details?group_id=<group-id>&federation_site_id=<site_id>
Response:
{
  "logical_switch_id_to_vm_instance_id_and_vnics_map":[
    {
      "ls_id":"36885723-7581-4696-a195-ef83851dc35f",
      "vm_and_vnics_mapping":[
        {
          "vm_instance_id":"52199e21-6aab-26e4-8c82-069a17d67667",
          "vnics":[
            "4001"
          ]
        },
        {
          "vm_instance_id":"52630e5d-ce6f-fac0-424c-4aa4bdf6bd56",
          "vnics":[
            "4001"
          ]
        }
      ]
    }
  ],
  "failedVmInstanceIds":[
    "501557f6-2197-1fe8-14e5-89898cee5fec"
  ]
}

Halten Sie sich an den nachfolgenden Pseudo-Python-Code, um ein Skript für die vMotion-Übertragung der VMs zu schreiben.

Im Abschnitt Python-Beispielskripts des NSX Tech Zone-Artikels finden Sie ein Beispiel.

     define _get_nsx_portgroups_in_host(self, host):
        ls_id_to_nsx_pgs_map = {}
        for net in host.network:
            if isinstance(net, vim.dvs.DistributedVirtualPortgroup):
                if hasattr(net.config, 'backingType'):
                    if net.config.backingType == 'nsx' and net.config.logicalSwitchUuid:
                        ls_id_to_nsx_pgs_map[net.config.logicalSwitchUuid] =\
                           [net.key, net.config.distributedVirtualSwitch.uuid]
        return ls_id_to_nsx_pgs_map

     define _get_vms_vnic_to_ls_id_map(self, logical_switch_id_to_vm_instance_id_and_vnics_map):
        vm_uuid_2_vnics_map = {}
        for ls_id_2_vm_vnics in logical_switch_id_to_vm_instance_id_and_vnics_map:
            ls_id = ls_id_2_vm_vnics['ls_id']
            for vm_vnics in ls_id_2_vm_vnics['vm_and_vnics_mapping']:
                vnic_2_ls_id = vm_uuid_2_vnics_map.get(vm_vnics['vm_instance_id'], {})
                for vnic in vm_vnics['vnics']:
                    vnic_2_ls_id[vnic] = ls_id
                vm_uuid_2_vnics_map[vm_vnics['vm_instance_id']] = vnic_2_ls_id
        return vm_uuid_2_vnics_map
    
    def _get_nsxt_vnic_spec(self, device, dvpg_key, dvs_uuid, vif_id):
        vdsPgConn = vim.dvs.PortConnection()
        vdsPgConn.portgroupKey = dvpg_key
        vdsPgConn.switchUuid = dvs_uuid
        device.backing = vim.vm.device.VirtualEthernetCard.DistributedVirtualPortBackingInfo()
        device.backing.port = vdsPgConn
        device.externalId = vif_id
        dev_spec = vim.Vm.Device.VirtualDeviceSpec()
        dev_spec.SetOperation(vim.Vm.Device.VirtualDeviceSpec.Operation.edit)
        dev_spec.SetDevice(device)
        return dev_spec
    
    def _migrate_vm(self, vmObject, vnic_2_ls_id_map, ls_id_to_nsx_pgs_map):
        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:
            ls_id = vnic_2_ls_id_map.get(str(device.key))
            if ls_id:
                vif_id = vmObject.config.instanceUuid + ":" + str(device.key)
                nsx_pg = ls_id_to_nsx_pgs_map.get(ls_id)
                vnic_spec = self._get_nsxt_vnic_spec(device, nsx_pg[0], nsx_pg[1], 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)
    
    vm_uuid_2_vnics_map = self._get_vms_vnic_to_ls_id_map(logical_switch_id_to_vm_instance_id_and_vnics_map)
    for vm_uuid, vnic_2_ls_id_map in vm_uuid_2_vnics_map.items():
        # get the vmObject by the vm_uuid
        # find a target host that has all the networks needed by this VM
        ls_id_to_nsx_pgs_map = self._get_nsx_portgroups_in_host(host)
        self._migrate_vm(vmObject, vnic_2_ls_id_map, ls_id_to_nsx_pgs_map)

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

Beispiel: Abrufen der VM-Instanz-UUID aus vCenter MOB

In diesem Beispiel ist dargestellt, wie Sie die Instanz-UUID einer VM aus dem VMware vCenter Managed Object Browser (MOB) unter http://{vCenter-IP-Address}/mob abrufen oder bestätigen. Sie können auch die Instanz-UUID einer VM abrufen oder bestätigen, indem Sie einen API-Aufruf für vSphere durchführen.

Geben Sie in einem Webbrowser den vCenter Managed Object Browser unter http//{vCenter-IP-Adresse}/mob ein.
Klicken Sie auf Inhalt.
Suchen Sie rootFolder in der Spalte „Name“ und klicken Sie auf den entsprechenden Link in der Spalte „Wert“. Beispiel: group-d1.
Suchen Sie childEntity in der Spalte „Name“ und klicken Sie auf den entsprechenden Link in der Spalte „Wert“. Beispiel: datacenter-21.
Suchen Sie hostFolder in der Spalte „Name“ und klicken Sie auf den entsprechenden Link in der Spalte „Wert“. Beispiel: group-h23.
Suchen Sie childEntity in der Spalte „Name“. Die entsprechende Spalte „Wert“ enthält Links zu Hostclustern. Klicken Sie auf den entsprechenden Hostcluster-Link. Beispiel: domain-c33.
Suchen Sie host in der Spalte „Name“. In der entsprechenden Spalte „Wert“ werden die Hosts in diesem Cluster nach vCenter-MOID und Hostname aufgelistet. Klicken Sie auf den entsprechenden Host-Link, z. B. host-32.
Suchen Sie vm in der Spalte „Name“. In der entsprechenden Spalte „Wert“ werden die virtuellen Maschinen nach vCenter-MOID und Hostnamen aufgelistet. Beispiel: vm-216 (web-01a). Klicken Sie auf die VM, die Sie interessiert.
Suchen Sie config in der Spalte „Name“. Suchen Sie config in der Spalte „Wert“.
Suchen Sie instanceUuid in der Spalte „Name“. In der entsprechenden Spalte „Wert“ wird die Instanz-UUID der VM aufgelistet. Beispiel: 502e71fa-1a00-759b-e40f-ce778e915f16.

Nächste Maßnahme

Nach der Migration von Arbeitslast-VMs können Sie die Layer-2-Bridge entfernen.