FAQ et dépannage de NSX Cloud

Cette rubrique couvre des questions fréquemment posées et des informations de dépannage.

Comment puis-je réinstaller NSX Tools sur une VM Windows ?

Pour réinstaller NSX Tools sur la VM Windows :

1. Désinstallez l'instance de NSX Tools existante sur la VM Windows. Pour plus d'informations, reportez-vous au Désinstallation de NSX Tools.
2. Redémarrez la VM Windows.
   Important : Si vous ne redémarrez pas la VM Windows après la désinstallation de NSX Tools, la réinstallation peut entraîner un comportement indésirable.
3. Réinstallez NSX Tools à l'aide de la commande d'installation. Pour plus d'informations, reportez-vous à la section Installer NSX Tools sur des machines virtuelles Windows.

Comment puis-je accéder aux commandes nsxcli après l'installation de NSX Tools ?

Après l'installation de NSX Tools sur la machine virtuelle Linux :

1. Connectez-vous à la machine virtuelle Linux sur laquelle vous avez installé NSX Tools.
2. Exécutez la commande sudo service nsx-agent-chroot nsx-exec bash. Vous serez dirigé vers l'interpréteur en ligne de commande Bash.
3. maintenant exécutez la commande nsxcli. Vous serez dirigé vers l'invite nsxcli.

Vous pouvez maintenant exécuter toutes les commandes nsxcli requises, telles que get firewall rules et ainsi de suite.

Après l'installation de NSX Tools sur la machine virtuelle Windows :

1. Connectez-vous à la machine virtuelle Windows sur laquelle vous avez installé NSX Tools.
2. Ouvrez PowerShell.
3. Sur l'invite PowerShell, exécutez la commande nsxcli. Vous serez dirigé vers l'invite nsxcli.

Vous pouvez maintenant exécuter toutes les commandes nsxcli requises, telles que get firewall rules et ainsi de suite.

Comment puis-je vérifier que mes composants NSX Cloud sont installés et en cours d'exécution ?

1. Pour vérifier que les outils NSX Tools sur votre machine virtuelle de charge de travail sont connectés à PCG, procédez comme suit :

   1. Entrez la commande nsxcli pour ouvrir la CLI de NSX.

   2. Entrez la commande suivante pour obtenir l'état de connexion de la passerelle, par exemple :

      get gateway connection status
      Public Cloud Gateway  : nsx-gw.vmware.com:5555
      Connection Status 	: ESTABLISHED 

2. Les machines virtuelles de charge de travail doivent avoir des balises correctes pour se connecter à PCG :

   1. Connectez-vous à la console AWS ou au portail Microsoft Azure.

   2. Vérifiez la balise eth0 ou d'interface de la machine virtuelle.

      La clé nsx.network doit avoir la valeur default.

Mes machines virtuelles lancées à l'aide de cloud-init sont mises en quarantaine et n'autorisent pas l'installation d'outils tiers. Que dois-je faire ?

Lorsque la stratégie de mise en quarantaine est activée et que vous lancez des machines virtuelles à l'aide de scripts cloud-init avec les spécifications suivantes, vos machines virtuelles sont mises en quarantaine lors du lancement et vous ne pouvez pas y installer des applications ou des outils personnalisés :

• application de la balise nsx.network=default à la machine virtuelle
• installation automatique ou démarrage des services personnalisés lorsque la machine virtuelle est sous tension

Solution :

Mettez à jour le groupe de sécurité default (AWS) ou default-vnet-<vnet-ID>-sg (Microsoft Azure) pour ajouter des ports entrants/sortants comme requis pour l'installation d'applications personnalisées ou tierces.

J'ai correctement balisé ma machine virtuelle et installé NSX Tools, mais ma machine virtuelle est mise en quarantaine. Que dois-je faire ?

Si vous rencontrez ce problème, essayez ce qui suit :

• Vérifiez que la balise NSX Cloud: nsx.network et sa valeur : default sont correctement entrées. Ces informations sont sensibles à la casse.
• Resynchronisez le compte AWS ou Microsoft Azure à partir de CSM.
  • Connectez-vous à CSM.
  • Accédez à Clouds > AWS/Azure > Comptes.
  • Cliquez sur Actions depuis la vignette de compte de cloud public et cliquez sur Resynchroniser un compte.

Que dois-je faire si je ne peux pas accéder à ma machine virtuelle de charge de travail ?

À partir de votre Cloud Public (AWS ou Microsoft Azure) :

1. Vérifiez que tous les ports sur la machine virtuelle, y compris ceux gérés par NSX Cloud, le pare-feu du système d'exploitation (Microsoft Windows ou IPTables) et NSX sont correctement configurés afin d'autoriser le trafic.

   Par exemple, pour autoriser ping pour une machine virtuelle, les éléments suivants doivent être correctement configurés :

   • Groupe de sécurité sur AWS ou Microsoft Azure. Pour plus d'informations, reportez-vous à la section Détection des menaces à l'aide de la stratégie de mise en quarantaine de NSX Cloud.
   • Règles DFW de NSX. Reportez-vous à Stratégie de connectivité par défaut pour les machines virtuelles de charge de travail gérées par NSX dans le Mode d'application NSX pour plus de détails.
   • Pare-feu Windows ou IPTables sous Linux.
2. Essayez de résoudre le problème en vous connectant à la machine virtuelle à l'aide de SSH ou d'autres méthodes, par exemple, la console série dans Microsoft Azure.
3. Vous pouvez redémarrer la machine virtuelle verrouillée.
4. Si vous ne pouvez toujours pas accéder à la machine virtuelle, connectez une carte réseau secondaire à la machine virtuelle de charge de travail, à partir de laquelle vous pourrez accéder à cette machine.

Ai-je besoin d'un PCG même dans le Mode d'application du Cloud natif ?

Oui.

Puis-je modifier le rôle IAM de la PCG après avoir intégré mon compte de cloud public dans CSM ?

Oui. Vous pouvez réexécuter le script de NSX Cloud applicable à votre cloud public pour régénérer le rôle de la PCG. Modifiez votre compte de cloud public dans CSM avec le nouveau nom du rôle après avoir régénéré le rôle PCG. Les nouvelles instances de la PCG déployées dans votre compte de cloud public utiliseront le nouveau rôle.

Notez que les instances de PCG existantes continuent d'utiliser l'ancien rôle PCG. Si vous souhaitez mettre à jour le rôle IAM d'une instance de PCG existante, accédez à votre cloud public et modifiez manuellement le rôle de cette instance de PCG.

Puis-je utiliser les licences NSX sur site pour NSX Cloud ?

Oui, vous pouvez si votre ELA possède une clause relative à ce produit.

J'utilise l'URL de CSM pour déployer PCG, mais une erreur se produit, car le nom de la passerelle ne peut pas être résolu.

Lorsque l'URL de l'interface utilisateur de CSM pour l'installation de PCG échoue en raison d'un nom de passerelle qui ne peut pas être résolu, faites ce qui suit dans le cloud public respectif pour le système d'exploitation de votre VM de charge de travail :

• Sur les VM de charge de travail Microsoft Windows dans Microsoft Azure, exécutez la commande suivante et téléchargez de nouveau le script d'installation à l'aide de l'URL de CSM :

  Add-DnsClientNrptRule -Namespace "nsx-gw.vmware.local" -NameServers "168.63.129.16" -DnsSecEnable

• Sur les VM de charge de travail Microsoft Windows dans AWS, exécutez la commande suivante et téléchargez de nouveau le script d'installation à l'aide de l'URL de CSM :

  Add-DnsClientNrptRule -Namespace "nsx-gw.vmware.local" -NameServers "169.254.169.253" -DnsSecEnable

• Sur les VM de charge de travail Linux dans Microsoft Azure, exécutez la commande suivante pour obtenir les adresses IP de PCG et téléchargez le script d'installation à l'aide de ces adresses IP avec l'URL de CSM.

  nslookup nsx-gw.vmware.local 168.63.129.16 | awk '/^Address: / { print $2 }'

• Sur les VM de charge de travail Linux dans AWS, exécutez la commande suivante pour obtenir les adresses IP de PCG et téléchargez le script d'installation à l'aide de ces adresses IP avec l'URL de CSM.:

  nslookup nsx-gw.vmware.local 169.254.169.253 | awk '/^Address: / { print $2 }'

Comment connecter CSM à MP à l'aide d'un certificat d'autorité de certification (CA) ?

Dans les configurations de NSX Cloud, CSM se connecte à MP via un certificat auto-signé. Au lieu d'un certificat auto-signé, vous pouvez utiliser un certificat signé par une autorité de certification (CA), si nécessaire.

Pour utiliser un certificat signé par une autorité de certification (CA), procédez comme suit :

1. Connectez-vous au dispositif CSM en tant qu'utilisateur racine.
2. Copiez le fichier CA cert pem racine dans CSM.
3. Obtenez le mot de passe Java KeyStore (JKS) à partir du fichier comme suit.

   PASSWORD=`cat /config/http/.http_cert_pw`

4. Ajoutez le certificat d'autorité de certification (CA) racine au magasin JKS CSM à l'aide de la commande suivante.

   keytool -importcert -file /root/myCA.pem -noprompt -alias nsx_mgmr_custom -storetype JKS -keystore /usr/java/jre/lib/security/cacerts -storepass $PASSWORD

   Note : Cet exemple utilise /root/myCA.pem. Vous devez utiliser le chemin d'accès pour votre fichier CA cert pem racine.
5. Vérifiez si l'alias est ajouté à l'aide de la commande suivante.

   keytool -list -v -keystore /usr/java/jre/lib/security/cacerts -storepass $PASSWORD | grep
           nsx_mgmr_custom

La commande répertorie les certificats d'autorité de certification (CA) récemment ajoutés. Elle est utilisée entre CSM et NSX Manager.

Le certificat d'autorité de certification (CA) racine est désormais considéré comme valide. CSM et NSX Manager peuvent alors être appairés.