Le informazioni contenute in questa sezione potrebbero essere utili per risolvere i problemi durante la migrazione.

Problemi di importazione della configurazione

Problema Soluzione
L'importazione della configurazione non riesce. Fare clic su Riprova per provare a eseguire di nuovo l'importazione. Vengono ripetuti solo i passaggi di importazione non riusciti.

Problemi di migrazione dell'host

Problema Soluzione
La migrazione dell'host non riesce a causa di una configurazione del gestore delle risorse di elaborazione mancante.

La configurazione del gestore delle risorse di elaborazione è un prerequisito per la migrazione. Tuttavia, se la configurazione del gestore delle risorse di elaborazione viene rimossa da NSX Manager dopo l'avvio della migrazione, il coordinatore della migrazione conserva l'impostazione. La migrazione procede fino al passaggio di migrazione dell'host, che ha esito negativo.

Aggiungere un gestore delle risorse di elaborazione a NSX Manager e immettere gli stessi dettagli di vCenter Server utilizzati per l'importazione della configurazione iniziale di NSX-V.

La migrazione dell'host non riesce a causa della presenza di dvFilter obsoleti.

Messaggio di errore di esempio: Stale dvFilters present: ['port 33554463 (disconnected)', 'port 33554464 (disconnected)'] Stale dvfilters present. Aborting ]

Accedere all'host che non è riuscito a eseguire la migrazione, identificare le porte disconnesse e riavviare la macchina virtuale appropriata o connettere le porte disconnesse. È quindi possibile riprovare il passaggio di migrazione dell'host.

  1. Accedere all'interfaccia della riga di comando dell'host che non è riuscito a eseguire la migrazione.
  2. Eseguire summarize-dvfilter e cercare le porte segnalate nel messaggio di errore. 
    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. Individuare la macchina virtuale e la porta interessate.
    Ad esempio, il messaggio di errore indica che la porta 33554463 è disconnessa.
    1. Individuare la sezione dell'output summarize-dvfilter corrispondente a questa porta. Il nome della macchina virtuale è qui elencato. In questo caso, è 2-vm_RHEL-srv5.6.0.9-32-local-258-963adcb8-ab56-41d6-bd9e-2d1c329e7745.
    2. Cercare la voce name per determinare quale interfaccia della macchina virtuale è disconnessa. In questo caso, è eth1. La seconda interfaccia del 2-vm_RHEL-srv5.6.0.9-32-local-258-963adcb8-ab56-41d6-bd9e-2d1c329e7745 è quindi disconnessa.
  4. Risolvere il problema con questa porta. Eseguire uno dei passaggi seguenti:
    • Riavviare la macchina virtuale interessata.
    • Connettere la porta vNIC disconnessa a qualsiasi rete.
  5. Nella pagina Migra gli host fare clic su Riprova.

Dopo la migrazione dell'host utilizzando vMotion, è possibile che nelle macchine virtuali si verifichi un'interruzione del traffico se SpoofGuard è abilitato in NSX-V.

Sintomi:

Il file vmkernel.log nell'host che si trova in /var/run/log/ mostra un calo del traffico a causa di SpoofGuard.

Ad esempio, il file di registro mostra: 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

Causa:

Le configurazioni della porta del commutatore logico e del commutatore stesso vengono migrate tramite il coordinatore della migrazione, che esegue la migrazione della configurazione di SpoofGuard. Tuttavia, i binding di porta rilevati non vengono migrati tramite vMotion. SpoofGuard elimina quindi i pacchetti.
Se SpoofGuard è abilitato in NSX-V prima della migrazione, eseguire uno di questi passaggi della soluzione dopo vMotion delle macchine virtuali:
  • Disabilitare i criteri di SpoofGuard.
  • Aggiungere i binding degli indirizzi IP e MAC della porta come binding manuali.
  • Se lo snooping ARP è abilitato, attendere che ARP esamini gli indirizzi IP della macchina virtuale.

Nelle prime due opzioni, il traffico di rete viene ripristinato immediatamente.

Nella terza opzione:
  • Si verifica un tempo di inattività del traffico finché la macchina virtuale non invia una richiesta ARP o una risposta.
  • Se è abilitato anche lo snooping DHCP e l'indirizzo IP della macchina virtuale è stato assegnato dal server DHCP, è molto probabile che venga prima esaminato come ARP prima e successivamente come indirizzo IP con snooping DHCP.

Durante la migrazione di un cluster, la migrazione dell'host non è riuscita a causa di un errore hardware nell'host.

Ad esempio, si supponga che un cluster disponga di 10 host e che quattro host siano stati migrati correttamente. Il quinto host presenta un errore hardware e la migrazione dell'host non riesce.
Se l'errore hardware dell'host non può essere risolto, ignorare l'host che ha causato l'errore e provare a eseguire di nuovo la migrazione degli host. Completare i seguenti passaggi per risolvere il problema:
  1. Nell'interfaccia utente di vCenter Server rimuovere l'host non riuscito dall'inventario.

    Attendere alcuni minuti finché l'host non verrà rimosso.

  2. Accedere all'appliance NSX Manager in cui è in esecuzione il servizio del coordinatore della migrazione ed eseguire la seguente richiesta API:

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

  3. Tornare all'interfaccia utente di NSX-T NSX Manager e aggiornare il browser. Si tenga presente che l'host con errori non è più visibile.
  4. Fare clic su Riprova per riavviare la migrazione dell'host.
Se, per qualsiasi motivo, è necessario riavviare il servizio del coordinatore della migrazione, i cluster già migrati in NSX-T diventano di nuovo disponibili per la migrazione nella pagina Migra gli host. Questo comportamento è un problema noto. In questo caso, la soluzione consiste nell'ignorare i cluster migrati eseguendo i passaggi seguenti:
  1. Aprire una sessione SSH nell'appliance NSX-T NSX Manager in cui è in esecuzione il servizio del coordinatore della migrazione.
  2. Modificare il file /var/log/migration-coordinator/v2t/clusters-to-migrate.json per rimuovere i cluster già migrati.

    Ad esempio, se il contenuto del file è il seguente e viene eseguita la migrazione di cluster-1, rimuovere l'elemento {"modId":"domain-c9", "name":"cluster-1"}.

    "clusters":[
   {
     "modId":"domain-c9",
     "name":"cluster-1"
   },
   {
     "modId":"domain-c19",
     "name":"cluster-2"
   }
 ]
  3. Eseguire la stessa richiesta API sull'appliance NSX Manager menzionata nella soluzione precedente.
  4. Tornare all'interfaccia utente di NSX-T NSX Manager e aggiornare il browser. Passare alla pagina Migra gli host e verificare che i cluster rimossi dal file clusters-to-migrate.json vengano visualizzati come Non migrare.
  5. Fare clic su Riprova per riavviare la migrazione dell'host.
La migrazione dell'host viene bloccata dopo l'accettazione del consiglio perché la macchina virtuale del controller NSX-V è disattivata. Nel passaggio di migrazione dell'host, il feedback consiglia di interrompere la migrazione. Se si accetta il consiglio, la migrazione non riuscirà. Poiché viene eseguita la migrazione completa dell'Edge, è possibile modificare l'azione in skip e continuare la migrazione con i passaggi seguenti:
  1. Effettuare la seguente chiamata API e cercare i risultati per NoNsxvControllerInRunningSate per trovare la richiesta di feedback e ottenere il relativo ID:
    GET https://$NSX_MANAGER_IP/api/v1/migration/feedack-requests?state=UNRESOLVED
  2. Accettare tutti i consigli eseguendo la seguente chiamata API:
    POST https://$NSX_MANAGER_IP/api/v1/migration/feedback-response?action=accept-recommended
  3. Specificare una risposta al feedback con l'azione skip e la seguente chiamata API (tenere presente che $FEEDBACK_ID è l'ID ottenuto nel passaggio 1):
    PUT https://$NSX_MANAGER_IP/api/v1/migration/feedback-response -d '{"response_list":[{"id": $FEEDBACK_ID, "action": "skip" }]}'

Rollback di una migrazione

Problema Soluzione
Con alcune distribuzioni OSPF NSX-V, se si esegue un rollback dopo la fase di migrazione dell'Edge, potrebbe essere visualizzato l'errore "Motivo: NSCutover non riuscito con '400: configurazione non riuscita nella macchina virtuale NSX Edge vm-XXXX". Distribuire nuovamente la macchina virtuale NSX-V Edge pertinente. Una volta completata la ridistribuzione della macchina virtuale, eseguire nuovamente il rollback.

Nuovo tentativo di migrazione

Problema Soluzione
Se un host viene riavviato per qualsiasi motivo durante una migrazione, un nuovo tentativo di migrazione non riesce e viene visualizzato un messaggio di errore simile al seguente: "Oggetto richiesto: TransportNode/42178ba8-49fb-9545-2b78-5e9c64fddda7 non trovato. Agli identificatori degli oggetti viene applicata la distinzione maiuscole/minuscole." Eseguire i passaggi seguenti:
  1. Dall'interfaccia utente di VC, rimuovere l'host dal relativo cluster per renderlo indipendente.
  2. Dall'interfaccia utente di NSX Manager, configurare NSX sull'host indipendente utilizzando lo stesso VDS. Fare in modo che il nodo di trasporto si unisca allo stesso overlay e alle stesse zone di trasporto VLAN a cui si uniscono altri host migrati.
  3. Dall'interfaccia utente di NSX Manager, tornare alla schermata di migrazione e aggiornarla per assicurarsi che l'host non sia nel cluster da migrare. Riprovare la migrazione del cluster.
  4. Dopo la migrazione, aggiungere nuovamente l'host al cluster.

Rimozione dei dati VTEP obsoleti

Problema Soluzione
Se la migrazione viene interrotta dopo la migrazione dei gateway dei servizi Edge, è possibile che in NSX-T siano presenti tabelle VTEP obsolete. Se sono presenti nodi di trasporto in NSX-T, il loro stato del tunnel rimarrà inattivo per questi VTEP obsoleti. Per rimuovere i dati VTEP obsoleti, effettuare la seguente chiamata API: 
GET https://<nsx-manager-IP>/api/v1/global-configs/SwitchingGlobalConfig
Se il parametro global_replication_mode_enabled nel payload risultante è true, accettare questo payload, impostare global_replication_mode_enabled su false e utilizzare il payload per effettuare la seguente chiamata API: 
PUT https://<nsx-manager-IP>/api/v1/global-configs/SwitchingGlobalConfig
.

Problemi di migrazione del servizio partner

Problema Soluzione

Il coordinatore della migrazione non visualizza i messaggi di feedback per la categoria Inserimento del servizio nella pagina Risolvi configurazione nonostante i criteri di sicurezza nell'ambiente NSX-V contengano regole Network Introspection.

Questo problema si verifica quando si esegue la migrazione di una combinazione dei servizi Guest Introspection e Network Introspection dallo stesso partner. Se un profilo di servizio per il servizio partner è già stato creato in NSX-T, il coordinatore della migrazione non avvia la migrazione delle regole Network Introspection.
Verificare che nel proprio ambiente NSX-T sia già stato creato un profilo di servizio. In caso affermativo, eseguire i passaggi seguenti:
  1. Eseguire il rollback della migrazione.
  2. Eliminare il profilo del servizio partner e il riferimento del servizio in NSX-T.
  3. Riavviare la migrazione.

Problemi successivi alla migrazione

Problema Soluzione

Dopo una migrazione e dopo aver rimosso gli ESG dalla rete, NSX-T avvisa i router adiacenti OSPF inattivi per questi gruppi ESG. Se si risolvono gli allarmi, questi vengono generati nuovamente.

Riconoscere gli allarmi ma non risolverli. In questo modo gli allarmi non verranno rimossi.