Une fois que vous aurez associé une instance de VMware Cloud Director à un SDDC dans VMware Cloud Director service, vous ne pourrez peut-être pas effectuer diverses tâches.
Problème
Une fois que vous aurez associé une instance de VMware Cloud Director à un SDDC à l'aide de VMware Proxy Service, vCenter Server peut s'afficher comme étant déconnecté. Lorsque vous tentez d'actualiser ou de vous reconnecter, cela entraîne un échec avec une exception de mise en réseau, telle que SocketTimeoutException.
Vous ne pouvez pas ouvrir une console de machine virtuelle, ni charger et télécharger des fichiers OVF et OVA.
Vous ne pouvez pas ajouter, modifier ou supprimer des ressources de mise en réseau, telles que des pools de réseaux, des réseaux externes ou des passerelles Edge.
Lorsque VMware Cloud Director effectue des appels d'API à NSX, dans le fichier vcd-debug-container.log, des entrées semblables à Received Response: 503 s'affichent.
Note : Dans les versions plus récentes du dispositif client proxy de
VMware Cloud Director service, vous pouvez utiliser la commande de dépannage
diagnose.sh pour diagnostiquer les problèmes liés au dispositif. Reportez-vous à la section
Comment dépanner le dispositif client proxy de VMware Cloud Director service ?. Si vous tentez d'exécuter la commande
diagnose.sh et que vous obtenez une erreur, suivez les instructions de dépannage décrites ci-dessous.
Cause
Cela se produit, car l'instance de VMware Cloud Director ne peut pas communiquer avec les hôtes vCenter Server, ESXi ou avec NSX via VMware Proxy Service.
Il existe deux raisons possibles à cela.
Soit la communication entre VMware Cloud Director et VMware Proxy Service a échoué, soit la communication entre VMware Cloud Director et la machine virtuelle proxy que vous avez déployée lors de l'association de l'instance au SDDC VMware Cloud on AWS a réussi, mais la connexion entre le service de proxy et vCenter Server ou NSX échoue.
Conditions préalables
- Localisez la machine virtuelle cliente du proxy inverse VMware que vous avez déployée lors de l'association entre le SDDC et l'instance de VMware Cloud Director dans le pool de ressources de l'interface utilisateur de vCenter Server.
- Connectez-vous au SE de la machine virtuelle cliente du proxy inverse en tant que racine.
Info-bulle : Vous trouverez le mot de passe de l'utilisateur
racine dans les propriétés du vApp de la machine virtuelle sous
root-password.
Solution
- Pour vérifier que la machine virtuelle dispose d'une connectivité réseau, exécutez la commande
transporter-status.sh.
Si la machine virtuelle est connectée, la commande renvoie l'état
UP et l'état de
command_channel_1 et
command_channel_2 comme
CONNECTED.
- Vérifiez que la machine virtuelle cliente du proxy inverse VMware dispose d'une adresse IPv4 valide.
- Accédez à la machine virtuelle dans le pool de ressources de vCenter Server et vérifiez si la machine virtuelle dispose d'une adresse IPv4 valide.
- Si la machine virtuelle ne dispose pas d'une adresse IPv4 valide, choisissez l'une des adresses suivantes.
- Exécutez une demande cURL sur l'URL dans laquelle les dernières images de la machine virtuelle cliente du proxy inverse VMware sont stockées.
- À partir du SE de la machine virtuelle cliente du proxy inverse VMware, exécutez une demande cURL sur le service proxy VMware.
curl -v <VMware-Proxy-Service-IP-address>
Vous trouverez l'adresse IP du service proxy VMware dans les propriétés du vApp de la machine virtuelle cliente du proxy inverse VMware, sous
reverse-proxy-host.
La commande renvoie un résultat similaire au suivant.
Connected to <VMware-Proxy-Service-IP-address> port 80
- Vérifiez qu'il n'existe aucune règle de pare-feu ni aucun autre problème de mise en réseau qui empêche la machine virtuelle cliente du proxy inverse VMware d'envoyer une requête ping sur vCenter Server, NSX et ESXi.
Si la liste de cibles autorisées inclut une notation CIDR et qu'il vous est impossible d'atteindre l'un des hôtes qu'elle contient, vérifiez que vous pouvez effectuer un test ping sur l'hôte spécifique. Si vous réussissez, ajoutez l'adresse IP ou le nom de domaine complet de l'hôte à la liste comme entrée distincte.
- Vérifiez que la machine virtuelle cliente du proxy inverse VMware utilise un jeton d'API valide.
Vous trouverez le jeton d'API actuel dans les propriétés du vApp de la machine virtuelle cliente du proxy inverse VMware, sous
csp-token.
- Exécutez une demande POST sur https://console.cloud.vmware.com/csp/gateway/am/api/auth/api-tokens/authorize avec
refresh_token={your-api-token-value} dans le corps de la demande.
Par exemple :
curl --location --request POST 'https://console.cloud.vmware.com/csp/gateway/am/api/auth/api-tokens/authorize' \
--header 'Accept: application/json' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Cookie: incap_ses_8217_1285679=sJfafQlQfgUmPGK0X6YIckRAaWIAAAAAZ5DsTuKH0eALPsXXCrk1Lw==; nlbi_1285679=qGFfKYa/khghkd06+iiRRwAAAAA7h7npdR2O1o9/MIk2Plre' \
--data-urlencode 'refresh_token=<your-csp-token>'
Si votre jeton d'API a expiré, la demande renvoie un message Invalid Token ou une erreur 400 Bad Request. Reportez-vous à la section Comment renouveler le jeton d'API de la machine virtuelle cliente du proxy inverse VMware ?
Si votre jeton d'API est valide, la demande renvoie une réponse qui contient un jeton d'accès, par exemple :
{
"id_token": "eyJhbGciOiJS.......srRmGX9eYKOKMA",
"token_type": "bearer",
"expires_in": 1799,
"scope": "ALL_PERMISSIONS openid group_ids group_names",
"access_token": "eyJhbGciOiJSU.........Q6Y9Yohgw",
"refresh_token": "B4STbh2fYFmjI9ABCv..............XeRniDiO4cBJjF82sWWprZfm7OLHn"
}
La partie pertinente est access_token, qui commence toujours par "ey" et constitue un jeton Web JSON (JWT).
- Copiez la valeur
access_token et copiez-la dans la section Codé à l'adresse https://jwt.io/.
- Vérifiez que dans la charge utile,
context_name contient l'ID de votre organisation VMware Cloud et que la section Perms contient le rôle de fournisseur:réseau.
