Die Informationen in diesem Abschnitt können bei der Behebung von Problemen während der Migration hilfreich sein.

Probleme beim Importieren der Konfiguration

Problem Lösung
Die Konfiguration kann nicht importiert werden. 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 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.
Die Hostmigration wird blockiert, nachdem die Empfehlung akzeptiert wurde, da sich NSX-V Controller-VM im Ausgeschaltet-Zustand befindet. Im Schritt zur Hostmigration empfiehlt das Feedback, die Migration abzubrechen. Wenn Sie die Empfehlung akzeptieren, schlägt die Migration fehl. Da die Edge-Übernahme abgeschlossen ist, können Sie die Aktion in skip ändern und die Migration mit den folgenden Schritten fortsetzen:
  1. Führen Sie den folgenden API-Aufruf aus und suchen Sie das Ergebnis nach NoNsxvControllerInRunningSate, um die Feedback-Anforderung zu finden und ihre ID abzurufen:
    GET https://$NSX_MANAGER_IP/api/v1/migration/feedack-requests?state=UNRESOLVED
  2. Akzeptieren Sie alle Empfehlungen, indem Sie den folgenden API-Aufruf ausführen:
    POST https://$NSX_MANAGER_IP/api/v1/migration/feedback-response?action=accept-recommended
  3. Geben Sie eine Feedbackantwort mit der Aktion skip mit dem folgenden API-Aufruf ein (beachten Sie, dass $FEEDBACK_ID die ID ist, die Sie in Schritt 1 erhalten haben):
    PUT https://$NSX_MANAGER_IP/api/v1/migration/feedback-response -d '{"response_list":[{"id": $FEEDBACK_ID, "action": "skip" }]}'

Rollback einer Migration

Problem Lösung
Wenn Sie bei einigen NSX-V OSPF-Bereitstellungen nach der Edge-Migrationsphase ein Rollback durchführen, wird möglicherweise der Fehler „Grund: NSCutover fehlgeschlagen mit '400: Konfiguration fehlgeschlagen auf NSX Edge VM vm-XXXX“ angezeigt. Stellen Sie die relevante NSX-V Edge-VM erneut bereit. Nachdem die VM erfolgreich erneut bereitgestellt wurde, führen Sie das Rollback erneut durch.

Wiederholen einer Migration

Problem Lösung
Wenn ein Host während einer Migration aus irgendeinem Grund neu gestartet wird, schlägt das Wiederholen der Migration mit einer Fehlermeldung ähnlich der folgenden fehl: „Das angeforderte Objekt : TransportNode/42178ba8-49fb-9545-2b78-5e9c64fddda7 konnte nicht gefunden werden. Bei Objektbezeichnern wird die Groß-/Kleinschreibung berücksichtigt.“ Führen Sie die folgenden Schritte aus:
  1. Entfernen Sie über die VC-Benutzeroberfläche den Host aus seinem Cluster und machen Sie ihn zu einem eigenständigen Host.
  2. Konfigurieren Sie auf der NSX Manager-Benutzeroberfläche NSX auf dem eigenständigen Host, der denselben VDS verwendet. Verbinden Sie den Transportknoten mit denselben Overlay- und VLAN-Transportzonen, denen andere migrierte Hosts beitreten.
  3. Navigieren Sie über die NSX Manager-Benutzeroberfläche zurück zum Migrationsbildschirm und aktualisieren Sie ihn, um sicherzustellen, dass sich der Host nicht in dem zu migrierenden Cluster befindet. Wiederholen der Migration des Clusters.
  4. Fügen Sie nach der Migration den Host wieder zum Cluster hinzu.

Entfernen veralteter VTEP-Daten

Problem Lösung
Wenn die Migration nach der Migration von Edge Services Gateways abgebrochen wird, sind in NSX-T möglicherweise veraltete VTEP-Tabellen vorhanden. Wenn in NSX-T Transportknoten vorhanden sind, bleibt der Tunnelstatus für diese veralteten VTEPs „Inaktiv“. 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.