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 à | .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 |
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
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 :
|
Importer les problèmes de configuration
Problème | Solution |
---|---|
La configuration de l'importation échoue. |
|
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 : |
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.
|
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 : 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 :
Dans les deux premières options, le trafic réseau est restauré immédiatement.
Dans la troisième option :
|
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 :
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 :
|
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 :
|
Problèmes de post-migration
Problème | Solution |
---|---|
Après une migration et après la suppression des passerelles ESG du réseau, NSX-T 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. |