Les informations de cette section peuvent être utiles pour résoudre les problèmes lors de la migration.

Importer les problèmes de configuration

Problème Solution
La configuration de l'importation échoue. Cliquez sur Réessayer pour essayer à nouveau d'importer. Seules les étapes d'importation ayant échoué sont réessayées.

Problèmes de migration de l'hôte

Problème Solution
La migration vers un hôte échoue en raison d'une configuration du gestionnaire de calcul manquante.

La configuration du gestionnaire de calcul est une condition préalable pour la migration. Cependant, si la configuration du gestionnaire de calcul est supprimée du dispositif NSX Manager après le démarrage de la migration, le coordinateur de migration conserve le paramètre. La migration se poursuit jusqu'à ce l'étape de migration de l'hôte, qui échoue.

Ajoutez un gestionnaire de calcul à NSX Manager et entrez les mêmes détails de VMware vCenter utilisés pour l'importation de la configuration initiale de NSX-V.

La migration de l'hôte échoue en raison de dvFilters périmés présents.

Exemple de message d'erreur : Stale dvFilters present: ['port 33554463 (disconnected)', 'port 33554464 (disconnected)'] Stale dvfilters present. Aborting ]

Connectez-vous à l'hôte qui n'a pas pu migrer, identifiez les ports déconnectés, et redémarrez la machine virtuelle appropriée ou connectez les ports déconnectés. Recommencez l'étape de la Migration de l'hôte.

  1. Connectez-vous à l'interface de ligne de commande de l'hôte qui n'a pas pu migrer.
  2. Exécutez summarize-dvfilter et recherchez les ports signalés dans le message d'erreur. 
    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. Localisez la machine virtuelle et le port concernés.
    Par exemple, le message d'erreur indique que le port 33554463 est déconnecté.
    1. Recherchez la section de la sortie de summarize-dvfilter qui correspond à ce port. Le nom de la machine virtuelle est répertorié ici. Dans ce cas, il s'agit de 2-vm_RHEL-srv5.6.0.9-32-local-258-963adcb8-ab56-41d6-bd9e-2d1c329e7745.
    2. Recherchez l'entrée de name déterminer quelle interface de machine virtuelle est déconnectée. Dans ce cas, il s'agit de eth1. Par conséquent, la seconde interface de 2-vm_RHEL-srv5.6.0.9-32-local-258-963adcb8-ab56-41d6-bd9e-2d1c329e7745 est déconnectée.
  4. Résolvez le problème avec ce port. Effectuez l'une des étapes suivantes :
    • Redémarrez la machine virtuelle affectée.
    • Connectez le port vnic déconnecté à n'importe quel réseau.
  5. Sur la page Migrer les hôtes, cliquez sur Réessayer.

Après la migration de l'hôte à l'aide de vMotion, les machines virtuelles peuvent subir une interruption du trafic si SpoofGuard est activé dans NSX-V.

Symptômes :

Le fichier vmkernel.log sur l'hôte dans /var/run/log/ affiche une perte de trafic en raison de SpoofGuard.

Par exemple, le fichier journal indique : 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

Cause :

Le commutateur logique et la configuration du port de commutateur logique sont migrés via le coordinateur de migration, qui migre la configuration SpoofGuard. Cependant, les liaisons de port détectées ne sont pas migrées via vMotion. Par conséquent, SpoofGuard abandonne les paquets.
Si SpoofGuard est activé dans NSX-V avant la migration, essayez l'une de ces solutions après le déplacement vMotion des machines virtuelles :
  • Désactivez les stratégies SpoofGuard.
  • Ajoutez les liaisons d'adresse IP et d'adresse MAC du port en tant que liaisons manuelles.
  • Si l'écoute ARP est activée, attendez que les adresses IP de la machine virtuelle soient écoutées par ARP.

Dans les deux premières options, le trafic réseau est restauré immédiatement.

Dans la troisième option :
  • Une interruption du trafic est observée jusqu'à ce que la machine virtuelle envoie une demande ou une réponse ARP.
  • Si l'écoute DHCP est également activée et que l'adresse IP de la machine virtuelle a été attribuée par le serveur DHCP, elle sera probablement écoutée en tant qu'ARP et ensuite en tant qu'adresse IP d'écoute DHCP.

Au milieu de la migration d'un cluster, la migration de l'hôte a échoué en raison d'une panne matérielle dans l'hôte.

Par exemple, supposons qu'un cluster dispose de 10 hôtes et que la migration de 4 hôtes a réussi. Le cinquième hôte présente une panne matérielle et la migration de l'hôte échoue.
Si la panne matérielle de l'hôte ne peut pas être corrigée, ignorez cet hôte ayant échoué pour la migration, puis réessayez la migration de l'hôte. Effectuez les étapes suivantes pour résoudre ce problème :
  1. Dans l'interface utilisateur de VMware vCenter, supprimez l'hôte ayant échoué de l'inventaire.

    Attendez quelques minutes que l'hôte soit supprimé.

  2. Connectez-vous au dispositif NSX Manager sur lequel le service de coordinateur de migration est en cours d'exécution, puis exécutez la demande d'API suivante :

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

  3. Revenez à l'interface utilisateur de NSX NSX Manager et actualisez le navigateur. Notez que l'hôte ayant échoué n'est plus visible.
  4. Cliquez sur Réessayer pour reprendre la migration de l'hôte.
Si vous devez redémarrer le service de coordinateur de migration pour une raison quelconque, les clusters déjà migrés vers NSX deviennent à nouveau disponibles pour la migration sur la page Migrer les hôtes. Ce comportement est un problème connu. Dans ce cas, la solution consiste à ignorer les clusters migrés en effectuant les étapes suivantes :
  1. Ouvrez une session SSH vers le dispositif NSX NSX Manager sur lequel le service de coordinateur de migration est en cours d'exécution.
  2. Modifiez le fichier /var/log/migration-coordinator/v2t/clusters-to-migrate.json pour supprimer les clusters déjà migrés.

    Par exemple, si le fichier a le contenu suivant et si cluster-1 a été migré, supprimez l'élément {"modId":"domain-c9", "name":"cluster-1"}.

    "clusters":[
   {
     "modId":"domain-c9",
     "name":"cluster-1"
   },
   {
     "modId":"domain-c19",
     "name":"cluster-2"
   }
 ]
  3. Exécutez la même demande d'API sur le dispositif NSX Manager comme mentionné dans la solution précédente.
  4. Revenez à l'interface utilisateur de NSX NSX Manager et actualisez le navigateur. Accédez à la page Migrer les hôtes et notez que les clusters que vous avez supprimés du fichier clusters-to-migrate.json sont affichés comme Ne pas migrer.
  5. Cliquez sur Réessayer pour reprendre la migration de l'hôte.
La migration de l'hôte est bloquée après l'acceptation de la recommandation, car la machine virtuelle NSX-V Controller est hors tension. Dans l'étape de migration de l'hôte, les commentaires vous recommandent d'abandonner la migration. Si vous acceptez la recommandation, la migration échouera. Étant donné que le basculement Edge est terminé, vous pouvez modifier l'action sur skip et poursuivre la migration en procédant comme suit :
  1. Effectuez l'appel d'API suivant et recherchez le résultat pour NoNsxvControllerInRunningSate afin de trouver la demande de commentaires et obtenir son ID :
    GET https://$NSX_MANAGER_IP/api/v1/migration/feedack-requests?state=UNRESOLVED
  2. Acceptez toutes les recommandations en effectuant l'appel d'API suivant :
    POST https://$NSX_MANAGER_IP/api/v1/migration/feedback-response?action=accept-recommended
  3. Fournissez une réponse de commentaires avec l'action skip avec l'appel d'API suivant (notez que $FEEDBACK_ID est l'ID que vous avez obtenu à l'étape 1) :
    PUT https://$NSX_MANAGER_IP/api/v1/migration/feedback-response -d '{"response_list":[{"id": $FEEDBACK_ID, "action": "skip" }]}'

Restauration d'une migration

Problème Solution
Avec certains déploiements OSPF NSX-V, si vous effectuez une restauration après la phase de migration Edge, vous pouvez voir l'erreur « Raison : échec de NSCutover avec '400 : échec de la configuration sur la VM vm-XXXX ». Redéployez la machine virtuelle NSX-V Edge appropriée. Une fois la machine virtuelle redéployée, effectuez à nouveau la restauration.

Nouvelle tentative de migration

Problème Solution
Si un hôte redémarre pour une raison quelconque pendant une migration, une nouvelle tentative de migration échoue avec une erreur telle que « L'objet demandé : TransportNode/42178ba8-49fb-9545-2b78-5e9c64fddda7 est introuvable. Les identificateurs d'objets respectent la casse. » Procédez comme suit :
  1. Dans l'interface utilisateur de VC, supprimez l'hôte de son cluster et faites-en un hôte autonome.
  2. Dans l'interface utilisateur de NSX Manager, configurez NSX sur l'hôte autonome à l'aide du même VDS. Faites en sorte que le nœud de transport joigne les mêmes zones de transport de superposition et de VLAN que d'autres hôtes migrés.
  3. Dans l'interface utilisateur de NSX Manager, revenez à l'écran de migration, actualisez-le pour vous assurer que l'hôte ne se trouve pas dans le cluster en cours de migration. Réessayez la migration du cluster.
  4. Après la migration, rajoutez l'hôte au cluster.

Suppression des données VTEP périmées

Problème Solution
Si la migration est abandonnée après la migration des passerelles Edge Services Gateway, des tables VTEP périmées peuvent se trouver dans NSX. S'il existe des nœuds de transport dans NSX, leur état de tunnel restera inactif pour ces VTEP périmés. Pour supprimer les données VTEP périmées, effectuez l'appel d'API suivant : 
GET https://<nsx-manager-IP>/api/v1/global-configs/SwitchingGlobalConfig
Si le paramètre global_replication_mode_enabled dans la charge utile des résultats est true prenez cette charge utile, définissez global_replication_mode_enabled sur false et utilisez la charge utile pour effectuer l'appel d'API suivant : 
PUT https://<nsx-manager-IP>/api/v1/global-configs/SwitchingGlobalConfig
.

Problèmes de migration de service de partenaires

Problème Solution

Le coordinateur de migration n'affiche pas les messages de commentaires pour la catégorie d'insertion de services sur la page Résoudre la configuration, même si les stratégies de sécurité de votre environnement NSX-V contiennent des règles d'introspection réseau.

Ce problème se produit lorsque vous migrez une combinaison de services Guest Introspection et Introspection réseau à partir du même partenaire. Si un profil de service pour le service de partenaires est déjà créé dans NSX, le coordinateur de migration n'initie pas la migration des règles d'introspection réseau.
Vérifiez si un profil de service est déjà créé dans votre environnement NSX. Si c'est le cas, procédez comme suit :
  1. Restaurez la migration.
  2. Supprimez le profil de service de partenaires et la référence de service dans NSX.
  3. Redémarrez la migration.

Problèmes de post-migration

Problème Solution

Après une migration et après la suppression des passerelles ESG du réseau, NSX déclenche des alarmes sur les voisins OSPF inactifs pour ces passerelles ESG. Si vous résolvez les alarmes, elles seront déclenchées à nouveau.

Reconnaître les alarmes mais ne pas les résoudre. Cela empêchera les alarmes de se déclencher à nouveau.