Share via

Solucionar problemas da ponte de recursos do Azure Arc

  • Artigo

Este artigo fornece informações sobre como solucionar e solucionar problemas que podem ocorrer ao tentar implantar, usar ou remover a ponte de recursos do Azure Arc. A ponte de recursos é uma máquina virtual empacotada, que hospeda um cluster Kubernetes de gerenciamento . Para obter informações gerais, consulte Visão geral da ponte de recursos do Azure Arc.

Problemas gerais

Recolha de registos

Para problemas encontrados com a ponte de recursos do Arc, colete logs para investigação adicional usando o comando da CLI az arcappliance logs do Azure. Esse comando precisa ser executado a partir da mesma máquina de gerenciamento que foi usada para executar comandos para implantar a ponte de recursos Arc. Se você estiver usando uma máquina diferente para coletar logs, precisará executar o az arcappliance get-credentials comando primeiro antes de coletar logs.

Se houver um problema ao coletar logs, provavelmente a máquina de gerenciamento não consegue acessar a VM do Appliance. Entre em contato com o administrador da rede para permitir a comunicação SSH da máquina de gerenciamento para a VM do dispositivo na porta TCP 22.

Você pode coletar os logs da ponte de recursos do Arc passando o IP da VM do dispositivo ou o kubeconfig no comando logs.

Para coletar logs de ponte de recursos do Arc no VMware usando o endereço IP da VM do dispositivo:

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

Para coletar logs de ponte de recursos do Arc para o Azure Stack HCI usando o endereço IP da VM do dispositivo:

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

Se você não tiver certeza do IP da VM do seu dispositivo, também há a opção de usar o kubeconfig. Você pode recuperar o kubeconfig executando o comando get-credentials e, em seguida, executar o comando logs.

Para recuperar o kubeconfig e a chave de log, colete logs para o VMware habilitado para Arc de uma máquina diferente da usada para implantar a ponte de recursos do Arc para VMware habilitado para 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>

A ponte de recursos do Arc está offline

Se a ponte de recursos estiver offline, isso normalmente se deve a uma alteração de rede na infraestrutura, no ambiente ou no cluster que impede que a VM do dispositivo possa se comunicar com seu recurso equivalente do Azure. Se não conseguir determinar o que mudou, você pode reiniciar a VM do dispositivo, coletar logs e enviar um tíquete de suporte para investigação adicional.

O PowerShell remoto não é suportado

Se você executar az arcappliance comandos da CLI para o Arc Resource Bridge por meio do PowerShell remoto, poderá ter vários problemas. Por exemplo, você pode ver um erro de falha de handshake de autenticação ao tentar instalar a ponte de recursos em um cluster HCI do Azure Stack ou outro tipo de erro. Atualmente, não há suporte para o uso az arcappliance de comandos do PowerShell remoto. Em vez disso, inicie sessão no nó através do protocolo RDP (Remote Desktop Protocol) ou utilize uma sessão de consola.

As configurações da ponte de recursos não podem ser atualizadas

Nesta versão, todos os parâmetros são especificados no momento da criação. Para atualizar a ponte de recursos do Azure Arc, você deve excluí-la e reimplantá-la novamente. Por exemplo, se você especificou o local errado ou a assinatura durante a implantação, mais tarde a criação do recurso falhará. Se você tentar apenas recriar o recurso sem reimplantar a VM da ponte de recursos, verá o status bloqueado em WaitForHeartBeat. Para resolver esse problema, exclua o appliance e atualize o arquivo YAML do appliance. Em seguida, reimplante e crie a ponte de recursos.

Rede de dispositivos indisponível

Se a ponte de recursos Arc estiver enfrentando um problema de rede, você poderá ver um erro "Rede do dispositivo indisponível". Em geral, qualquer problema de conectividade de rede ou infraestrutura com a VM do dispositivo pode causar esse erro. Este erro também pode aparecer como "Erro ao discar tcp xx.xx.xxx.xx:55000: connect: no route to host". O problema pode ser que a comunicação do host para a VM da ponte de recursos Arc precisa ser aberta pela porta TCP 22 com a ajuda do administrador da rede. Pode ser que tenha havido um problema de rede temporário não permitindo que o host alcance a VM da ponte de recursos Arc e, uma vez que o problema de rede seja resolvido, você pode tentar novamente a operação. Você também pode verificar se a ponte de recursos da VM do dispositivo para Arc não está parada ou offline. No caso do Azure Stack HCI, o armazenamento do host pode estar cheio e o armazenamento precisa ser resolvido.

Erro de atualização do token

Quando você executa os comandos da CLI do Azure, o seguinte erro pode ser retornado: O token de atualização expirou ou é inválido devido a verificações de frequência de entrada por acesso condicional. O erro ocorre porque quando você entra no Azure, o token tem um tempo de vida máximo. Quando esse tempo de vida for excedido, você precisará entrar no Azure novamente usando o az login comando.

Os pools de recursos de host padrão não estão disponíveis para implantação

Ao usar o az arcappliance createconfig comando or az arcappliance run , haverá uma experiência interativa que mostra a lista de entidades VMware onde você pode selecionar para implantar o dispositivo virtual. Essa lista mostrará todos os pools de recursos criados pelo usuário juntamente com os pools de recursos de cluster padrão, mas os pools de recursos de host padrão não estão listados. Quando o dispositivo é implantado em um pool de recursos de host, não há alta disponibilidade se o hardware do host falhar. Por isso, recomendamos que você não tente implantar o dispositivo em um pool de recursos de host.

Status da ponte de recursos "Offline" e provisioningState "Falha"

Ao implantar a ponte de recursos Arc, a ponte pode parecer ter sido implantada com êxito, porque nenhum erro foi encontrado durante a execução az arcappliance deploy ou az arcappliance create. No entanto, ao exibir a ponte no portal do Azure, você pode ver o status mostra como Offline e az arcappliance show pode mostrar o provisioningState como Falha. Isso acontece quando os provedores necessários não são registrados antes que a ponte seja implantada.

Para resolver esse problema, exclua a ponte de recurso, registre os provedores e, em seguida, reimplante a ponte de recurso.

  1. Exclua a ponte de recursos:

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

  2. Registe os fornecedores:

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

  3. Reimplante a ponte de recursos.

Nota

Os produtos de parceiros (como o VMware vSphere habilitado para Arc) podem ter seus próprios provedores necessários para se registrar. Para ver fornecedores adicionais que devem ser registrados, consulte a documentação do produto.

Credenciais expiradas na VM do dispositivo

A ponte de recursos do Arc consiste em uma VM de dispositivo que é implantada na infraestrutura local. A VM do dispositivo mantém uma conexão com o ponto de extremidade de gerenciamento da infraestrutura local usando credenciais armazenadas localmente. Se essas credenciais não forem atualizadas, a ponte de recursos não poderá mais se comunicar com o ponto de extremidade de gerenciamento. Isso pode causar problemas ao tentar atualizar a ponte de recursos ou gerenciar VMs por meio do Azure. Para corrigir isso, as credenciais na VM do dispositivo precisam ser atualizadas. Para obter mais informações, consulte Atualizar credenciais na VM do dispositivo.

A ponte de recursos do Arc não suporta link privado. Todas as chamadas provenientes da VM do dispositivo não devem passar pela configuração do link privado. Os IPs de Link Privado podem entrar em conflito com o intervalo de pool de IP do dispositivo, que não é configurável na ponte de recursos. A ponte de recursos do Arc alcança as URLs necessárias que não devem passar por uma conexão de link privado. Você deve implantar a ponte de recursos Arc em um segmento de rede separado não relacionado à configuração do link privado.

Problemas de rede

Erro de imagem de retirada de back-off

Ao tentar implantar a ponte de recursos do Arc, você pode ver um erro que contém back-off pulling image \\\"url"\\\: FailFastPodCondition. Este erro é causado quando a VM do dispositivo não consegue alcançar o URL especificado no erro. Para resolver esse problema, verifique se a VM do dispositivo atende aos requisitos do sistema, incluindo conectividade de acesso à Internet para URLs de lista de permissões necessárias.

Não é possível conectar-se ao URL

Se você receber um erro que contenha Not able to connect to https://example.url.como , verifique com o administrador da rede se a rede permite que todas as URLs de firewall e proxy necessárias implantem a ponte de recursos do Arc. Para obter mais informações, consulte Requisitos de rede da ponte de recursos do Azure Arc.

Servidor Http2 enviado GOAWAY

Ao tentar implantar a ponte de recursos do Arc, você pode receber uma mensagem de erro semelhante a:

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

Isso ocorre quando um firewall ou proxy tem a inspeção SSL/TLS habilitada e bloqueia chamadas http2 da máquina usada para implantar a ponte de recursos. Para confirmar que esse é o problema, execute o seguinte cmdlet do PowerShell para invocar a solicitação da Web com http2 (requer a versão 7 ou superior do PowerShell), substituindo a região na URL e na versão api (ex:2019-11-01) por valores do erro:

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

Se o resultado for The response ended prematurely while waiting for the next frame from the server, então a chamada http2 está sendo bloqueada e precisa ser permitida. Trabalhe com o administrador da rede para desativar a inspeção SSL/TLS para permitir chamadas http2 da máquina usada para implantar a ponte.

Nenhum host - .local não suportado

Ao tentar definir a configuração para a ponte de recursos Arc, você pode receber uma mensagem de erro semelhante a:

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

Isso ocorre quando um .local caminho é fornecido para uma definição de configuração, como proxy, dns, armazenamento de dados ou ponto de extremidade de gerenciamento (como o vCenter). A VM do dispositivo Arc resource bridge usa o sistema operacional Linux do Azure, que não oferece suporte .local por padrão. Uma solução alternativa pode ser fornecer o endereço IP, quando aplicável.

A ponte de recursos do Azure Arc está inacessível

A ponte de recursos do Azure Arc executa um cluster do Kubernetes e seu plano de controle requer um endereço IP estático. O endereço IP é especificado no infra.yaml arquivo. Se o endereço IP for atribuído a partir de um servidor DHCP, o endereço pode mudar se não estiver reservado. Reinicializar a ponte de recursos ou VM do Azure Arc pode disparar uma alteração de endereço IP, resultando em serviços com falha.

Intermitentemente, a ponte de recursos pode perder a configuração de IP reservado. Isso ocorre devido ao comportamento descrito na perda de VIPs quando systemd-networkd é reiniciado. Quando o endereço IP não é atribuído à VM da ponte de recursos do Azure Arc, qualquer chamada para o servidor de API da ponte de recursos falhará. Como resultado, você não pode criar nenhum novo recurso por meio da ponte de recursos, desde conectar-se à nuvem privada do Azure Arc, criar um local personalizado, criar uma VM, etc.

Outra causa possível é o acesso lento ao disco. A ponte de recursos do Azure Arc usa etcd, que requer latência de 10 ms ou menos por recomendação. Se o disco subjacente tiver baixo desempenho, isso pode afetar as operações e causar falhas.

Para resolver esse problema, reinicialize a VM de ponte de recursos e ela deve recuperar seu endereço IP. Se o endereço for atribuído a partir de um servidor DHCP, reserve o endereço IP associado à ponte de recursos.

Problemas de configuração de proxy SSL

Certifique-se de que o servidor proxy em sua máquina de gerenciamento confia no certificado SSL para seu proxy SSL e no certificado SSL dos servidores de download da Microsoft. Para obter mais informações, consulte Configuração de proxy SSL.

Nenhum anfitrião - dp.kubernetesconfiguration.azure.com

Um erro que contém dial tcp: lookup westeurope.dp.kubernetesconfiguration.azure.com: no such host durante a implantação da ponte de recursos Arc significa que o dataplane de configuração está atualmente indisponível na região especificada. O serviço pode estar temporariamente indisponível. Aguarde até que o serviço esteja disponível e, em seguida, tente novamente a implantação.

Proxy connect tcp - Nenhum host para Arc resource bridge URL necessário

Um erro que contém uma URL necessária da ponte de recursos Arc com a mensagem proxyconnect tcp: dial tcp: lookup http: no such host indica que o DNS não é capaz de resolver a URL. O erro pode ser semelhante ao exemplo abaixo, onde o URL necessário é 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}_ }

Este erro pode ocorrer se as configurações de DNS fornecidas durante a implantação não estiverem corretas ou se houver um problema com o(s) servidor(es) DNS. Você pode verificar se o servidor DNS é capaz de resolver a url executando o seguinte comando da máquina de gerenciamento ou de uma máquina que tenha acesso ao(s) servidor(es) DNS:

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

Para resolver o erro, o(s) seu(s) servidor(es) DNS deve(m) ser configurado(s) para resolver todas as URLs necessárias da ponte de recursos Arc e o(s) servidor(es) DNS(s) deve(m) ser fornecido(s) corretamente durante a implantação da ponte de recursos Arc.

Erro de tempo limite do KVA

O erro de tempo limite do KVA é um erro genérico que pode ser o resultado de uma variedade de configurações incorretas de rede que envolvem a máquina de gerenciamento, a VM do dispositivo ou o IP do plano de controle que não têm comunicação entre si, com a Internet ou com as URLs necessárias. Esta falha de comunicação deve-se frequentemente a problemas com a resolução de DNS, definições de proxy, configuração de rede ou acesso à Internet.

Para maior clareza, a máquina de gerenciamento refere-se à máquina onde os comandos da CLI de implantação estão sendo executados. Appliance VM é a VM que hospeda a ponte de recursos Arc. O IP do Plano de Controle é o IP do plano de controle para o cluster de gerenciamento do Kubernetes na VM do Dispositivo.

Principais causas do erro de tempo limite do KVA

  • A máquina de gerenciamento não consegue se comunicar com o IP do Plano de Controle e o IP da VM do Aparelho.
  • A VM do dispositivo não consegue se comunicar com a máquina de gerenciamento, o ponto de extremidade vCenter (para VMware) ou o ponto de extremidade do agente de nuvem MOC (para Azure Stack HCI). 
  • A VM do aparelho não tem acesso à Internet.
  • A VM do dispositivo tem acesso à Internet, mas a conectividade com uma ou mais URLs necessárias está sendo bloqueada, possivelmente devido a um proxy ou firewall.
  • A VM do dispositivo não consegue acessar um servidor DNS que possa resolver nomes internos, como ponto de extremidade vCenter para vSphere ou ponto de extremidade de agente de nuvem para Azure Stack HCI. O servidor DNS também deve ser capaz de resolver endereços externos, como endereços de serviço do Azure e nomes de registro de contêiner. 
  • A configuração do servidor proxy na máquina de gerenciamento ou nos arquivos de configuração da ponte de recursos Arc está incorreta. Isso pode afetar a máquina de gerenciamento e a VM do Appliance. Quando o az arcappliance prepare comando é executado, a máquina de gerenciamento não poderá se conectar e baixar imagens do sistema operacional se o proxy do host não estiver configurado corretamente. O acesso à Internet na VM do Appliance pode ser interrompido pela configuração de proxy incorreta ou ausente, o que afeta a capacidade da VM de extrair imagens de contêiner. 

Solucionar problemas de erro de tempo limite do KVA

Para resolver o erro, uma ou mais configurações incorretas de rede podem precisar ser resolvidas. Siga as etapas abaixo para abordar os motivos mais comuns para esse erro.

  1. Quando há um problema com a implantação, a primeira etapa é coletar logs pelo IP da VM do Appliance (não pelo kubeconfig, pois o kubeconfig pode estar vazio se o comando deploy não for concluído). Os problemas na coleta de logs são provavelmente devido à incapacidade da máquina de gerenciamento de acessar a VM do Appliance.

    Uma vez que os logs são coletados, extraia a pasta e abra kva.log. Analise o kva.log para obter mais informações sobre a falha em ajudar a identificar a causa do erro de tempo limite do KVA.

  2. A máquina de gerenciamento deve ser capaz de se comunicar com o IP da VM do dispositivo e o IP do plano de controle. Execute ping no IP do Plano de Controle e no IP da VM do Dispositivo a partir da máquina de gerenciamento e verifique se há uma resposta de ambos os IPs.

    Se uma solicitação expirar, a máquina de gerenciamento não poderá se comunicar com o(s) IP(s). Isso pode ser causado por uma porta fechada, configuração incorreta da rede ou um bloco de firewall. Trabalhe com o administrador da rede para permitir a comunicação entre a máquina de gerenciamento e o IP do plano de controle e o IP da VM do aparelho.

  3. O IP da VM do dispositivo e o IP do plano de controle devem ser capazes de se comunicar com a máquina de gerenciamento e o ponto de extremidade do vCenter (para VMware) ou o ponto de extremidade do agente de nuvem MOC (para HCI). Trabalhe com o administrador da rede para garantir que a rede está configurada para permitir isso. Isso pode exigir a adição de uma regra de firewall para abrir a porta 443 do IP da VM do Appliance e do IP do Plano de Controle para o vCenter ou a porta 65000 e 55000 para o agente de nuvem MOC HCI do Azure Stack. Analise os requisitos de rede para o Azure Stack HCI e a ponte de recursos VMware for Arc.

  4. O IP da VM do dispositivo e o IP do Plano de Controle precisam de acesso à Internet para essas URLs necessárias. O Azure Stack HCI requer URLs adicionais. Trabalhe com o administrador da rede para garantir que os IPs possam acessar as URLs necessárias.

  5. Em um ambiente sem proxy, a máquina de gerenciamento deve ter resolução DNS externa e interna. A máquina de gerenciamento deve ser capaz de acessar um servidor DNS que possa resolver nomes internos, como ponto de extremidade vCenter para vSphere ou ponto de extremidade de agente de nuvem para Azure Stack HCI. O servidor DNS também precisa ser capaz de resolver endereços externos, como URLs do Azure e URLs de download de imagens do sistema operacional. Trabalhe com o administrador do sistema para garantir que a máquina de gerenciamento tenha resolução DNS interna e externa. Em um ambiente de proxy, a resolução DNS no servidor proxy deve resolver pontos de extremidade internos e endereços externos necessários.

    Para testar a resolução DNS para um endereço interno da máquina de gerenciamento em um cenário sem proxy, abra o prompt de comando e execute nslookup <vCenter endpoint or HCI MOC cloud agent IP>. Você deve receber uma resposta se a máquina de gerenciamento tiver resolução DNS interna em um cenário sem proxy. 

  6. A VM do dispositivo precisa ser capaz de alcançar um servidor DNS que possa resolver nomes internos, como ponto de extremidade vCenter para vSphere ou ponto de extremidade do agente de nuvem para Azure Stack HCI. O servidor DNS também precisa ser capaz de resolver endereços externos/internos, como endereços de serviço do Azure e nomes de registro de contêiner para download das imagens de contêiner da ponte de recursos Arc da nuvem.

    Verifique se o IP do servidor DNS usado para criar os arquivos de configuração tem resolução de endereço interno e externo. Caso contrário, exclua o dispositivo, recrie os arquivos de configuração da ponte de recursos Arc com as configurações corretas do servidor DNS e, em seguida, implante a ponte de recursos Arc usando os novos arquivos de configuração.

Mover o local da ponte de recursos do Arc

A movimentação de recursos da ponte de recursos Arc não é suportada no momento. Você precisará excluir a ponte de recursos Arc e, em seguida, reimplantá-la no local desejado.

VMs habilitadas para Azure Arc em problemas de HCI do Azure Stack

Para obter ajuda geral para resolver problemas relacionados a VMs habilitadas para Azure Arc no Azure Stack HCI, consulte Solucionar problemas de máquinas virtuais habilitadas para Azure Arc.

Falha no handshake de autenticação

Ao executar um az arcappliance comando, você pode ver um erro de conexão: authentication handshake failed: x509: certificate signed by unknown authority

Isso geralmente é causado ao tentar executar comandos do PowerShell remoto, que não é suportado pela ponte de recursos do Azure Arc.

Para instalar a ponte de recursos do Azure Arc em um cluster HCI do Azure Stack, az arcappliance os comandos devem ser executados localmente em um nó no cluster. Entre no nó por meio do protocolo RDP (Remote Desktop Protocol) ou use uma sessão de console para executar esses comandos.

Problemas do VMware VCenter habilitado para Azure Arc

Cliente vSphere SDK 403 Proibido ou 404 não encontrado

Se você receber um erro que contenha errorCode_: _CreateConfigKvaCustomerError_, _errorResponse_: _error getting the vsphere sdk client: POST \_/sdk\_: 403 Forbidden ou 404 not found durante a implantação da ponte de recursos Arc, isso provavelmente se deve a uma URL incorreta do vCenter sendo fornecida durante a criação do arquivo de configuração, onde você será solicitado a inserir o endereço do vCenter como FQDN ou endereço IP. Há diferentes maneiras de encontrar seu endereço vCenter. Uma opção é acessar o cliente vSphere através de sua interface web. O FQDN ou endereço IP do vCenter é normalmente o que você usa no navegador para acessar o cliente vSphere. Se já tiver sessão iniciada, pode consultar a barra de endereço do navegador; o URL que você usa para acessar o vSphere é o FQDN ou o endereço IP do seu servidor vCenter. Como alternativa, depois de fazer login, vá para a seção Administração do menu > . Em Configuração do Sistema, escolha Nós. A(s) instância(s) do servidor vCenter será(ão) listada(s) lá, juntamente com seu FQDN. Verifique o endereço do vCenter e tente novamente a implantação.

Erros de validação pré-implantação

Se você estiver recebendo uma variedade de pre-deployment validation of your download\upload connectivity wasn't successful erros, como:

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

Uma combinação desses erros geralmente indica que a máquina de gerenciamento perdeu a conexão com o armazenamento de dados ou que há um problema de rede que faz com que o armazenamento de dados fique inacessível. Essa conexão é necessária para carregar o OVA da máquina de gerenciamento usada para criar a VM do dispositivo no vCenter. A conexão entre a máquina de gerenciamento e o armazenamento de dados precisa ser restabelecida e, em seguida, tentar implantar novamente a ponte de recursos do Arc.

O certificado x509 expirou ou ainda não é válido

Ao implantar a ponte de recursos do Arc, você pode encontrar o erro:

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

Este erro é causado quando há uma diferença de hora/relógio entre o(s) host(s) ESXi e a máquina de gerenciamento onde os comandos de implantação para a ponte de recursos Arc estão sendo executados. Para resolver esse problema, ative a sincronização de tempo NTP no(s) host(s) ESXi e confirme se a máquina de gerenciamento também está sincronizada com NTP e, em seguida, tente a implantação novamente.

Erro durante a configuração do host

Se você estiver usando o mesmo modelo para implantar e excluir a ponte de recursos Arc várias vezes, poderá encontrar o seguinte erro:

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

Para resolver esse problema, exclua manualmente o modelo existente. Em seguida, execute az arcappliance prepare para baixar um novo modelo para implantação.

Não é possível localizar pastas

Ao implantar a ponte de recursos no VMware vCenter, especifique a pasta na qual o modelo e a VM serão criados. A pasta deve ser VM e tipo de pasta modelo. Outros tipos de pasta, como pastas de armazenamento, pastas de rede ou pastas de host e cluster, não podem ser usados para a implantação da ponte de recursos.

Permissões insuficientes

Ao implantar a ponte de recursos no VMware vCenter, você pode receber um erro informando que não tem permissão suficiente. Para resolver esse problema, verifique se a conta de usuário que está sendo usada para implantar a ponte de recursos tem todos os seguintes privilégios no VMware vCenter e tente novamente.

Armazenamento de dados 

  • Alocar espaço
  • Procurar armazenamento de dados
  • Operações de arquivo de baixo nível

Pasta 

  • Criar pasta

Marcação vSphere

  • Atribuir ou cancelar a atribuição da tag vSphere

Rede 

  • Atribuir rede

Recurso

  • Atribuir máquina virtual ao pool de recursos
  • Migrar máquina virtual desligada
  • Migrar com tecnologia de máquina virtual

Sessões

  • Validar sessão

vApp

  • Atribuir pool de recursos
  • Importação

Máquina virtual

  • Alterar configuração
    • Adquirir locação de disco
    • Adicionar disco existente
    • Adicionar novo disco
    • Adicionar ou remover dispositivo
    • Configuração avançada
    • Alterar a contagem de CPU
    • Alterar memória
    • Alterar configurações
    • Alterar recurso
    • Configurar managedBy
    • Exibir configurações de conexão
    • Estender disco virtual
    • Modificar as configurações do dispositivo
    • Compatibilidade com tolerância a falhas de consulta
    • Consultar arquivos sem propriedade
    • Recarregar a partir do caminho
    • Remover disco
    • Mudar o nome
    • Redefinir informações do hóspede
    • Definir anotação
    • Alternar o controle de alterações de disco
    • Alternar pai de garfo
    • Atualizar a compatibilidade da máquina virtual
  • Editar inventário
    • Criar a partir do existente
    • Criar nova
    • Registar
    • Remover
    • Anular o Registo
  • Operações com hóspedes
    • Modificação do alias de operação do convidado
    • Modificações na operação do convidado
    • Execução do programa de operação convidado
    • Consultas de operação de convidado
  • Interação
    • Ligar dispositivos
    • Interação com o console
    • Gerenciamento de sistema operacional convidado pela API VIX
    • Instalar o VMware Tools
    • Desligamento
    • Ligar
    • Reset
    • Suspender
  • Provisionamento
    • Permitir acesso ao disco
    • Permitir acesso a ficheiros
    • Permitir acesso somente leitura ao disco
    • Permitir download de máquina virtual
    • Permitir o carregamento de arquivos de máquina virtual
    • Clonar máquina virtual
    • Implementar o modelo
    • Marcar como modelo
    • Marcar como máquina virtual
    • Personalizar convidado
  • Gerenciamento de snapshots
    • Criar instantâneo
    • Remover instantâneo
    • Reverter para snapshot

Próximos passos

Compreender as operações de recuperação para ponte de recursos em cenários de desastre VMware vSphere habilitados para Azure Arc

Se não vir o problema aqui ou não conseguir resolvê-lo, experimente um dos seguintes canais de suporte:

  • Obtenha respostas de especialistas do Azure através das Perguntas e Respostas da Microsoft.
  • Conecte-se com @AzureSupport, a conta oficial do Microsoft Azure para melhorar a experiência do cliente. O Suporte do Azure conecta a comunidade do Azure a respostas, suporte e especialistas.
  • Abra uma solicitação de suporte do Azure.