Partage via

Résoudre les problèmes liés au pont de ressources Azure Arc

  • Article

Cet article fournit des informations sur la résolution et la résolution des problèmes qui peuvent se produire lors de la tentative de déploiement, d’utilisation ou de suppression du pont de ressources Azure Arc. Le pont de ressources est une machine virtuelle empaquetée, qui héberge un cluster Kubernetes de gestion. Pour plus d’informations générales, consultez vue d’ensemble du pont de ressources Azure Arc.

Problèmes généraux

Collection de journaux

Pour les problèmes rencontrés avec le pont de ressources Arc, collectez les journaux pour une investigation plus approfondie à l’aide de la commande Azure CLI az arcappliance logs. Vous devez exécuter cette commande à partir de la même machine de gestion que celle utilisée pour déployer le pont de ressources Arc. Si vous utilisez une autre machine, elle doit répondre aux exigences de la machine de gestion.

En cas de problème rencontré lors de la collecte des journaux, la machine de gestion ne peut probablement pas accéder à la machine virtuelle de l’appliance. Contactez votre administrateur réseau pour permettre la communication SSH entre la machine de gestion et la machine virtuelle de l’appliance sur le port TCP 22.

Vous pouvez collecter les journaux de pont de ressources Arc en transmettant l’adresse IP de la machine virtuelle de l’appliance ou le kubeconfig dans la commande logs.

Pour collecter des journaux de pont de ressources Arc sur VMware à l’aide de l’adresse IP de la machine virtuelle de l’appliance, procédez comme suit :

az arcappliance logs vmware --ip <appliance VM IP> --username <vSphere username> --password <vSphere password> --address <vCenter address> --out-dir <path to output directory>

Pour collecter des journaux de pont de ressources Arc pour Azure Stack HCI à l’aide de l’adresse IP de la machine virtuelle de l’appliance, procédez comme suit :

az arcappliance logs hci --ip <appliance VM IP> --cloudagent <cloud agent service IP/FQDN> --loginconfigfile <file path of kvatoken.tok>

Si vous n’êtes pas sûr de l’adresse IP de votre machine virtuelle d’appliance, vous pouvez aussi utiliser kubeconfig. Vous pouvez récupérer le kubeconfig en exécutant la commande get-credentials puis exécuter la commande logs.

Pour récupérer la clé kubeconfig et la clé de journal, collectez les journaux d’activité pour VMware avec Arc à partir d’une autre machine que celle utilisée pour déployer le pont de ressources Arc pour VMware avec Arc :

az account set -s <subscription id>
az arcappliance get-credentials -n <Arc resource bridge name> -g <resource group name> 
az arcappliance logs vmware --kubeconfig kubeconfig --out-dir <path to specified output directory>

La connectivité de téléchargement/chargement n’a pas réussi

Si la vitesse de votre réseau est lente, vous risquez de ne pas pouvoir télécharger correctement l’image de machine virtuelle de pont de ressources Arc et cette erreur peut se produire : ErrorCode: ValidateKvaError, Error: Pre-deployment validation of your download/upload connectivity was not successful. Timeout error occurred during download and preparation of appliance image to the on-premises fabric storage. Common causes of this timeout error are slow network download/upload speeds, a proxy limiting the network speed or slow storage performance.

Si l’erreur est due à la lenteur du réseau qui affecte le chargement, une solution de contournement consiste à créer une machine virtuelle directement sur le cloud privé local, puis à exécuter le script de déploiement du pont de ressources Arc à partir de cette machine virtuelle. Cette solution de contournement garantit un chargement plus rapide de l’image vers le magasin de données.

Le contexte a expiré pendant la phase ApplyingKvaImageOperator

Vous pouvez recevoir l’erreur suivante lors du déploiement du pont de ressources Arc : Deployment of the Arc resource bridge appliance VM timed out. Please collect logs with _az arcappliance logs_ and create a support ticket for help. To troubleshoot the error, refer to aka.ms/arc-rb-error { _errorCode_: _ContextError_, _errorResponse_: _{\n\_message\_: \_Context timed out during phase _ApplyingKvaImageOperator_\_\n}_ }

Cette erreur se produit généralement lors de la tentative de téléchargement de l’image KVAIO (400 Mo compressée) sur un réseau lent ou présentant une connectivité intermittente. Le gestionnaire de contrôleurs KVAIO attend que le téléchargement de l’image se termine et expire. Vous pouvez vérifier que la vitesse de votre réseau entre la machine virtuelle de pont de ressources Arc et Microsoft Container Registry (mcr.microsoft.com) est stable à au moins 2 Mbits/s. Si votre connectivité réseau et votre vitesse sont stables et que vous recevez toujours cette erreur, attendez au moins 30 minutes avant de réessayer, car Microsoft Container Registry peut recevoir un volume élevé de trafic.

Le contexte a expiré pendant la phase WaitingForAPIServer

Lors du déploiement du pont de ressources Arc, vous pouvez recevoir l’erreur suivante : Deployment of the Arc resource bridge appliance VM timed out. Please collect logs with _az arcappliance logs_ and create a support ticket for help. To troubleshoot the error, refer to aka.ms/arc-rb-error { _errorCode_: _ContextError_, _errorResponse_: _{\n\_message\_: \_Context timed out during phase _WaitingForAPIServer

Cette erreur indique que l’ordinateur de déploiement ne peut pas contacter l’adresse IP du plan de contrôle pour le pont de ressources Arc dans le délai imparti. Les causes courantes de l’erreur sont souvent liées à la mise en réseau, telles que la communication entre l’ordinateur de déploiement et l’adresse IP du plan de contrôle acheminée via un proxy. Le trafic de l’ordinateur de déploiement vers le plan de contrôle et les adresses IP de machine virtuelle de l’appliance ne doivent pas passer par proxy même s’il en existe un. Cette erreur peut également se produire lorsqu’un pare-feu ferme l’accès au port 6443 et au port 22 entre l’ordinateur de déploiement et l’adresse IP du plan de contrôle ou l’ordinateur de déploiement et les adresses IP de machine virtuelle de l’appliance.

Le pont de ressources Arc est hors connexion

Si le pont de ressources est hors connexion, cela est généralement dû à un changement de mise en réseau dans l’infrastructure, l’environnement ou le cluster qui empêche la machine virtuelle de l’appliance de fonctionner ou de communiquer avec la ressource Azure correspondante. Si vous ne parvenez pas à déterminer ce qui a changé, vous pouvez redémarrer la machine virtuelle de l’appliance, collecter des journaux et envoyer un ticket de support pour une investigation plus approfondie.

Remote PowerShell n’est pas pris en charge

Si vous exécutez les commandes CLI az arcappliance pour Arc Resource Bridge via PowerShell à distance, vous pouvez rencontrer différents problèmes. Par exemple, vous pouvez voir une erreur d’échec de l’échange d’authentification lorsque vous essayez d’installer le pont de ressources sur un cluster Azure Stack HCI ou un autre type d’erreur. L’utilisation de commandes az arcappliance à partir de PowerShell distantes n’est actuellement pas prise en charge. Au lieu de cela, connectez-vous au nœud via le protocole RDP (Remote Desktop Protocol) ou utilisez une session de console.

Les configurations du pont de ressources ne peuvent pas être mises à jour

Dans cette version, tous les paramètres sont spécifiés au moment de la création. Pour mettre à jour le pont de ressources Azure Arc, vous devez le supprimer et le redéployer. Par exemple, si vous avez spécifié un emplacement incorrect ou un abonnement lors du déploiement, la création de la ressource échoue ultérieurement. Si vous tentez de recréer la ressource sans avoir à redéployer la machine virtuelle du pont de ressources, vous verrez l’état bloqué à WaitForHeartBeat. Pour résoudre ce problème, supprimez l’appliance et mettez à jour le fichier YAML de l’appliance. Ensuite, redéployez et créez le pont de ressources.

Réseau de l’appliance indisponible

Si le pont de ressources Arc rencontre un problème réseau, une erreur « Le réseau de l’appliance n’est pas disponible » peut s’afficher. En général, tout problème de connectivité réseau ou de l’infrastructure à la machine virtuelle de l’appliance peut entraîner cette erreur. Cette erreur peut également apparaître comme suit : « Erreur lors de la numérotation tcp xx.xx.xxx.xx:55000 : connexion : aucun itinéraire à héberger ». Le problème peut venir du fait que la communication de l’hôte vers la machine virtuelle de pont de ressources Arc doit être ouverte sur le port TCP 22 avec l’aide de votre administrateur réseau. Un problème réseau temporaire peut ne pas permettre à l’hôte d’atteindre la machine virtuelle de pont de ressources Arc. Une fois le problème réseau résolu, vous pouvez réessayer l’opération. Vous pouvez également vérifier le fonctionnement ou la connexion de la machine virtuelle de l’appliance du pont de ressources Arc. Dans le cas d’Azure Stack HCI, le stockage hôte peut être plein. Si c’est le cas, vous devez résoudre la problématique du stockage.

Erreur d’actualisation du jeton

Lorsque vous exécutez les commandes Azure CLI, l’erreur suivante peut être retournée : Le jeton d’actualisation a expiré ou n’est pas valide en raison des vérifications de fréquence de connexion par accès conditionnel. L’erreur se produit car lorsque vous vous connectez à Azure, le jeton a une durée de vie maximale. Lorsque cette durée de vie est dépassée, vous devez vous reconnecter à Azure avec la commande az login.

Les pools de ressources hôtes par défaut ne sont pas disponibles pour le déploiement

Lors de l’utilisation de la commande az arcappliance createconfig ou az arcappliance run, une expérience interactive affiche la liste des entités VMware où vous pouvez choisir de déployer l’appliance virtuelle. Cette liste affiche tous les pools de ressources créés par l’utilisateur. ainsi que les pools de ressources de cluster par défaut, mais les pools de ressources hôtes par défaut ne sont pas répertoriés. Lorsque l’appliance est déployée sur un pool de ressources hôte, il n’existe aucune haute disponibilité en cas d’échec du matériel hôte. Nous vous recommandons de ne pas essayer de déployer l’appliance dans un pool de ressources hôte.

État du pont de ressources « Hors connexion » et provisioningState « Échec »

Lors du déploiement du pont de ressources Arc, le pont peut sembler être correctement déployé, car aucune erreur n’a été rencontrée lors de l’exécution de az arcappliance deploy ou de az arcappliance create. Toutefois, lors de l’affichage du pont dans le portail Azure, l’état peut s’afficher comme hors connexion et az arcappliance show peut afficher le provisioningState comme échec. Cela se produit lorsque les fournisseurs requis ne sont pas inscrits avant le déploiement du pont.

Pour résoudre ce problème, supprimez le pont de ressources, inscrivez les fournisseurs, puis redéployez le pont de ressources.

  1. Supprimez le pont de ressources :

    az arcappliance delete <fabric> --config-file <path to appliance.yaml>

  2. Inscrivez les fournisseurs :

    az provider register --namespace Microsoft.ExtendedLocation –-wait
az provider register --namespace Microsoft.ResourceConnector –-wait

  3. Redéployez le pont des ressources.

Remarque

Les produits partenaires (tels que VMware vSphere avec Arc) peuvent avoir leurs propres fournisseurs requis pour s’inscrire. Pour afficher d’autres fournisseurs qui doivent être inscrits, consultez la documentation du produit.

Informations d’identification expirées dans la machine virtuelle de l’appliance

Le pont de ressources Arc se compose d’une machine virtuelle d’appliance déployée sur l’infrastructure locale. La machine virtuelle de l’appliance gère une connexion au point de terminaison de gestion de l’infrastructure locale à l’aide d’informations d’identification stockées localement. Si ces informations d’identification ne sont pas mises à jour, le pont de ressources ne peut plus communiquer avec le point de terminaison de gestion. Cela peut entraîner des problèmes lors de la mise à niveau du pont de ressources ou de la gestion des machines virtuelles via Azure. Pour résoudre ce problème, les informations d’identification de la machine virtuelle de l’appliance doivent être mises à jour. Pour plus d’informations, consultez Mettre à jour les informations d’identification dans la machine virtuelle de l’appliance.

Le pont de ressources Arc ne prend pas en charge la liaison privée. Aucun des appels provenant de la machine virtuelle de l’appliance ne doit passer par votre configuration de liaison privée. Les adresses IP Private Link peuvent entrer en conflit avec la plage du pool d’adresses IP de l’appliance, qui ne peut pas être configurée sur le pont de ressources. Le pont de ressources Arc accède aux URL requises. Celles-ci ne doivent pas passer par une connexion de liaison privée. Vous devez déployer le pont de ressources Arc sur un segment réseau distinct non lié à la configuration de la liaison privée.

Problèmes de mise en réseau

Erreur d’extraction d’image de sauvegarde

Lorsque vous essayez de déployer un pont de ressources Arc, vous pouvez voir une erreur qui contient back-off pulling image \\\"url"\\\: FailFastPodCondition. Cette erreur est due au fait que la machine virtuelle de l’appliance ne peut pas atteindre l’URL spécifiée dans l’erreur. Pour résoudre ce problème, assurez-vous que la machine virtuelle de l’appliance répond à la configuration système requise, y compris la connectivité à l’accès Internet à URL de liste verte requises.

Impossible de se connecter à l’URL

Si vous recevez une erreur qui contient Not able to connect to https://example.url.com, vérifiez auprès de votre administrateur réseau pour vous assurer que votre réseau autorise tous les URL de pare-feu et de proxy requises à déployer le pont de ressources Arc. Pour plus d’informations, consultez configuration réseau requise pour le pont des ressources Azure Arc.

Le serveur Http2 a envoyé GOAWAY

Lorsque vous essayez de déployer un pont de ressources Arc, vous pouvez recevoir un message d’erreur similaire à ce qui suit :

"errorResponse": "{\n\"message\": \"Post \\\"https://region.dp.kubernetesconfiguration.azure.com/azure-arc-appliance-k8sagents/GetLatestHelmPackagePath?api-version=2019-11-01-preview\\u0026releaseTrain=stable\\\": http2: server sent GOAWAY and closed the connection; LastStreamID=1, ErrCode=NO_ERROR, debug=\\\"\\\"\"\n}"

Cela survient lorsqu’un pare-feu ou un proxy a la fonctionnalité d’inspection SSL/TLS activée et bloque les appels http2 depuis la machine utilisée pour déployer le pont de ressources. Pour confirmer le problème, exécutez l’applet de commande PowerShell suivante pour appeler la requête web avec http2 (nécessite PowerShell version 7 ou ultérieure), en remplaçant la région dans l’URL et la version de l’API (ex : 2019-11-01) par les valeurs de l’erreur :

Invoke-WebRequest -HttpVersion 2.0 -UseBasicParsing -Uri https://region.dp.kubernetesconfiguration.azure.com/azure-arc-appliance-k8sagents/GetLatestHelmPackagePath?api-version=2019-11-01-preview"&"releaseTrain=stable -Method Post -Verbose

Si le résultat est The response ended prematurely while waiting for the next frame from the server, l’appel http2 est bloqué et doit être autorisé. Collaborez avec votre administrateur réseau pour désactiver l’inspection SSL/TLS afin d’autoriser les appels http2 depuis l’ordinateur utilisé pour déployer le pont.

Aucun hôte de ce type – .local non pris en charge

Lorsque vous essayez de définir la configuration du pont de ressources Arc, vous pouvez recevoir un message d’erreur similaire à ce qui suit :

"message": "Post \"https://esx.lab.local/52c-acac707ce02c/disk-0.vmdk\": dial tcp: lookup esx.lab.local: no such host"

Cela se produit lorsqu’un chemin d’accès .local est fourni pour un paramètre de configuration, tel que proxy, dns, magasin de données ou point de terminaison de gestion (tel que vCenter). La machine virtuelle de l’appliance de pont de ressources Arc utilise le système d’exploitation Linux Azure, qui ne prend pas en charge les .local par défaut. Une solution de contournement peut être de fournir l’adresse IP le cas échéant.

Le pont de ressources Azure Arc est inaccessible

Le pont de ressources Azure Arc exécute un cluster Kubernetes et son plan de contrôle nécessite une adresse IP statique. L’adresse IP est spécifiée dans le fichier infra.yaml. Si l’adresse IP est affectée à partir d’un serveur DHCP, l’adresse peut changer si elle n’est pas réservée. Le redémarrage du pont de ressources Azure Arc ou de la machine virtuelle peut déclencher une modification d’adresse IP, ce qui entraîne l’échec des services.

Le pont de ressources Arc peut perdre la configuration IP réservée. Cette perte est due au comportement décrit dans la section Perte des adresses IP virtuelles lorsque systemd-networkd est redémarré. Lorsque l’adresse IP n’est pas affectée à la machine virtuelle de pont de ressources Azure Arc, tout appel au serveur d’API de pont de ressources échoue. Les opérations principales, telles que la création d’une ressource, la connexion à votre cloud privé à partir d’Azure ou la création d’un emplacement personnalisé, ne fonctionnent pas comme prévu. Pour résoudre ce problème, redémarrez la machine virtuelle de pont de ressources et devez récupérer son adresse IP. Si l’adresse est affectée à partir d’un serveur DHCP, réservez l’adresse IP associée au pont de ressources.

Le pont de ressources Arc peut également être inaccessible en raison d’un accès au disque lent. Le pont de ressources Azure Arc utilise l’arborescence de configuration étendue Kubernetes (ETCD), ce qui nécessite une latence de 10 ms ou moins. Si le disque sous-jacent présente des performances faibles, les opérations sont affectées et des défaillances peuvent se produire.

Problèmes de configuration du proxy SSL

Assurez-vous que le serveur proxy sur votre ordinateur de gestion approuve à la fois le certificat SSL de votre proxy SSL et le certificat SSL des serveurs de téléchargement Microsoft. Pour plus d’informations, consultez Configuration du proxy SSL.

Aucun hôte de ce type – dp.kubernetesconfiguration.azure.com

Une erreur qui contient dial tcp: lookup westeurope.dp.kubernetesconfiguration.azure.com: no such host lors du déploiement d’un pont de ressources Arc signifie que le plan de données de configuration n’est pas actuellement disponible dans la région spécifiée. Le service peut être temporairement indisponible. Attendez que le service soit disponible, puis réessayez le déploiement.

proxyconnect tcp – Aucun hôte de ce type pour l’URL requise par le pont de ressources Arc

Une erreur contenant une URL requise par le pont de ressources Arc avec le message proxyconnect tcp: dial tcp: lookup http: no such host indique que DNS n’est pas en mesure de résoudre l’URL. L’erreur peut ressembler à l’exemple ci-dessous, où l’URL requise est https://msk8s.api.cdp.microsoft.com :

Error: { _errorCode_: _InvalidEntityError_, _errorResponse_: _{\n\_message\_: \_Post \\\_https://msk8s.api.cdp.microsoft.com/api/v1.1/contents/default/namespaces/default/names/arc-appliance-stable-catalogs-ext/versions/latest?action=select\\\_: POST https://msk8s.api.cdp.microsoft.com/api/v1.1/contents/default/namespaces/default/names/arc-appliance-stable-catalogs-ext/versions/latest?action=select giving up after 6 attempt(s): Post \\\_https://msk8s.api.cdp.microsoft.com/api/v1.1/contents/default/namespaces/default/names/arc-appliance-stable-catalogs-ext/versions/latest?action=select\\\_: proxyconnect tcp: dial tcp: lookup http: no such host\_\n}_ }

Cette erreur peut se produire si les paramètres DNS fournis pendant le déploiement ne sont pas corrects ou s’il y a un problème avec le ou les serveurs DNS. Vous pouvez vérifier si votre serveur DNS peut résoudre l’URL en exécutant la commande suivante à partir de la machine de gestion ou d’un ordinateur qui a accès au ou aux serveurs DNS :

nslookup
> set debug
> <hostname> <DNS server IP>

Pour résoudre l’erreur, votre ou vos serveurs DNS doivent être configurés pour résoudre toutes les URL requises par le pont de ressources Arc et le ou les serveurs DNS doivent être correctement fournis durant le déploiement du pont de ressources Arc.

Erreur de délai d’expiration de KVA

L’erreur de délai d’expiration du KVA est une erreur générique qui peut être le résultat d’une variété de configurations réseau dans lesquelles l’ordinateur de déploiement, la machine virtuelle de l’appliance ou l’adresse IP du plan de contrôle ne communiquent pas entre eux, avec Internet ou avec les URL requises. Cet échec de communication est souvent dû à des problèmes de résolution DNS, de paramètres de proxy, de configuration réseau ou d’accès à Internet.

Pour plus de clarté, une machine de gestion fait référence à l’ordinateur sur lequel les commandes CLI de déploiement sont exécutées. La machine virtuelle de l’appliance correspond à la machine virtuelle qui héberge le pont de ressources Arc. L’adresse IP du plan de contrôle correspond à l’adresse IP du plan de contrôle pour le cluster de gestion Kubernetes dans la machine virtuelle de l’appliance.

Principales causes de l’erreur de délai d’expiration du KVA

  • La machine de déploiement ne peut pas communiquer avec l’adresse IP du plan de contrôle et l’adresse IP de la machine virtuelle de l’appliance.
  • La machine virtuelle de l’appliance ne peut pas communiquer avec la machine de gestion, le point de terminaison vCenter (pour VMware) ou le point de terminaison de l’agent cloud MOC (pour Azure Stack HCI). 
  • La machine virtuelle de l’appliance n’a pas accès à Internet.
  • La machine virtuelle de l’appliance a accès à Internet, mais la connectivité à une ou plusieurs URL requises est bloquée, peut-être en raison d’un proxy ou d’un pare-feu.
  • La machine virtuelle de l’appliance ne peut pas atteindre un serveur DNS capable de résoudre les noms internes, comme le point de terminaison vCenter pour vSphere ou le point de terminaison de l’agent cloud pour Azure Stack HCI. Le serveur DNS doit également être en mesure de résoudre des adresses externes, telles que des adresses de service Azure et des noms de registre de conteneurs. 
  • La configuration du serveur proxy sur la machine de gestion ou les fichiers de configuration de pont de ressources Arc est incorrecte. Cela peut avoir un impact sur la machine de gestion et la machine virtuelle de l’appliance. Lorsque la commande az arcappliance prepare est exécutée, la machine de gestion ne pourra pas se connecter et télécharger des images de système d’exploitation si le proxy hôte n’est pas correctement configuré. L’accès à Internet sur la machine virtuelle de l’appliance peut être interrompu par une configuration de proxy incorrecte ou manquante, ce qui a un impact sur la capacité de la machine virtuelle à extraire des images conteneur. 

Dépannage de l’erreur de dépassement de temps KVA

Pour résoudre l’erreur, une ou plusieurs configurations réseau incorrectes peuvent être traitées. Suivez les étapes ci-dessous pour résoudre les raisons les plus courantes de cette erreur.

  1. En cas de problème de déploiement, la première étape consiste à collecter des journaux d’activité par adresse IP de machine virtuelle de l’appliance (non par kubeconfig, car le kubeconfig peut être vide si la commande de déploiement n’a pas été terminée). Les problèmes de collecte des journaux sont probablement dus à l’incapacité de l’ordinateur de gestion d’atteindre la machine virtuelle de l’appliance.

    Une fois les journaux collectés, extrayez le dossier et ouvrez kva.log. Passez en revue le fichier kva.log pour plus d’informations sur l’échec permettant de déterminer la cause de l’erreur de délai d’expiration du KVA.

  2. La machine de gestion doit être en mesure de communiquer avec l’adresse IP de la machine virtuelle de l’appliance et l’adresse IP du plan de contrôle. Effectuez un test ping sur l’adresse IP du plan de contrôle et l’adresse IP de la machine de gestion, et vérifiez que les deux adresses IP envoient une réponse.

    Si une demande expire, la machine de gestion ne peut pas communiquer avec les adresses IP. Cela peut être dû à un port fermé, à une configuration incorrecte du réseau ou à un bloc de pare-feu. Collaborez avec votre administrateur réseau pour permettre la communication entre l’ordinateur de gestion vers l’adresse IP du plan de contrôle et l’adresse IP de la machine virtuelle de l’appliance.

  3. L’adresse IP de machine virtuelle et l’adresse IP du plan de contrôle de l’appliance doivent être en mesure de communiquer avec la machine de gestion et le point de terminaison vCenter (pour VMware) ou le point de terminaison de l’agent cloud MOC (pour HCI). Collaborez avec votre administrateur réseau pour vous assurer que le réseau est configuré pour permettre cette opération. Cela peut nécessiter l’ajout d’une règle de pare-feu pour ouvrir le port 443 à partir de l’adresse IP de machine virtuelle de l’appliance et du plan de contrôle vers vCenter ou le port 65000 et 55000 pour l’agent cloud MOC Azure Stack HCI. Passez en revue la configuration réseau requise pour le pont de ressources Azure Stack HCI et VMware for Arc.

  4. L’adresse IP de la machine virtuelle et l’adresse IP du plan de contrôle de l’appliance ont besoin d’un accès Internet à ces URL requises. Azure Stack HCI nécessite des URL supplémentaires. Collaborez avec votre administrateur réseau pour vous assurer que les adresses IP peuvent accéder aux URL requises.

  5. Dans un environnement non proxy, l’ordinateur de gestion doit disposer d’une résolution DNS externe et interne. La machine de gestion doit être en mesure d’atteindre un serveur DNS capable de résoudre des noms internes tels que le point de terminaison vCenter pour vSphere ou le point de terminaison de l’agent cloud pour Azure Stack HCI. Le serveur DNS doit également être en mesure de résoudre les adresses externes, telles que les URL Azure et les URL de téléchargement d’images de système d’exploitation. Collaborez avec votre administrateur système pour vous assurer que l’ordinateur de gestion dispose d’une résolution DNS interne et externe. Dans un environnement proxy, la résolution DNS sur le serveur proxy doit résoudre les points de terminaison internes et les adresses externes requises.

    Pour tester la résolution DNS sur une adresse interne à partir de l’ordinateur de gestion dans un scénario non proxy, ouvrez l’invite de commandes et exécutez nslookup <vCenter endpoint or HCI MOC cloud agent IP>. Vous devez recevoir une réponse si la machine de gestion a une résolution DNS interne dans un scénario non proxy. 

  6. La machine virtuelle de l’appliance doit être en mesure d’atteindre un serveur DNS capable de résoudre des noms internes tels que le point de terminaison vCenter pour vSphere ou le point de terminaison de l’agent cloud pour Azure Stack HCI. Le serveur DNS doit également être en mesure de résoudre des adresses externes/internes, telles que des adresses de service Azure et des noms de registre de conteneurs pour le téléchargement des images conteneur du pont de ressources Arc à partir du cloud.

    Vérifiez que l’adresse IP du serveur DNS utilisée pour créer les fichiers de configuration a une résolution d’adresse interne et externe. Si ce n’est pas le cas, supprimez l’appliance, recréez les fichiers de configuration du pont de ressources Arc avec les paramètres de serveur DNS appropriés, puis déployez le pont de ressources Arc à l’aide des nouveaux fichiers de configuration.

Déplacer l’emplacement du pont de ressources Arc

Le déplacement des ressources du pont de ressources Arc n’est actuellement pas pris en charge. Vous devez supprimer le pont de ressources Arc, puis le redéployer à l’emplacement souhaité.

Problèmes liés aux machines virtuelles avec Azure Arc sur Azure Stack HCI

Pour obtenir de l’aide générale sur la résolution des problèmes liés aux machines virtuelles avec Azure Arc sur Azure Stack HCI, consultez Résoudre les problèmes liés aux machines virtuelles avec Azure Arc.

Échec de la négociation d’authentification

Lors de l’exécution d’une commande az arcappliance, une erreur de connexion peut s’afficher : authentication handshake failed: x509: certificate signed by unknown authority

Cela est généralement dû à la tentative d’exécution de commandes à partir de PowerShell distant, qui n’est pas pris en charge par le pont de ressources Azure Arc.

Pour installer un pont de ressources Azure Arc sur un cluster Azure Stack HCI, les commandes az arcappliance doivent être exécutées localement sur un nœud du cluster. Connectez-vous au nœud par le biais du protocole RDP (Remote Desktop Protocol) ou utilisez une session console pour exécuter ces commandes.

Problèmes sur VMware VCenter avec Azure Arc

errorCode: CreateConfigKvaCustomerError, errorResponse: erreur lors de l’obtention du client SDK vsphere

En ce qui concerne les erreurs présentant l’errorCode CreateConfigKvaCustomerError et l’errorResponse error getting the vsphere sdk client, elles se produisent lorsque votre machine de déploiement tente d’établir une connexion TCP à votre adresse vCenter, mais rencontre un problème. Vous recevez cet errorCode et errorResponse si votre adresse vCenter est incorrecte (erreur 403 ou 404) ou s’il existe une configuration réseau/proxy/pare-feu bloquante (échec de la tentative de connexion). Si vous entrez votre adresse vCenter en tant que nom d’hôte et recevez l’erreur no such host, votre ordinateur de déploiement n’est pas en mesure de résoudre le nom d’hôte vCenter via le DNS du client. Vous pouvez recevoir une erreur si la machine de déploiement est en mesure de résoudre le nom d’hôte vCenter, mais que la machine de déploiement ne peut pas atteindre l’adresse IP qu’elle a reçue du DNS. Vous pouvez recevoir une erreur si le point de terminaison retourné par DNS n’est pas votre adresse vCenter ou si le trafic a été intercepté par proxy. Enfin, vous pouvez obtenir une erreur si votre machine de déploiement est en mesure de communiquer avec votre adresse vCenter, mais que le nom d’utilisateur ou le mot de passe est incorrect.

Client du Kit de développement logiciel (SDK) vSphere – Échec de la tentative de connexion

Si vous recevez une erreur pendant le déploiement qui indique : errorCode_: _CreateConfigKvaCustomerError_, _errorResponse_: _error getting the vsphere sdk client: Post \_https://ip.address/sdk\_: dial tcp ip.address:443: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond._ }, votre machine de déploiement n’est pas en mesure de communiquer avec votre serveur vCenter. Assurez-vous que votre machine de déploiement répond aux exigences de machine de gestion et qu’il n’existe pas de communication bloquante par pare-feu ou proxy.

Client SDK vSphere – 403 Interdit ou 404 introuvable

Si vous recevez une erreur qui contient errorCode_: _CreateConfigKvaCustomerError_, _errorResponse_: _error getting the vsphere sdk client: POST \_/sdk\_: 403 Forbidden ou 404 not found lors du déploiement du pont de ressources Arc, vous avez probablement indiqué une adresse vCenter incorrecte lors de la création du fichier de configuration, où vous êtes invité à entrer l’adresse de vCenter sous la forme d’un nom d’hôte ou d’une adresse IP. Vous pouvez trouver l’adresse de vCenter de plusieurs manières. Une option consiste à accéder au client vSphere via son interface web. Le nom d’hôte ou l’adresse IP de vCenter est généralement ce que vous utilisez dans le navigateur pour accéder au client vSphere. Si vous êtes déjà connecté, vous pouvez consulter la barre d’adresse du navigateur. L’URL que vous utilisez pour accéder à vSphere est le nom d’hôte ou l’adresse IP de votre serveur vCenter. Vérifiez l’adresse de vCenter, puis réessayez le déploiement.

Client du Kit de développement logiciel (SDK) vSphere – aucun hôte de ce type

Si vous rencontrez l’erreur { _errorCode_: _CreateConfigKvaCustomerError_, _errorResponse_: _error getting the vsphere sdk client: Post \_https://your.vcenter.hostname/sdk\_: dial tcp: lookup your.vcenter.hostname: no such host_ } pendant le déploiement, la machine de déploiement ne peut pas résoudre le nom d’hôte vCenter en adresse IP. Ce problème se produit, car le processus de déploiement tente d’établir une connexion TCP à partir de votre machine de déploiement vers le nom d’hôte vCenter, mais échoue en raison de problèmes de résolution DNS. Pour résoudre ce problème, vérifiez que la configuration DNS sur votre machine de déploiement est correcte et que le serveur DNS est en ligne et recherchez une entrée DNS manquante pour le nom d’hôte vCenter. Vous pouvez tester la résolution DNS en exécutant nslookup your.vcenter.hostname ou ping your.vcenter.hostname à partir de la machine de déploiement. Si vous avez spécifié votre adresse vCenter en tant que nom d’hôte, envisagez d’utiliser directement l’adresse IP.

Erreurs de validation avant le déploiement

Si vous recevez diverses erreurs pre-deployment validation of your download\upload connectivity wasn't successful, par exemple :

Pre-deployment validation of your download/upload connectivity wasn't successful. {\\n \\\_code\\\_: \\\_ImageProvisionError\\\_,\\n \\\_message\\\_: \\\_Post \\\\\\\_https://vcenter-server.com/nfc/unique-identifier/disk-0.vmdk\\\\\\\_: Service Unavailable

Pre-deployment validation of your download/upload connectivity wasn't successful. {\\n \\\_code\\\_: \\\_ImageProvisionError\\\_,\\n \\\_message\\\_: \\\_Post \\\\\\\_https://vcenter-server.com/nfc/unique-identifier/disk-0.vmdk\\\\\\\_: dial tcp 172.16.60.10:443: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

Pre-deployment validation of your download/upload connectivity wasn't successful. {\\n \\\_code\\\_: \\\_ImageProvisionError\\\_,\\n \\\_message\\\_: \\\_Post \\\\\\\_https://vcenter-server.com/nfc/unique-identifier/disk-0.vmdk\\\\\\\_: use of closed network connection.

Pre-deployment validation of your download/upload connectivity wasn't successful. {\\n \\\_code\\\_: \\\_ImageProvisionError\\\_,\\n \\\_message\\\_: \\\_Post \\\\\\\_https://vcenter-server.com/nfc/unique-identifier/disk-0.vmdk\\\\\\\_: dial tcp: lookup hostname.domain: no such host

Une combinaison de ces erreurs indique généralement que la connexion entre la machine de gestion et le magasin de données a été perdue ou qu’un problème de mise en réseau rend le magasin de données inaccessible. Cette connexion est nécessaire pour charger l’OVA à partir de la machine de gestion utilisée pour générer la machine virtuelle de l’appliance dans vCenter. Rétablissez la connexion entre la machine de gestion et le magasin de données, puis réessayer le déploiement du pont de ressources Arc.

Le certificat x509 a expiré ou n’est pas encore valide

Lorsque vous déployez un pont de ressources Arc, vous pouvez rencontrer l’erreur suivante :

Error: { _errorCode_: _PostOperationsError_, _errorResponse_: _{\n\_message\_: \_{\\n \\\_code\\\_: \\\_GuestInternetConnectivityError\\\_,\\n \\\_message\\\_: \\\_Not able to connect to https://msk8s.api.cdp.microsoft.com. Error returned: action failed after 3 attempts: Get \\\\\\\_https://msk8s.api.cdp.microsoft.com\\\\\\\_: x509: certificate has expired or isn't yet valid: current time 2022-01-18T11:35:56Z is before 2023-09-07T19:13:21Z. Arc Resource Bridge network and internet connectivity validation failed: http-connectivity-test-arc. 1. Please check your networking setup and ensure the URLs mentioned in : https://aka.ms/AAla73m are reachable from the Appliance VM. 2. Check firewall/proxy settings

Cette erreur est due au fait qu’il existe une différence d’horloge/heure entre le ou les hôtes ESXi et la machine de gestion où les commandes de déploiement pour le pont de ressources Arc sont exécutées. Pour résoudre ce problème, activez la synchronisation de temps NTP sur le ou les hôtes ESXi, vérifiez que la machine de gestion est également synchronisée avec NTP, puis réessayez le déploiement.

L’état du pont de ressources Arc est déconnecté

Lors de l’exécution du script d’intégration VMware avec Arc initial, vous êtes invité à fournir un compte vSphere. Ce compte est stocké localement dans le pont de ressources Arc en tant que secret Kubernetes chiffré. Le compte est utilisé pour permettre au pont de ressources Arc d’interagir avec vCenter. Si l’état de votre pont de ressources Arc est déconnecté, cela peut être dû au compte vSphere stocké localement dans le pont de ressources qui va expirer. Vous devez mettre à jour les informations d’identification dans le pont de ressources Arc et pour VMware avec Arc en suivant les instructions de mise à jour des informations d’identification du compte vSphere.

Erreur lors de la configuration de l’hôte

Si vous avez utilisé le même modèle pour déployer et supprimer le pont de ressources Arc plusieurs fois, vous pouvez rencontrer l’erreur suivante :

Appliance cluster deployment failed with error: Error: An error occurred during host configuration

Pour résoudre ce problème, supprimez le modèle existant manuellement. Exécutez ensuite az arcappliance prepare pour télécharger un nouveau modèle pour le déploiement.

Impossible de trouver des dossiers

Lors du déploiement du pont de ressources Arc sur VMware, vous spécifiez le dossier dans lequel le modèle et la machine virtuelle sont créés. Le dossier sélectionné doit être un type de dossier de machine virtuelle et de modèle. Vous ne pouvez pas utiliser d’autres types de dossiers, comme des dossiers de stockage, des dossiers réseau ou des dossiers hôtes et de cluster, pour le déploiement du pont de ressources.

Autorisations insuffisantes

Lorsque vous déployez le pont de ressources sur VMware vCenter, vous risquez d’obtenir une erreur indiquant que vous disposez d’une autorisation insuffisante. Pour résoudre ce problème, assurez-vous que le compte d’utilisateur utilisé pour déployer le pont de ressources dispose de tous les privilèges suivants dans VMware vCenter, puis réessayez.

Magasins de données 

  • Allouer de l’espace
  • Parcourir les magasins de données
  • Opérations de fichier de bas niveau

Dossier 

  • Créer un dossier

Catégorisation vSphere

  • Attribuer ou annuler l’attribution d’une balise vSphere

Réseau 

  • Attribuer un réseau

Ressource

  • Assign virtual machine to resource pool
  • Migrer une machine virtuelle hors tension
  • Migrer une machine virtuelle sous tension

Sessions

  • Valider la session

vApp

  • Attribuer une liste de ressources partagées
  • Importez

Machine virtuelle

  • Changer la configuration
    • Acquérir le bail du disque
    • Ajouter un disque existant
    • Ajouter un nouveau disque
    • Ajouter ou supprimer un appareil
    • Configuration avancée
    • Modifier le nombre d’UC
    • Modifier la mémoire
    • Modifier les paramètres
    • Modifier la ressource
    • Configurer managedBy
    • Afficher les paramètres de connexion
    • Étendre l’unité virtuelle
    • Modification des paramètres de l’appareil
    • Interroger la compatibilité de la tolérance de pannes
    • Interroger les fichiers sans propriétaire
    • Recharger à partir du chemin d’accès
    • Supprimer le disque
    • Renommer
    • Réinitialiser les informations de l’invité
    • Définir l’annotation
    • Activer/désactiver le suivi des modifications du disque
    • Basculer le parent fourche
    • Mettre à niveau la compatibilité de la machine virtuelle
  • Modifier l’inventaire
    • Créer à partir de ce qui existe
    • Création
    • Inscrire
    • Remove
    • Unregister
  • Opérations de l’invité
    • Modification des alias d’opération invité
    • Modification d’opération invité
    • Exécution du programme d’opération invité
    • Requêtes d’opération invité
  • Interaction
    • Connecter des appareils
    • Interaction de la console
    • Gestion du système d’exploitation invité par API VIX
    • Installer VMware Tools
    • Mise hors tension
    • Mise sous tension
    • Réinitialiser
    • Interrompre
  • Approvisionnement
    • Autoriser l’accès au disque
    • Autoriser l’accès au fichier
    • Autoriser l’accès au disque en lecture seule
    • Autoriser le téléchargement de machines virtuelles
    • Autoriser le téléchargement de machines virtuelles
    • Cloner la machine virtuelle
    • Déployer un modèle
    • Marquer comme modèle
    • Marquer come machine virtuelle
    • Personnaliser l’invité
  • Gestion des instantanés
    • Créer une capture instantanée
    • Supprimer l’instantané
    • Restaurer l’instantané

Étapes suivantes

Comprendre les opérations de récupération pour le pont de ressources dans les scénarios de sinistre VMware vSphere avec Azure Arc

Si votre problème ne figure pas ici ou que vous ne pouvez pas le résoudre, utilisez l’un des canaux suivants pour obtenir de l’aide :

  • Obtenez des réponses d'experts Azure par le biais de Microsoft Q&A.
  • Connectez-vous à @AzureSupport, le compte Microsoft Azure officiel pour améliorer l’expérience client. Le Support Azure fournit à la communauté Azure des réponses, un support technique et des experts.
  • Ouvrez une demande de support Azure.