Vous pouvez voir des erreurs lors de l'exécution de la migration de NSX Data Center for vSphere. Ces informations de dépannage peuvent aider à résoudre les problèmes.

Accéder au coordinateur de migration

Problème Solution
Le coordinateur de migration n'est pas visible à System > Migrate. Vérifiez si le service de coordinateur de migration est en cours d'exécution sur NSX Manager.
manager> get service migration-coordinator
Service name:                     migration-coordinator
Service state:                    running

Si le service n'est pas en cours d'exécution, démarrez-le avec start service migration-coordinator.

Lors du retour au coordinateur de migration, la migration en cours n'est pas visible.
Le coordinateur de migration ne stocke pas les informations d'identification de vCenter Server ou NSX Manager. Si le service de coordinateur de migration est redémarré lorsqu'une migration est en cours, la page Système > Migrer peut afficher des informations de configuration périmées ou aucune information sur le programme d'installation. Pour afficher le dernier état de migration si le service de coordinateur de migration est redémarré, procédez comme suit :
  1. Actualisez la page Système > Migrer.
  2. Cliquez sur Démarrer et entrez les informations d'identification de vCenter Server et NSX Manager.

Importer les problèmes de configuration

Problème Solution
La configuration de l'importation échoue.
  1. 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 vCenter Server 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 vCenter Server, supprimez l'hôte ayant échoué de l'inventaire.

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

  2. Connectez-vous au dispositif NSX-T 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-T 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-T 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-T 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-T 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.

Annulation d'une migration

Problème Solution
Si la migration est annulée après la migration des passerelles Edge Services Gateway, des tables VTEP périmées peuvent se trouver dans NSX-T. S'il existe des nœuds de transport dans NSX-T, leur état de tunnel restera bas pour ces VTEP périmées. 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-T, 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-T. 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-T.
  3. Redémarrez la migration.