Beim Abschließen der Migration von NSX Data Center for vSphere treten unter Umständen Fehler auf. Die folgenden Informationen zur Fehlerbehebung bieten Unterstützung bei der Lösung dieser Probleme.

Zugreifen auf den Migrations-Koordinator

Problem Lösung
Der Migrations-Koordinator wird bei System > Migrieren nicht angezeigt. Stellen Sie sicher, dass der Migrations-Koordinatordienst auf NSX Manager ausgeführt wird. 
manager> get service migration-coordinator
Service name:                     migration-coordinator
Service state:                    running

Wenn der Dienst nicht ausgeführt wird, starten Sie ihn mit start service migration-coordinator.

Bei der Rückkehr zum Migrations-Koordinator wird die aktuell ausgeführte Migration nicht angezeigt.
Die Anmeldedaten von vCenter Server oder NSX Manager werden vom Migrations-Koordinator nicht gespeichert. Wenn der Migrations-Koordinatordienst während der Ausführung einer Migration neu gestartet wird, werden auf der Seite System > Migrieren gegebenenfalls veraltete oder keine Informationen angezeigt. Zur Anzeige des letzten Migrationsstatus beim Neustart des Migrations-Koordinatordiensts führen Sie folgende Schritte aus:
  1. Aktualisieren Sie die Seite System > Migrieren.
  2. Klicken Sie auf Erste Schritte und geben Sie die Anmeldedaten für vCenter Server und NSX Manager ein.

Probleme beim Importieren der Konfiguration

Problem Lösung
Die Konfiguration kann nicht importiert werden.
  1. Klicken Sie auf Wiederholen, um den Importvorgang zu wiederholen. Nur die fehlgeschlagenen Importschritte werden wiederholt.

Probleme bei der Hostmigration

Problem Lösung
Die Hostmigration schlägt aufgrund einer fehlenden Compute Manager-Konfiguration fehl.

Die Compute Manager-Konfiguration gilt als Voraussetzung für die Migration. Wenn die Compute Manager-Konfiguration nach dem Start der Migration jedoch aus NSX Manager entfernt wird, bleibt die Einstellung im Migrations-Koordinator erhalten. Die Migration wird bis zu dem Schritt der Hostmigration fortgesetzt, der fehlschlägt.

Fügen Sie einen Compute Manager zu NSX Manager hinzu und geben Sie dieselben vCenter Server-Details ein, die beim erstmaligen Import der NSX-v-Konfiguration verwendet wurden.

Die Hostmigration schlägt aufgrund veralteter dvFilter fehl.

Beispiel für eine Fehlermeldung: Stale dvFilters present: ['port 33554463 (disconnected)', 'port 33554464 (disconnected)'] Stale dvfilters present. Aborting ]

Melden Sie sich bei dem Host an, der nicht migriert werden konnte, ermitteln Sie die getrennten Ports und starten Sie die entsprechende VM neu oder verbinden Sie die getrennten Ports. Anschließend können Sie den Schritt „Hostmigration“ wiederholen.

  1. Melden Sie sich bei der Befehlszeilenschnittstelle des Hosts an, der nicht migriert werden konnte.
  2. Führen Sie summarize-dvfilter aus und suchen Sie nach den Ports, die in der Fehlermeldung gemeldet wurden. 
    world 1000057161 vmm0:2-vm_RHEL-srv5.6.0.9-32-local-258-963adcb8-ab56-41d6-bd9e-2d1c329e7745 vcUuid:'96 3a dc b8 ab 56 41 d6-bd 9e 2d 1c 32 9e 77 45'
 port 33554463 (disconnected)
  vNic slot 2
  name: nic-1000057161-eth1-vmware-sfw.2
 agentName: vmware-sfw
   state: IOChain Detached
   vmState: Detached
   failurePolicy: failClosed
   slowPathID: none
   filter source: Dynamic Filter Creation
  3. Suchen Sie nach der betroffenen VM und dem betroffenen Port.
    In der Fehlermeldung wird beispielsweise darauf hingewiesen, dass Port 33554463 getrennt wurde.
    1. Suchen Sie nach dem Abschnitt der summarize-dvfilter-Ausgabe, die diesem Port entspricht. Der VM-Name wird hier aufgeführt. In diesem Fall handelt es sich um 2-vm_RHEL-srv5.6.0.9-32-local-258-963adcb8-ab56-41d6-bd9e-2d1c329e7745.
    2. Suchen Sie nach dem Eintrag name, um die getrennte VM-Schnittstelle zu ermitteln. In diesem Fall handelt es sich um eth1. Die zweite Schnittstelle ist von 2-vm_RHEL-srv5.6.0.9-32-local-258-963adcb8-ab56-41d6-bd9e-2d1c329e7745 getrennt.
  4. Beheben Sie das Problem mit diesem Port. Führen Sie einen der folgenden Schritte aus:
    • Starten Sie die betroffene VM neu.
    • Verbinden Sie den getrennten Vnic-Port mit einem beliebigen Netzwerk.
  5. Klicken Sie auf der Seite Hosts migrieren auf Wiederholen.

Nach der Migration der Hosts mit vMotion kann es bei VMs zu Unterbrechungen des Datenverkehrs kommen, sofern SpoofGuard in NSX-v aktiviert ist.

Symptome:

In der Datei vmkernel.log, die sich unter /var/run/log/ auf dem Host befindet, erfahren Sie, ob der Datenverkehr wegen SpoofGuard beeinträchtigt wird.

In der Protokolldatei könnte z. B. Folgendes enthalten sein: WARNING: swsec.throttle: SpoofGuardMatchWL:296:[nsx@6876 comp="nsx-esx" subcomp="swsec"]Filter 0x8000012 [P]DROP sgType 4 vlan 0 mac 00:50:56:84:ee:db

Ursache:

Die Konfiguration des logischen Switch und des logischen Switch Ports werden über den Migrations-Koordinator migriert, der die SpoofGuard-Konfiguration migriert. vMotion migriert jedoch keine erkannten Portbindungen. Deshalb verwirft SpoofGuard die Pakete.
Falls SpoofGuard vor der Migration in NSX-v aktiviert ist, führen Sie nach dem Einsatz von vMotion für die VMs einen der folgenden Schritte zur Problembehebung aus:
  • Deaktivieren Sie die SpoofGuard-Richtlinien.
  • Fügen Sie die Bindungen der Port-IP und der Mac-Adresse als manuelle Bindungen hinzu.
  • Sofern ARP-Snooping aktiviert ist, warten Sie, bis die VM-IP-Adressen von ARP ermittelt wurden.

In den beiden ersten Optionen wird der Netzwerkdatenverkehr umgehend wiederhergestellt.

In der dritten Option:
  • Der Datenverkehr fällt aus, bis die VM eine ARP-Anforderung sendet oder beantwortet.
  • Wenn auch DHCP-Snooping aktiviert ist und die VM-IP-Adresse vom DHCP-Server zugewiesen wurde, wird diese höchstwahrscheinlich zuerst als ARP-IP-Adresse ermittelt und erst später als DHCP-IP-Adresse.

In der Mitte einer Cluster-Migration ist die Hostmigration aufgrund eines Hardwarefehlers auf dem Host fehlgeschlagen.

Nehmen wir zum Beispiel an, ein Cluster hat 10 Hosts und vier Hosts wurden erfolgreich migriert. Der fünfte Host hat einen Hardwarefehler und die Hostmigration schlägt fehl.
Wenn der Hardwarefehler des Hosts nicht behoben werden kann, überspringen Sie diesen ausgefallenen Host für die Migration und versuchen Sie die Migration des Hosts erneut. Führen Sie die folgenden Schritte zur Problemumgehung aus:
  1. Entfernen Sie aus der vCenter Server-Benutzeroberfläche den fehlerhaften Host aus der Bestandsliste.

    Warten Sie einige Minuten, bis der Host entfernt wird.

  2. Melden Sie sich bei der NSX-T NSX Manager-Appliance an, auf der der Migrationskoordinator-Dienst ausgeführt wird, und führen Sie die folgende API-Anforderung aus:

    GET https://{nsxt-policy-ip}/api/v1/migration/migration-unit-groups?component_type=HOST&sync=true

  3. Kehren Sie zur NSX-T NSX Manager-Benutzeroberfläche zurück und aktualisieren Sie den Browser. Beachten Sie, dass der fehlerhafte Host nicht mehr sichtbar ist.
  4. Klicken Sie auf Wiederholen, um die Hostmigration neu zu starten.
Wenn Sie den Migrationskoordinator-Dienst aus irgendeinem Grund neu starten müssen, werden die Cluster, die bereits auf NSX-T migriert sind, auf der Seite Hosts migrieren wieder für die Migration verfügbar. Dieses Verhalten ist ein bekanntes Problem. In diesem Fall besteht die Problemumgehung darin, die migrierten Cluster zu überspringen. Führen Sie dazu die folgenden Schritte aus:
  1. Öffnen Sie eine SSH-Sitzung für die NSX-T NSX Manager-Appliance, auf der der Migrationskoordinator-Dienst ausgeführt wird.
  2. Bearbeiten Sie die Datei /var/log/migration-coordinator/v2t/clusters-to-migrate.json, um die bereits migrierten Cluster zu entfernen.

    Wenn die Datei z. B. den folgenden Inhalt hat und Cluster-1 migriert wurde, entfernen Sie das Element {"modId": "domain-c9", "name": "cluster-1"}.

    "clusters":[
   {
     "modId":"domain-c9",
     "name":"cluster-1"
   },
   {
     "modId":"domain-c19",
     "name":"cluster-2"
   }
 ]
  3. Führen Sie dieselbe API-Anforderung auf der NSX Manager-Appliance aus, wie in der früheren Problemumgehung beschrieben.
  4. Kehren Sie zur NSX-T NSX Manager-Benutzeroberfläche zurück und aktualisieren Sie den Browser. Navigieren Sie zur Seite Hosts migrieren und sehen Sie, dass die Cluster, die Sie aus der Datei clusters-to-migrate.json entfernt haben, als Nicht migrieren gekennzeichnet sind.
  5. Klicken Sie auf Wiederholen, um die Hostmigration neu zu starten.

Abbrechen einer Migration

Problem Lösung
Wenn die Migration nach der Migration von Edge Services Gateways abgebrochen wird, gibt es möglicherweise veraltete VTEP-Tabellen in NSX-T. Wenn sich Transportknoten in NSX-T befinden, bleibt ihr Tunnelstatus für diese veralteten VTEPs in diesem Zustand. Um die veralteten VTEP-Daten zu entfernen, führen Sie den folgenden API-Aufruf aus: 
GET https://<nsx-manager-IP>/api/v1/global-configs/SwitchingGlobalConfig
Wenn der Parameter global_replication_mode_enabled in der Ergebnisnutzlast true ist, nehmen Sie diese Nutzlast, legen Sie global_replication_mode_enabled auf false fest und verwenden Sie die Nutzlast, um den folgenden API-Aufruf auszuführen: 
PUT https://<nsx-manager-IP>/api/v1/global-configs/SwitchingGlobalConfig
.

Probleme bei der Migration von Partnerdiensten

Problem Lösung

Der Migrationskoordinator zeigt die Rückmeldungen für die Kategorie „Service Insertion“ auch dann nicht auf der Seite Konfiguration auflösen an, wenn die Sicherheitsrichtlinien in Ihrer NSX-v-Umgebung Netzwerk-Introspektionsregeln enthalten.

Dieses Problem tritt auf, wenn Sie eine Kombination aus Guest Introspection- und Netzwerk-Introspektionsdiensten von demselben Partner migrieren. Wenn in NSX-T bereits ein Dienstprofil für den Partnerdienst erstellt wurde, initiiert der Migrationskoordinator keine Migration der Netzwerk-Introspektionsregeln.
Prüfen Sie, ob bereits ein Dienstprofil in Ihrer NSX-T-Umgebung erstellt wurde. Wenn ja, führen Sie folgende Schritte aus:
  1. Setzen Sie die Migration zurück.
  2. Löschen Sie das Partnerdienstprofil und die Dienstreferenz in NSX-T.
  3. Starten Sie die Migration neu.

Probleme nach Abschluss der Migration

Problem Lösung

Nach einer Migration und nach dem Entfernen von ESGs aus dem Netzwerk löst NSX-T Alarme aus, die besagen, dass OSPF-Nachbarn für diese ESGs inaktiv sind. Wenn Sie diese Alarme auflösen, werden sie erneut ausgelöst.

Bestätigen Sie die Alarme, lösen Sie sie jedoch nicht auf. Das verhindert, dass die Alarme erneut ausgelöst werden.