Felsöka problem med Azure Arc-resursbryggan

Den här artikeln innehåller information om hur du felsöker och löser problem som kan uppstå när du försöker distribuera, använda eller ta bort Azure Arc-resursbryggan. Resursbryggningen är en paketerad virtuell dator som är värd för ett Kubernetes-hanteringskluster . Allmän information finns i Översikt över Azure Arc-resursbryggan.

Allmänna problem

Insamling av loggar

För problem som uppstår med Arc-resursbryggan samlar du in loggar för ytterligare undersökning med hjälp av Azure CLI-kommandot az arcappliance logs . Det här kommandot måste köras från hanteringsdatorn som används för att distribuera Arc-resursbryggan. Om du använder en annan dator måste datorn uppfylla kraven för hanteringsdatorn.

Om det uppstår ett problem med att samla in loggar kan hanteringsdatorn troligen inte nå den virtuella enhetens virtuella dator. Kontakta nätverksadministratören om du vill tillåta SSH-kommunikation från hanteringsdatorn till den virtuella datorinstallationen på TCP-port 22.

Du kan samla in Arc-resursbryggningsloggarna genom att skicka antingen vm-IP-adressen för installationen eller kubeconfig i loggkommandot.

Så här samlar du in Arc-resursbryggningsloggar på VMware med hjälp av den virtuella datorns IP-adress för installationen:

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

Så här samlar du in Arc-resursbryggningsloggar för Azure Stack HCI med hjälp av den virtuella datorns IP-adress för installationen:

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

Om du är osäker på vm-IP-adressen för installationen finns det också möjlighet att använda kubeconfig. Du kan hämta kubeconfig genom att köra kommandot get-credentials och sedan köra kommandot logs.

Hämta kubeconfig och loggnyckeln genom att samla in loggar för Arc-aktiverade VMware från en annan dator än den som används för att distribuera Arc-resursbryggan för Arc-aktiverad VMware:

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>

Nedladdnings-/uppladdningsanslutningen lyckades inte

Om nätverkshastigheten är långsam kan det hända att du inte kan ladda ned vm-avbildningen för Arc-resursbryggan och det här felet kan inträffa: 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.

Om felet beror på långsam nätverkshastighet som påverkar uppladdningen är en lösning att skapa en virtuell dator direkt i det lokala privata molnet och sedan köra distributionsskriptet för Arc-resursbryggan från den virtuella datorn. Den här lösningen säkerställer en snabbare uppladdning av avbildningen till datalagringen.

Tidsgränsen för kontexten har överskrids under fasen ApplyingKvaImageOperator

Du kan få följande fel när du distribuerar Arc-resursbryggan: 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}_ }

Det här felet uppstår vanligtvis när du försöker ladda ned avbildningen KVAIO (400 MB komprimerad) över ett nätverk som är långsamt eller har tillfälliga anslutningar. Kontrollanthanteraren KVAIO väntar på att avbildningen ska laddas ned och tidsgränsen uppnås. Du kanske vill kontrollera att nätverkshastigheten mellan den virtuella Arc-resursbryggan och Microsoft Container Registry (mcr.microsoft.com) är stabil och minst 2 Mbit/s. Om nätverksanslutningen och hastigheten är stabil och du fortfarande får det här felet väntar du minst 30 minuter innan du försöker igen eftersom Microsoft Container Registry kanske får en hög trafikvolym.

Tidsgränsen för kontexten har överskrids under fasen WaitingForAPIServer

När du distribuerar Arc-resursbryggan kan du få felet: 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

Det här felet anger att distributionsdatorn inte kan kontakta kontrollplanets IP-adress för Arc-resursbryggan inom tidsgränsen. Vanliga orsaker till felet är ofta nätverksrelaterade, till exempel kommunikation mellan distributionsdatorn och kontrollplanets IP-adress som dirigeras via en proxyserver. Trafik från distributionsdatorn till kontrollplanet och vm-IP-adresserna för installationen får inte passera via proxyn. Om trafiken är proxied konfigurerar du proxyinställningarna på nätverket eller distributionsdatorn för att inte proxytrafik mellan distributionsdatorn till kontrollplanets IP- och installations-IP-adresser. En annan orsak till det här felet är om en brandvägg stänger åtkomsten till port 6443 och port 22 mellan distributionsdatorn och kontrollplanets IP-adress eller vm-IP-adresser för distributionsdatorn och installationen.

UploadError 403 Förbjuden eller 404 Webbplats hittades inte

När du distribuerar Arc-resursbryggan kan du få felet: { _errorCode_: _UploadError_, _errorResponse_: _{\n\_message\_: \_Pre-deployment validation of your download/upload connectivity was not successful. {\\n \\\_code\\\_: \\\_ImageProvisionError\\\_,\\n \\\_message\\\_: \\\_403 Forbidden eller { _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

Det här felet uppstår i distributionsprocessen när avbildningar måste laddas ned från Microsoft-register till distributionsdatorn och nedladdningen blockeras av en proxy eller brandvägg. Granska nätverkskraven och kontrollera att alla nödvändiga URL:er kan nås. Du kan behöva uppdatera dina inga proxyinställningar för att säkerställa att trafik från distributionsdatorn till Microsofts url:er som krävs inte går via en proxyserver.

Arc-resursbryggan är offline

Om resursbryggningen är offline beror detta vanligtvis på en nätverksändring i infrastrukturen, miljön eller klustret som hindrar den virtuella datorn från att kunna kommunicera med sin motsvarighet i Azure-resursen. Om du inte kan avgöra vad som har ändrats kan du starta om den virtuella datorn, samla in loggar och skicka ett supportärende för vidare undersökning.

Fjärr-PowerShell stöds inte

Om du kör az arcappliance CLI-kommandon för Arc Resource Bridge via fjärransluten PowerShell kan det uppstå olika problem. Du kan till exempel se ett fel i handskakningsfelet för autentisering när du försöker installera resursbryggan i ett Azure Stack HCI-kluster eller någon annan typ av fel. Det finns för närvarande inte stöd för att använda az arcappliance kommandon från fjärranslutna PowerShell. Logga i stället in på noden via RDP (Remote Desktop Protocol) eller använd en konsolsession.

Det går inte att uppdatera konfigurationer för resursbryggor

I den här versionen anges alla parametrar när de skapas. Om du vill uppdatera Azure Arc-resursbryggan måste du ta bort den och distribuera den igen. Om du till exempel har angett fel plats eller prenumeration under distributionen misslyckas resursskapandet senare. Om du bara försöker återskapa resursen utan att distribuera om den virtuella resursbryggans virtuella dator ser du att statusen har fastnat på WaitForHeartBeat. Lös problemet genom att ta bort installationen och uppdatera YAML-filen för installationen. Distribuera sedan om och skapa resursbryggans.

Enhetens nätverk är inte tillgängligt

Om Arc-resursbryggan har ett nätverksproblem kan du se felet "Apparatnätverk är inte tillgängligt". I allmänhet kan eventuella problem med nätverks- eller infrastrukturanslutningar till den virtuella datorn orsaka det här felet. Det här felet kan också visas som "Fel vid uppringning tcp xx.xx.xxx.xx:55000: anslut: ingen väg till värden". Problemet kan vara att kommunikationen från värden till den virtuella Arc-resursbryggan måste öppnas via TCP-port 22 med hjälp av nätverksadministratören. Ett tillfälligt nätverksproblem kanske inte tillåter att värden når den virtuella Arc-resursbryggan. När nätverksproblemet har lösts kan du försöka utföra åtgärden igen. Du kan också kontrollera att den virtuella datorn för Arc-resursbryggan inte stoppas eller är offline. När det gäller Azure Stack HCI kan värdlagringen vara full och lagringen måste åtgärdas.

Tokenuppdateringsfel

När du kör Azure CLI-kommandona kan följande fel returneras: Uppdateringstoken har upphört att gälla eller är ogiltig på grund av inloggningsfrekvenskontroller med villkorlig åtkomst. Felet uppstår eftersom token har en maximal livslängd när du loggar in på Azure. När livslängden az login överskrids måste du logga in på Azure igen med hjälp av kommandot .

Standardvärdens resurspooler är inte tillgängliga för distribution

När du använder az arcappliance createconfig kommandot eller az arcappliance run finns det en interaktiv upplevelse som visar listan över de VMware-entiteter där du kan välja att distribuera den virtuella installationen. Den här listan visar alla användarskapade resurspooler. tillsammans med standardklusterresurspooler, men standardvärdens resurspooler visas inte. När installationen distribueras till en värdresurspool finns det ingen hög tillgänglighet om värdmaskinvaran misslyckas. Vi rekommenderar att du inte distribuerar installationen i en värdresurspool.

Resursbryggningsstatus "Offline" och provisioningState "Misslyckades"

När du distribuerar Arc-resursbryggan kan det verka som om bryggan har distribuerats, eftersom inga fel påträffades när den kördes az arcappliance deploy eller az arcappliance create. Men när du visar bryggan i Azure-portalen kan statusen visas som Offline och az arcappliance show kan visa provisioningState som Misslyckad. Detta inträffar när nödvändiga leverantörer inte registreras innan bryggan distribueras.

Lös problemet genom att ta bort resursbryggans, registrera providrar och sedan distribuera om resursbryggans.

1. Ta bort resursbryggningen:

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

2. Registrera leverantörerna:

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

3. Distribuera om resursbryggans.

Kommentar

Partnerprodukter (till exempel Arc-aktiverade VMware vSphere) kan ha egna leverantörer som krävs för registrering. Information om hur du ser ytterligare leverantörer som måste registreras finns i produktens dokumentation.

Utgångna autentiseringsuppgifter på den virtuella enhetens virtuella dator

Arc-resursbryggan består av en virtuell dator som distribueras till den lokala infrastrukturen. Den virtuella datorn underhåller en anslutning till hanteringsslutpunkten för den lokala infrastrukturen med hjälp av lokalt lagrade autentiseringsuppgifter. Om dessa autentiseringsuppgifter inte uppdateras kan resursbryggningen inte längre kommunicera med hanteringsslutpunkten. Detta kan orsaka problem när du försöker uppgradera resursbryggan eller hantera virtuella datorer via Azure. För att åtgärda detta måste autentiseringsuppgifterna på den virtuella datorn för installationen uppdateras. Mer information finns i Uppdatera autentiseringsuppgifter på den virtuella datorn för installationen.

Privat länk stöds inte

Arc-resursbryggan stöder inte privat länk. Alla samtal som kommer från den virtuella datorn ska inte gå igenom konfigurationen av den privata länken. IP-adresserna för Private Link kan vara i konflikt med ip-poolintervallet för installationen, som inte kan konfigureras på resursbryggningen. Arc-resursbryggan når ut till nödvändiga URL:er som inte ska gå via en privat länkanslutning. Du måste distribuera Arc-resursbryggan i ett separat nätverkssegment som inte är relaterat till konfigurationen av den privata länken.

Nätverksproblem

Fel vid back-off-hämtning av avbildning

När du försöker distribuera Arc-resursbryggan kan ett fel visas som innehåller back-off pulling image \\\"url"\\\: FailFastPodCondition. Det här felet orsakas när den virtuella datorn för installationen inte kan nå den URL som angavs i felet. Lös problemet genom att se till att den virtuella datorn uppfyller systemkraven, inklusive internetanslutning till nödvändiga url:er för tillåtna listor.

Det går inte att ansluta till URL:en

Om du får ett fel som innehåller Not able to connect to https://example.url.comkontrollerar du med nätverksadministratören att nätverket tillåter att alla nödvändiga brandväggs- och proxy-URL:er distribuerar Arc-resursbryggan. Mer information finns i Nätverkskraven för Azure Arc-resursbryggan.

Http2-servern skickade GOAWAY

När du försöker distribuera Arc-resursbryggan kan du få ett felmeddelande som liknar:

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

Detta inträffar när en brandvägg eller proxy har SSL/TLS-inspektion aktiverat och blockerar http2-anrop från den dator som används för att distribuera resursbryggorna. Bekräfta att det här är problemet genom att köra följande PowerShell-cmdlet för att anropa webbbegäran med http2 (kräver PowerShell version 7 eller senare) och ersätta regionen i URL:en och api-versionen (t.ex. 2019-11-01) med värden från felet:

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

Om resultatet är The response ended prematurely while waiting for the next frame from the serverblockeras http2-anropet och måste tillåtas. Arbeta med nätverksadministratören för att inaktivera SSL/TLS-inspektionen för att tillåta http2-anrop från den dator som används för att distribuera bryggan.

Ingen sådan värd – .local stöds inte

När du försöker ställa in konfigurationen för Arc-resursbryggan kan du få ett felmeddelande som liknar:

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

Detta inträffar när en .local sökväg tillhandahålls för en konfigurationsinställning, till exempel proxy, dns, datalager eller hanteringsslutpunkt (till exempel vCenter). Den virtuella arc-resursbryggan använder Azure Linux OS, vilket inte stöds .local som standard. En lösning kan vara att ange IP-adressen i förekommande fall.

Azure Arc-resursbryggan kan inte nås

Azure Arc-resursbryggan kör ett Kubernetes-kluster, och dess kontrollplan kräver en statisk IP-adress. IP-adressen anges i infra.yaml filen. Om IP-adressen tilldelas från en DHCP-server kan adressen ändras om den inte är reserverad. Omstart av Azure Arc-resursbryggan eller den virtuella datorn kan utlösa en ÄNDRING av IP-adressen och resultera i misslyckade tjänster.

Arc-resursbryggan kan tillfälligt förlora den reserverade IP-konfigurationen. Den här förlusten beror på beteendet som beskrivs vid förlust av VIP-adresser när systemd-networkd den startas om. När IP-adressen inte har tilldelats till den virtuella Azure Arc-resursbryggan misslyckas alla anrop till resursbryggans API-server. Kärnåtgärder, till exempel att skapa en ny resurs, ansluta till ditt privata moln från Azure eller skapa en anpassad plats, fungerar inte som förväntat. Lös problemet genom att starta om den virtuella resursbryggningsdatorn och återställa ip-adressen. Om adressen har tilldelats från en DHCP-server reserverar du DEN IP-adress som är associerad med resursbryggningen.

Arc-resursbryggan kan också vara oåtkomlig på grund av långsam diskåtkomst. Azure Arc-resursbryggan använder Kubernetes extended configuration tree (ETCD), som kräver svarstid på minst 10 ms. Om den underliggande disken har låga prestanda påverkas åtgärder och fel kan inträffa.

Problem med SSL-proxykonfiguration

Se till att proxyservern på hanteringsdatorn litar på både SSL-certifikatet för SSL-proxyn och SSL-certifikatet för Microsofts nedladdningsservrar. Mer information finns i SSL-proxykonfiguration.

Ingen sådan värd – dp.kubernetesconfiguration.azure.com

Ett fel som innehåller dial tcp: lookup westeurope.dp.kubernetesconfiguration.azure.com: no such host när arc-resursbryggan distribueras innebär att konfigurationsdataplanen för närvarande inte är tillgängligt i den angivna regionen. Tjänsten kan vara tillfälligt otillgänglig. Vänta tills tjänsten är tillgänglig och försök sedan distribuera igen.

Proxyanslutnings-tcp – Ingen sådan värd för Arc-resursbryggan krävs URL

Ett fel som innehåller en Arc-resursbrygga krävs URL med meddelandet proxyconnect tcp: dial tcp: lookup http: no such host anger att DNS inte kan matcha URL:en. Felet kan se ut ungefär som i exemplet nedan, där den url som krävs är 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}_ }

Det här felet kan inträffa om DNS-inställningarna som angavs under distributionen inte är korrekta eller om det finns ett problem med DNS-servrarna. Du kan kontrollera om DNS-servern kan matcha URL:en genom att köra följande kommando från hanteringsdatorn eller en dator som har åtkomst till DNS-servrarna:

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

För att lösa felet måste dns-servrarna konfigureras för att lösa alla Url:er som krävs för Arc-resursbryggan och DNS-servrarna ska tillhandahållas korrekt under distributionen av Arc-resursbryggan.

KVA-timeoutfel

KVA-timeoutfelet är ett allmänt fel som kan bero på en mängd olika nätverksfelkonfigurationer som involverar hanteringsdatorn, den virtuella datorn för installation eller kontrollplanets IP-adress som inte har kommunikation med varandra, till Internet eller nödvändiga URL:er. Det här kommunikationsfelet beror ofta på problem med DNS-matchning, proxyinställningar, nätverkskonfiguration eller Internetåtkomst.

För tydlighetens skull refererar hanteringsdatorn till den dator där CLI-kommandon för distribution körs. Den virtuella datorn är den virtuella dator som är värd för Arc-resursbryggan. Kontrollplans-IP är IP-adressen för kontrollplanet för Kubernetes-hanteringsklustret på den virtuella datorn Installation.

De främsta orsakerna till KVA-timeoutfelet

• Hanteringsdatorn kan inte kommunicera med IP-adressen för kontrollplanet och vm-IP-adressen för apparaten.
• Den virtuella datorn för installation kan inte kommunicera med hanteringsdatorn, vCenter-slutpunkten (för VMware) eller MOC-molnagentens slutpunkt (för Azure Stack HCI). 
• Den virtuella installationens virtuella dator har inte internetåtkomst.
• Den virtuella datorn har internetåtkomst, men anslutningen till en eller flera nödvändiga URL:er blockeras, möjligen på grund av en proxy eller brandvägg.
• Den virtuella datorn för installationen kan inte nå en DNS-server som kan matcha interna namn, till exempel vCenter-slutpunkt för vSphere eller molnagentslutpunkt för Azure Stack HCI. DNS-servern måste också kunna matcha externa adresser, till exempel Azure-tjänstadresser och containerregisternamn. 
• Konfigurationen av proxyservern på hanteringsdatorn eller Arc-resursbryggan är felaktig. Detta kan påverka både hanteringsdatorn och den virtuella enhetens virtuella dator. az arcappliance prepare När kommandot körs kan hanteringsdatorn inte ansluta och ladda ned OS-avbildningar om värdproxyn inte är korrekt konfigurerad. Internetåtkomsten på den virtuella enhetens virtuella dator kan brytas av felaktig eller saknad proxykonfiguration, vilket påverkar den virtuella datorns möjlighet att hämta containeravbildningar. 

Felsöka KVA-timeoutfel

För att lösa felet kan en eller flera felkonfigurationer i nätverket behöva åtgärdas. Följ stegen nedan för att åtgärda de vanligaste orsakerna till det här felet.

1. När det är problem med distributionen är det första steget att samla in loggar efter VM-IP för installation (inte av kubeconfig, eftersom kubeconfig kan vara tom om distributionskommandot inte slutfördes). Problem med att samla in loggar beror troligen på att hanteringsdatorn inte kan nå den virtuella enhetens virtuella dator.

   När loggarna har samlats in extraherar du mappen och öppnar kva.log. Läs kva.log för mer information om felet för att hitta orsaken till KVA-timeoutfelet.

2. Hanteringsdatorn måste kunna kommunicera med DEN virtuella datorns IP-adress och kontrollplanets IP-adress. Pinga IP- och installations-IP-adressen för kontrollplanet från hanteringsdatorn och kontrollera att det finns ett svar från båda IP-adresserna.

   Om en begäran överskrider tidsgränsen kan hanteringsdatorn inte kommunicera med IP-adresserna. Detta kan orsakas av en stängd port, felkonfiguration av nätverket eller ett brandväggsblock. Arbeta med nätverksadministratören för att tillåta kommunikation mellan hanteringsdatorn till IP-adressen för kontrollplanet och VM-IP-adressen för installationen.

3. Den virtuella datorns IP- och kontrollplans-IP måste kunna kommunicera med hanteringsdatorn och vCenter-slutpunkten (för VMware) eller MOC-molnagentens slutpunkt (för HCI). Kontakta nätverksadministratören för att se till att nätverket är konfigurerat för att tillåta detta. Detta kan kräva att du lägger till en brandväggsregel för att öppna port 443 från VM-ip-adressen för installationen och kontrollplanets IP-adress till vCenter eller port 65000 och 55000 för Azure Stack HCI MOC-molnagenten. Granska nätverkskraven för Azure Stack HCI och VMware för Arc-resursbryggan.

4. Enhetens IP-adress för virtuella datorer och kontrollplanets IP-adress behöver internetåtkomst till dessa url:er som krävs. Azure Stack HCI kräver ytterligare URL:er. Samarbeta med nätverksadministratören för att se till att IP-adresserna har åtkomst till de url:er som krävs.

5. I en icke-proxymiljö måste hanteringsdatorn ha extern och intern DNS-matchning. Hanteringsdatorn måste kunna nå en DNS-server som kan matcha interna namn, till exempel vCenter-slutpunkt för vSphere eller molnagentslutpunkt för Azure Stack HCI. DNS-servern måste också kunna matcha externa adresser, till exempel Url:er för Azure och URL:er för hämtning av OS-avbildningar. Arbeta med systemadministratören för att säkerställa att hanteringsdatorn har intern och extern DNS-matchning. I en proxymiljö bör DNS-matchningen på proxyservern matcha interna slutpunkter och nödvändiga externa adresser.

   Om du vill testa DNS-matchning till en intern adress från hanteringsdatorn i ett scenario som inte är proxy öppnar du kommandotolken och kör nslookup <vCenter endpoint or HCI MOC cloud agent IP>. Du bör få ett svar om hanteringsdatorn har intern DNS-matchning i ett scenario som inte är proxy. 

6. Den virtuella enhetens virtuella dator måste kunna nå en DNS-server som kan matcha interna namn, till exempel vCenter-slutpunkt för vSphere eller molnagentslutpunkt för Azure Stack HCI. DNS-servern måste också kunna matcha externa/interna adresser, till exempel Azure-tjänstadresser och containerregisternamn för nedladdning av Arc-resursbryggcontainerns avbildningar från molnet.

   Kontrollera att DNS-serverns IP-adress som används för att skapa konfigurationsfilerna har intern och extern adressmatchning. Annars tar du bort installationen, återskapar Konfigurationsfilerna för Arc-resursbryggan med rätt DNS-serverinställningar och distribuerar sedan Arc-resursbryggan med hjälp av de nya konfigurationsfilerna.

Flytta Arc-resursbryggan

Resursflytt av Arc-resursbryggan stöds inte för närvarande. Du måste ta bort Arc-resursbryggan och sedan distribuera om den till önskad plats.

Problem med Azure Arc-aktiverade virtuella datorer i Azure Stack HCI

Allmän hjälp med att lösa problem som rör Azure Arc-aktiverade virtuella datorer på Azure Stack HCI finns i Felsöka azure Arc-aktiverade virtuella datorer.

Handskakningsfel för autentisering

När du kör ett az arcappliance kommando kan det uppstå ett anslutningsfel: authentication handshake failed: x509: certificate signed by unknown authority

Detta orsakas vanligtvis när du försöker köra kommandon från fjärranslutna PowerShell, som inte stöds av Azure Arc-resursbryggan.

Om du vill installera Azure Arc-resursbryggan i ett Azure Stack HCI-kluster az arcappliance måste kommandon köras lokalt på en nod i klustret. Logga in på noden via RDP (Remote Desktop Protocol) eller använd en konsolsession för att köra dessa kommandon.

Problem med Azure Arc-aktiverad VMware VCenter

errorCode: CreateConfigKvaCustomerError, errorResponse: error getting the vsphere sdk client

För fel med errorCode CreateConfigKvaCustomerError och errorResponse error getting the vsphere sdk clientuppstår dessa fel när distributionsdatorn försöker upprätta en TCP-anslutning till din vCenter-adress, men det uppstår ett problem. Du får det här feletCode och errorResponse om din vCenter-adress är felaktig (403- eller 404-fel) eller om det finns en nätverks-/proxy-/brandväggskonfiguration som blockerar den (anslutningsförsöket misslyckades). Om du anger din vCenter-adress som ett värdnamn och får felet no such hostkan distributionsdatorn inte matcha vCenter-värdnamnet via klientens DNS. Du kan få ett felmeddelande om distributionsdatorn kan matcha vCenter-värdnamnet, men distributionsdatorn inte kan nå DEN IP-adress som den tog emot från DNS. Du kan få ett fel om slutpunkten som returneras av DNS inte är din vCenter-adress eller om trafiken har avlyssnats av proxyn. Slutligen kan du få ett fel om distributionsdatorn kan kommunicera med din vCenter-adress, men användarnamnet eller lösenordet är felaktigt.

vSphere SDK-klient – Anslutningsförsöket misslyckades

Om du får ett fel under distributionen som anger: 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._ } kan distributionsdatorn inte kommunicera med din vCenter-server. Se till att distributionsdatorn uppfyller kraven för hanteringsdatorn och att det inte finns någon brandvägg eller proxy som blockerar kommunikationen.

vSphere SDK-klient – 403 Förbjudet eller 404 hittades inte

Om du får ett fel som innehåller errorCode_: _CreateConfigKvaCustomerError_, _errorResponse_: _error getting the vsphere sdk client: POST \_/sdk\_: 403 Forbidden eller 404 not found när du distribuerar Arc-resursbryggan beror det troligtvis på att en felaktig vCenter-adress angavs när konfigurationsfilen skapades när du uppmanas att ange vCenter-adressen som värdnamn eller IP-adress. Det finns olika sätt att hitta din vCenter-adress. Ett alternativ är att komma åt vSphere-klienten via dess webbgränssnitt. VCenter-värdnamnet eller IP-adressen är vanligtvis det du använder i webbläsaren för att komma åt vSphere-klienten. Om du redan är inloggad kan du titta på webbläsarens adressfält. DEN URL som du använder för att komma åt vSphere är vCenter-serverns värdnamn eller IP-adress. Kontrollera din vCenter-adress och prova sedan distributionen igen.

vSphere SDK-klient – ingen sådan värd

Om du får felet { _errorCode_: _CreateConfigKvaCustomerError_, _errorResponse_: _error getting the vsphere sdk client: Post \_https://your.vcenter.hostname/sdk\_: dial tcp: lookup your.vcenter.hostname: no such host_ } under distributionen kan distributionsdatorn inte matcha vCenter-värdnamnet till en IP-adress. Det här problemet uppstår eftersom distributionsprocessen försöker upprätta en TCP-anslutning från distributionsdatorn till vCenter-värdnamnet men misslyckas på grund av DNS-matchningsproblem. Åtgärda detta genom att kontrollera att DNS-konfigurationen på distributionsdatorn är korrekt, kontrollera att DNS-servern är online och sök efter en dns-post som saknas för vCenter-värdnamnet. Du kan testa DNS-matchningen genom att köra nslookup your.vcenter.hostname eller ping your.vcenter.hostname från distributionsdatorn. Om du har angett din vCenter-adress som värdnamn bör du överväga att använda IP-adressen direkt i stället.

Valideringsfel före distribution

Om du får en mängd pre-deployment validation of your download\upload connectivity wasn't successful olika fel, till exempel:

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

En kombination av dessa fel indikerar vanligtvis att hanteringsdatorn har förlorat anslutningen till datalagringen eller att det finns ett nätverksproblem som gör att datalagringen inte kan nås. Den här anslutningen behövs för att ladda upp OVA från hanteringsdatorn som används för att skapa den virtuella datorn i vCenter. Anslutningen mellan hanteringsdatorn och datalagringen måste återupprättas och sedan försöka distribuera Arc-resursbryggan igen.

x509-certifikatet har upphört att gälla eller är ännu inte giltigt

När du distribuerar Arc-resursbryggan kan det uppstå felet:

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

Det här felet orsakas när det finns en tidsskillnad mellan ESXi-värdar och hanteringsdatorn där distributionskommandona för Arc-resursbryggan körs. Lös problemet genom att aktivera NTP-tidssynkronisering på ESXi-värden och bekräfta att hanteringsdatorn också har synkroniserats med NTP och sedan försöka distribuera igen.

Status för Arc-resursbryggan är frånkopplad

När du körde det första Arc-aktiverade VMware-registreringsskriptet uppmanas du att ange ett vSphere-konto. Det här kontot lagras lokalt i Arc-resursbryggan som en krypterad Kubernetes-hemlighet. Kontot används för att göra det möjligt för Arc-resursbryggan att interagera med vCenter. Om statusen för Arc-resursbryggan är frånkopplad kan det bero på att vSphere-kontot som lagras lokalt i resursbryggan har upphört att gälla. Du måste uppdatera autentiseringsuppgifterna i Arc-resursbryggan och för Arc-aktiverad VMware genom att följa anvisningarna för att uppdatera vSphere-kontots autentiseringsuppgifter.

Fel vid värdkonfiguration

Om du har använt samma mall för att distribuera och ta bort Arc-resursbryggan flera gånger kan följande fel uppstå:

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

Lös problemet genom att ta bort den befintliga mallen manuellt. az arcappliance prepare Kör sedan för att ladda ned en ny mall för distribution.

Det går inte att hitta mappar

När du distribuerar Arc-resursbryggan på VMware anger du mappen där mallen och den virtuella datorn skapas. Den valda mappen måste vara en vm och mallmapptyp. Andra typer av mappar, till exempel lagringsmappar, nätverksmappar eller värd- och klustermappar, kan inte användas för distributionen av resursbryggningen.

Otillräckliga behörigheter

När du distribuerar resursbryggan på VMware vCenter kan du få ett felmeddelande om att du inte har tillräcklig behörighet. Lös problemet genom att kontrollera att användarkontot som används för att distribuera resursbryggan har alla följande behörigheter i VMware vCenter och försök sedan igen.

Datalager 

• Allokera utrymme
• Bläddra i datalager
• Filåtgärder på låg nivå

Mapp 

• Skapa mapp

vSphere-taggning

• Tilldela eller ta bort vSphere-tagg

Nätverk 

• Tilldela nätverk

Resurs

• Tilldela en virtuell dator till resurspoolen
• Migrera avstängd virtuell dator
• Migrera som drivs på en virtuell dator

Sessioner

• Verifiera session

vApp

• Tilldela resurspool
• Import

Virtuell dator

• Ändra konfiguration
  • Hämta disklån
  • Lägga till befintlig disk
  • Lägg till ny disk
  • Lägga till eller ta bort enhet
  • Avancerad konfiguration
  • Ändra antal processorer
  • Ändra minne
  • Ändra inställningar
  • Ändra resurs
  • Konfigurera managedBy
  • Visa anslutningsinställningar
  • Utöka virtuell disk
  • Ändra enhetsinställningar
  • Kompatibilitet för frågefeltolerans
  • Fråga efter ej ägda filer
  • Ladda om från sökvägen
  • Ta bort disk
  • Byt namn
  • Återställa gästinformation
  • Ange kommentar
  • Växla spårning av diskändring
  • Växla överordnad förgrening
  • Uppgradera kompatibilitet för virtuella datorer
• Redigera inventering
  • Skapa från befintlig
  • Skapa nya , och programformulär i
  • Registrera dig
  • Ta bort
  • Avregistrera
• Gäståtgärder
  • Ändring av alias för gäståtgärd
  • Ändringar av gäståtgärder
  • Körning av gäståtgärdsprogram
  • Frågor om gäståtgärder
• Interaktion
  • Ansluta enheter
  • Konsolinteraktion
  • Hantering av gästoperativsystem av VIX API
  • Installera VMware Tools
  • Stäng av
  • Ström på
  • Reset
  • Suspend
• Etableringen
  • Tillåt diskåtkomst
  • Tillåt filåtkomst
  • Tillåt skrivskyddad diskåtkomst
  • Tillåt nedladdning av virtuella datorer
  • Tillåt uppladdning av filer för virtuella datorer
  • Klona virtuell dator
  • Distribuera mallen
  • Markera som mall
  • Markera som virtuell dator
  • Anpassa gäst
• Hantering av ögonblicksbilder
  • Skapa ögonblicksbild
  • Ta bort ögonblicksbild
  • Återgå till ögonblicksbild

Nästa steg

Förstå återställningsåtgärder för resursbryggan i Azure Arc-aktiverade VMware vSphere-katastrofscenarier

Om du inte ser problemet här eller om du inte kan lösa problemet kan du prova någon av följande kanaler för support:

• Få svar från Azure-experter via Microsoft Q&A.
• Anslut med @AzureSupport, det officiella Microsoft Azure-kontot för att förbättra kundupplevelsen. Azure Support ansluter Azure-communityn till svar, support och experter.
• Öppna en Azure-supportbegäran.