Partager 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>

Afin de collecter des journaux de pont de ressources Arc pour Azure Local, consultez Collecter les journaux.

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 l’image VM du pont de ressources Arc, ce qui entraîne cette erreur : 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.

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. De cette façon, vous devez obtenir un chargement plus rapide de l’image dans le magasin de données.

Le contexte a expiré pendant la phase ApplyingKvaImageOperator

Quand vous déployez un pont de ressources Arc, vous pouvez voir cette erreur : Deployment of the Arc resource bridge appliance VM timed out. 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.

Vérifiez 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 la connectivité et la vitesse de votre réseau sont stables, et que vous recevez toujours cette erreur, attendez au moins 30 minutes avant de réessayer, car il se peut que Microsoft Container Registry reçoive un volume élevé de trafic.

Le contexte a expiré pendant la phase WaitingForAPIServer

Quand vous déployez un pont de ressources Arc, vous pouvez voir cette erreur : Deployment of the Arc resource bridge appliance VM timed out. 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 la machine de déploiement ne peut pas contacter l’IP de plan de contrôle du 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. Si le trafic est proxysé, configurez les paramètres du proxy sur votre réseau ou votre machine de déploiement pour ne pas proxyser le trafic entre la machine de déploiement vers l’IP de plan de contrôle et les IP VM de l’appliance. 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.

403 Forbidden (Interdit) ou 404 Site Not Found (Site introuvable)

Quand vous déployez un pont de ressources Arc, vous pouvez voir cette erreur : { _errorCode_: _UploadError_, _errorResponse_: _{\n\_message\_: \_Pre-deployment validation of your download/upload connectivity was not successful. {\\n \\\_code\\\_: \\\_ImageProvisionError\\\_,\\n \\\_message\\\_: \\\_403 Forbidden ou { _errorCode_: _UploadError_, _errorResponse_: _{\n\_message\_: \_Pre-deployment validation of your download/upload connectivity was not successful. {\\n \\\_code\\\_: \\\_ImageProvisionError\\\_,\\n \\\_message\\\_: \\\_404 Site Not Found

Cette erreur se produit quand les images doivent être téléchargées à partir de registres Microsoft sur la machine de déploiement, et qu’un proxy ou un pare-feu bloque le téléchargement. Passez en revue la Configuration requise pour le réseau et vérifiez que toutes les URL nécessaires sont accessibles. Vous allez peut-être devoir mettre à jour vos paramètres de proxy pour vous assurer que le trafic de votre ordinateur de déploiement vers les URL requises par Microsoft ne passe pas par un proxy.

Accès au dossier SSH refusé

L’interface CLI nécessite l’autorisation d’accéder au dossier SSH pendant le déploiement ou les opérations impliquant l’accès aux fichiers dans le dossier. Ce dossier contient des fichiers essentiels tels que le kubeconfig et la clé des journaux pour la machine virtuelle de l’appliance. Par exemple, l’interface CLI doit accéder à la clé des journaux stockée dans le dossier SSH pour collecter les journaux à partir de la machine virtuelle de l’appliance.

Vous pouvez voir cette erreur : Access to the file in the SSH folder was denied. This may occur if the CLI doesn't have permission to the SSH folder or if another CLI instance is using the file. Deux causes courantes peuvent être à l’origine de ce problème :

  • Autorisations insuffisantes : l’interface CLI ne dispose pas des autorisations nécessaires pour accéder au dossier SSH. Vérifiez que le compte d’utilisateur exécutant l’interface CLI dispose des autorisations appropriées pour accéder au dossier SSH.
  • Accès simultané aux fichiers : une autre instance de l’interface CLI peut utiliser le fichier dans le dossier SSH. Cela se produit souvent sur les stations de travail avec des profils partagés. Vérifiez que toute autre instance CLI termine ou met fin à son opération avant de continuer.

Le pont de ressources Arc est hors connexion

Des changements de réseau dans l’infrastructure, l’environnement ou le cluster peuvent empêcher la machine virtuelle de l’appliance 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 des commandes CLI az arcappliance pour le pont de ressources Arc via PowerShell à distance, vous pouvez voir une erreur d’échec de négociation de l’authentification quand vous essayez d’installer le pont de ressources sur une instance locale Azure 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 Arc, vous devez le supprimer et le redéployer.

Par exemple, si vous spécifiez le mauvais emplacement ou abonnement pendant le déploiement, la création de la ressource échoue. Si vous tentez seulement de recréer la ressource sans redéployer la machine virtuelle du pont de ressources, l’état se bloque sur 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 des problèmes de réseau, vous pouvez voir une erreur Appliance Network Unavailable. 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 Error while dialing dial tcp xx.xx.xxx.xx:55000: connect: no route to host. 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. Avec Azure Local, cette erreur peut se produire quand le stockage hôte est plein.

Erreur d’actualisation du jeton

Quand vous exécutez des commandes Azure CLI, vous pouvez voir l’erreur suivante : The refresh token has expired or is invalid due to sign-in frequency checks by conditional access.

L’erreur se produit car, quand 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

Quand vous utilisez la commande az arcappliance createconfig ou az arcappliance run, une expérience interactive affiche la liste des entités VMware que vous pouvez sélectionner pour 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.

L’état du pont de ressources est Hors connexion, et l’état d’approvisionnement est Échec

Quand vous déployez le pont de ressources Arc, le pont peut sembler correctement déployé, car aucune erreur n’a été rencontrée pendant l’exécution de az arcappliance deploy ou az arcappliance create. Toutefois, quand vous consultez le pont dans le portail Azure, vous pouvez voir l’état Offline, et az arcappliance show peut montrer le provisioningState Failed. Ce problème se produit quand les fournisseurs nécessaires ne sont pas inscrits avant le déploiement du pont.

Pour Azure Local, version 23H2 et ultérieures, le pont de ressources Arc est automatiquement déployé en même temps que le cluster et l’installation manuelle n’est plus nécessaire.

Si votre pont de ressources Arc est hors connexion, essayez de redémarrer la machine virtuelle du pont de ressources Arc. Si le problème persiste, contactez le support technique Microsoft.

Remarque

La réinstallation du pont de ressources Arc sur Azure Local peut entraîner des problèmes avec vos ressources Azure existantes.

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 plus d’informations sur ces fournisseurs supplémentaires, 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. Les appels provenant de la machine virtuelle de l’appliance ne doivent pas passer par votre configuration de liaison privée. Les IP Private Link peuvent être en conflit avec la plage du pool d’adresses IP de l’appliance, qui n’est pas configurable 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.

Machine de gestion incapable d’atteindre l’appliance

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

{ _errorCode_: _PostOperationsError_, _errorResponse_: _{\n\_message\_: \_Timeout occurred due to management machine being unable to reach the appliance VM IP, 10.2.196.170. Ensure that the requirements are met: https://aka.ms/arb-machine-reqs: dial tcp 10.2.196.170:22: 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.\_\n}_, _errorMetadata_: { _errorCategory_: __ }

Cette erreur se produit quand la machine de gestion ne peut pas accéder à l’IP VM du pont de ressources Arc par SSH (port 22) ou par le serveur d’API (port 6443). Elle peut également se produire si le serveur d’API du pont de ressources Arc est proxysé, dans ce cas le serveur d’API du pont de ressources Arc doit être ajouté aux paramètres noproxy. Pour plus d’informations, consultez configuration réseau requise pour le pont des ressources Azure Arc.

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.

Connexion impossible - échec de validation de la connectivité réseau et Internet

Quand vous déployez le pont de ressources Arc, vous pouvez recevoir une erreur avec l’errorCode PostOperationsError, l’errorResponse GuestInternetConnectivityError et une URL spécifiant le port 53 (DNS). Cette erreur peut être liée aux IP VM de l’appliance qui ne parviennent pas à accéder aux serveurs DNS, et par conséquent ne peuvent pas résoudre le point de terminaison spécifié dans l’erreur.

Exemples d’erreurs :

{ _errorCode_: _PostOperationsError_, _errorResponse_: _{\n\_message\_: \_{\\n  \\\_code\\\_:\\\_GuestInternetConnectivityError\\\_,\\n\\\_message\\\_:\\\_Not able to connect to http://aszhcitest01.company.org:55000. Error returned: action failed after 5 attempts: Get \\\\\\\_http://aszhcitest01.company.org:55000\\\\\\\_: dial tcp: lookup aszhcitest01.company.org on 127.0.0.53:53: read udp 127.0.0.1:32975-\\u003e127.0.0.53:53: i/o timeout. Arc Resource Bridge network and internet connectivity validation failed: cloud-agent-connectivity-test. 1. 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\\\_\\n }\_\n}_ }

{ _errorCode_: _PostOperationsError_, _errorResponse_: _{\n\_message\_: \_{\\n  \\\_code\\\_: \\\_GuestInternetConnectivityError\\\_,\\n  \\\_message\\\_: \\\_Not able to connect to https://linuxgeneva-microsoft.azurecr.io. Error returned: action failed after 5 attempts: Get \\\\\\\_https://linuxgeneva-microsoft.azurecr.io\\\\\\\_: dial tcp: lookup linuxgeneva-microsoft.azurecr.io on 127.0.0.53:53: server misbehaving. 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\\\_\\n }\_\n}_ }

Pour résoudre ces erreurs, collaborez avec votre administrateur réseau pour autoriser les IP VM de l’appliance à accéder aux serveurs DNS. Pour plus d’informations, consultez configuration réseau requise pour le pont des ressources Azure Arc.

Le serveur Http2 a envoyé GOAWAY

Quand vous tentez de déployer un pont de ressources Arc, vous pouvez recevoir des messages d’erreur similaires à ceux présentés ci-dessous :

"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}"

or

Post \_https://canadacentral.dp.kubernetesconfiguration.azure.com/azure-arc-appliance-k8sagents/GetLatestHelmPackagePath?api-version=2019-11-01-preview\u0026releaseTrain=stable\_: read tcp 10.128.131.173:52425-\u003e52.228.84.81:443: wsarecv: An existing connection was forcibly closed by the remote host.

Ces erreurs peuvent se produire quand l’inspection SSL/TLS est activée pour un pare-feu ou un proxy, et que cela bloque les appels http2 depuis la machine utilisée pour déployer le pont de ressources. Pour vérifier 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 api-version (par exemple, 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.

Hôte non existant - .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"

Cette erreur se produit quand un chemin .local est fourni pour un paramètre de configuration, comme un proxy, dns, magasin de données ou point de terminaison de gestion (par ex., 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), qui nécessite une latence de 10 ms ou moins. Si le disque sous-jacent a des performances lentes, les opérations sont impacté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 pendant le 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 demandée par le pont de ressources Arc avec le message proxyconnect tcp: dial tcp: lookup http: no such host indique que le DNS n’est pas en mesure de résoudre l’URL. L’erreur peut ressembler à cet exemple, où l’URL demandée 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 qu’il y a un problème avec 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’une machine ayant accès aux serveurs DNS :

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

Pour résoudre l’erreur, configurez vos serveurs DNS pour qu’ils résolvent toutes les URL demandées par le pont de ressources Arc. Les serveurs DNS doivent être correctement fournis quand vous déployez le pont de ressources Arc.

Erreur de délai d’expiration de KVA

L’erreur d’expiration du KVA est une erreur générique pouvant être provoquée par diverses configurations réseau incorrectes impliquant la machine de déploiement. Par exemple, l’IP VM de l’appliance ou l’IP du plan de contrôle peuvent ne pas communiquer pas entre elles, avec Internet ou avec les URL demandées. Ces échecs de communication sont souvent dus à des problèmes de résolution DNS, de paramètres 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 Local). 
  • 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 Local. 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. Quand la commande az arcappliance prepare est exécutée et que le proxy hôte n’est pas configuré correctement, la machine de gestion ne peut pas se connecter et télécharger des images de système d’exploitation. L’accès à Internet sur la machine virtuelle de l’appliance peut être interrompu par une configuration proxy incorrecte ou manquante, ce qui impacte la capacité de la machine virtuelle à tirer 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.

  • La première étape consiste à collecter les journaux d’activité par IP VM de l’appliance (non par kubeconfig, car le kubeconfig peut être vide si la commande de déploiement ne s’est pas 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 journal pour obtenir des informations permettant de déterminer la cause de l’erreur d’expiration du KVA.

  • 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’IP du plan de contrôle et l’IP VM de l’appliance à partir de la machine de gestion, et vérifiez que les deux IP envoient une réponse.

    Si une demande expire, la machine de gestion ne peut pas communiquer avec les IP. Ce problème peut être lié à un port fermé, une configuration incorrecte du réseau ou à un blocage 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.

  • L’IP VM de l’appliance et l’IP du plan de contrôle doivent pouvoir 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 Azure Local). Collaborez avec votre administrateur réseau pour vérifier que le réseau est configuré de sorte à permettre cette communication. Vous pouvez avoir besoin d’ajouter une règle de pare-feu pour ouvrir le port 443 à partir de l’IP VM de l’appliance et de l’IP du plan de contrôle vers vCenter, ou pour ouvrir les ports 65000 et 55000 pour l’agent cloud MOC Azure Local. Passez en revue la configuration réseau requise pour le pont de ressources Azure Local et VMware for Arc.

  • 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 Local 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.

  • 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 Local. 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 la machine de gestion dans un scénario sans 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. 

  1. La machine virtuelle de l’appliance doit pouvoir accéder à 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 Local. 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. À la place, supprimez le pont de ressources Arc et redéployez-le à l’emplacement souhaité.

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

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 Local, consultez Résoudre les problèmes de gestion des machines virtuelles Azure Arc pour Azure Local.

Si vous exécutez Azure Local, version 23H2 ou ultérieure, et que votre pont de ressources Arc est hors connexion, n’essayez pas de réinstaller ou de supprimer le pont de ressources Arc. À la place, essayez de redémarrer la machine virtuelle du pont de ressources Arc pour la remettre en ligne. Si le problème persiste, contactez le Support Microsoft pour obtenir de l’aide.

Échec de l’action - aucun hôte de ce type

Quand vous déployez le pont de ressources Arc, si vous recevez une erreur avec l’errorCode PostOperationsError, l’errorResponse GuestInternetConnectivityError et no such host, les IP VM de l’appliance ne peuvent peut-être pas accéder au point de terminaison spécifié dans l’erreur.

Exemple d’erreur :

{ _errorCode_: _PostOperationsError_, _errorResponse_: _{\n\_message\_: \_{\\n  \\\_code\\\_: \\\_GuestInternetConnectivityError\\\_,\\n  \\\_message\\\_: \\\_Not able to connect to http://aszhcitest01.company.org:55000. Error returned: action failed after 5 attempts: Get \\\\\\\_http://aszhcitest01.company.org:55000\\\\\\\_: dial tcp: lookup aszhcitest01.company.org: on 127.0.0.53:53: no such host. Arc Resource Bridge network and internet connectivity validation failed: cloud-agent-connectivity-test. 1. 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

Dans l’exemple, les IP VM de l’appliance ne peuvent pas accéder à http://aszhcitest01.company.org:55000, qui est le point de terminaison MOC. Collaborez avec votre administrateur réseau pour vous assurer que le serveur DNS peut de résoudre les URL requises.

Pour tester la connectivité au serveur DNS :

ping <dns-server.com>

Pour vérifier si le serveur DNS peut résoudre une adresse, exécutez cette commande à partir d’une machine capable d’accéder aux serveurs DNS :

Resolve-DnsName -Name "http://aszhcitest01.company.org:55000" -Server "<dns-server.com>"

Problèmes sur VMware VCenter avec Azure Arc

errorResponse: error getting the vsphere sdk client

Les erreurs avec l’errorCode: CreateConfigKvaCustomerError et l’errorResponse: error getting the vsphere sdk client se produisent quand votre machine de déploiement tente d’établir une connexion TCP sur votre adresse vCenter, mais rencontre un problème. Cela peut se produire si votre adresse vCenter est incorrecte (erreur 403 ou 404) ou si une configuration de réseau/proxy/pare-feu la bloque (é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. Cela peut se produire si la machine de déploiement peut résoudre le nom d’hôte vCenter, mais qu’elle ne peut pas accéder à l’adresse IP qu’elle a reçue du DNS. Vous pouvez également voir cette erreur si le point de terminaison renvoyé par le DNS n’est pas votre adresse vCenter ou si le trafic a été intercepté par un proxy. Si votre machine de déploiement peut communiquer avec votre adresse vCenter, vérifiez que votre nom d’utilisateur et votre mot de passe sont corrects.

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

Si vous recevez une erreur pendant le déploiement indiquant : 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 gestion ne peut pas communiquer avec votre serveur vCenter.

Pour résoudre ce problème, vérifiez que votre machine de gestion répond aux exigences de machine de gestion, et qu’aucun pare-feu ou proxy ne bloque la communication.

Client SDK vSphere – 403 Interdit ou 404 introuvable

Les erreurs qui contiennent errorCode_: _CreateConfigKvaCustomerError_, _errorResponse_: _error getting the vsphere sdk client: POST \_/sdk\_: 403 Forbidden ou 404 not found pendant le déploiement du pont de ressources Arc sont probablement dues à une adresse vCenter incorrecte. Cette adresse est fournie pendant la création du fichier de configuration, quand vous êtes invité à entrer l’adresse vCenter sous forme de nom d’hôte ou d’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, où 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 votre adresse vCenter, puis réessayez le déploiement.

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

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_ } peut se produire pendant le déploiement quand 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 la connexion échoue en raison de problèmes de résolution DNS.

Pour résoudre cette erreur, vérifiez que la configuration DNS sur votre machine de déploiement est correcte et que le serveur DNS est en ligne, et vérifiez qu’il ne manque pas d’entrée DNS 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 sous forme de nom d’hôte, utilisez plutôt l’adresse IP directement.

Erreurs de validation avant le déploiement

Quand vous déployez un pont de ressources Arc, vous pouvez voir diverses erreurs pre-deployment validation of your download\upload connectivity wasn't successful, de type :

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 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.

Pour corriger le problème, 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. 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 se produit quand il existe une différence d’horloge/heure entre les hôtes ESXi et la machine de gestion qui exécute les commandes de déploiement pour le pont de ressources Arc. Pour résoudre ce problème, activez la synchronisation d’heure NTP sur les hôtes ESXi, vérifiez que la machine de gestion est également synchronisée avec NTP, puis réessayez le déploiement.

Résout sur plusieurs réseaux

Quand vous déployez ou mettez à niveau le pont de ressources Arc, vous pouvez rencontrer une erreur similaire à :

{ "ErrorCode": "PreflightcheckErrorOnPrem", "ErrorDetails": "Upgrade Operation Failed with error: \"{\\n \\\"code\\\": \\\"PreflightcheckError\\\",\\n \\\"message\\\": \\\"{\\\\n \\\\\\\"code\\\\\\\": \\\\\\\"InvalidEntityError\\\\\\\",\\\\n \\\\\\\"message\\\\\\\": \\\\\\\"Cannot retrieve vSphere Network 'vmware-azure-arc-01': path 'vmware-azure-arc-01' resolves to multiple networks\\\\\\\",\\\\n \\\\\\\"category\\\\\\\": \\\\\\\"\\\\\\\"\\\\n }\\\",\\n \\\"category\\\": \\\"\\\"\\n }\"" }

Cette erreur se produit quand le segment réseau vSphere se résout en plusieurs réseaux, car plusieurs segments réseau vSphere utilisent le même nom que celui spécifié dans l’erreur. Pour corriger cette erreur, changez le nom réseau en double dans vCenter (pas le réseau avec la machine virtuelle d’appliance) ou déployez le pont de ressources Arc sur un autre réseau.

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

Quand vous exécutez le script initial d’intégration VMware avec Arc, 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 le compte vSphere stocké localement dans le pont de ressources expire, l’état de votre pont de ressources Arc est déconnecté. Mettez à jour les informations d’identification dans le pont de ressources Arc et celles de 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 utilisez 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

Quand vous déployez le 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.

Impossible de récupérer la ressource - introuvable ou inexistante

Quand vous déployez le pont de ressources Arc, vous spécifiez où déployer la machine virtuelle de l’appliance. La machine virtuelle de l’appliance ne peut pas être déplacée à partir de ce chemin d’accès d’emplacement. Si la machine virtuelle de l’appliance change d’emplacement et que vous essayez de faire une mise à niveau, vous pouvez rencontrer des erreurs de ce type :

{\n \"code\": \"PreflightcheckError\",\n \"message\": \"{\\n \\\"code\\\": \\\"InvalidEntityError\\\",\\n \\\"message\\\": \\\"Cannot retrieve <resource> 'resource-name': <resource> 'resource-name' not found\\\"\\n }\"\n }"

{\n \"code\": \"PreflightcheckError\",\n \"message\": \"{\\n \\\"code\\\": \\\"InvalidEntityError\\\",\\n \\\"message\\\": \\\"The specified vSphere Datacenter '/VxRail-Datacenter' does not exist\\\"\\n }\"\n }"

Pour résoudre ces erreurs, utilisez une de ces options :

  • Replacer la machine virtuelle d’appliance à son emplacement d’origine et vérifier que les informations d’identification RBAC sont mises à jour pour le changement d’emplacement.
  • Créez une ressource du même nom, puis déplacez le pont de ressource Arc vers cette nouvelle ressource.
  • Pour VMware avec Arc, exécutez le script de récupération d’urgence VMware avec Arc. Le script supprime l’appliance, déploie une nouvelle appliance et reconnecte l’appliance avec l’emplacement personnalisé, l’extension de cluster et les machines virtuelles avec Arc précédemment déployés.
  • Supprimez et redéployez le pont de ressources Arc.

Privilèges insuffisants

Quand vous déployez ou mettez à niveau le pont de ressources sur VMware vCenter, vous pouvez voir une erreur semblable à celle-ci :

{ ""code"": ""PreflightcheckError"", ""message"": ""{\n \""code\"": \""InsufficientPrivilegesError\"",\n \""message\"": \""The provided vCenter account is missing required vSphere privileges on the resource 'root folder (MoRefId: Folder:group-d1)'. Missing privileges: [Sessions.ValidateSession]. add the privileges to the vCenter account and try again. To review the full list of required privileges, go to https://aka.ms/ARB-vsphere-privilege.\""\n }

Quand vous déployez le pont de ressources Arc, vous fournissez les informations d’identification vCenter. Le pont de ressources Arc stocke localement ces informations d’identification vCenter pour interagir avec vCenter. Pour résoudre le problème de privilèges manquants, le compte vCenter utilisé par le pont de ressources a besoin des privilèges suivants dans VMware vCenter :

Banque 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

Marquage 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
  • Importer

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.