Risolvere i problemi del bridge di risorse di Azure Arc
Questo articolo fornisce informazioni sulla risoluzione dei problemi che possono verificarsi durante il tentativo di distribuire, usare o rimuovere il bridge di risorse di Azure Arc. Il bridge di risorse è una macchina virtuale in pacchetto che ospita un cluster Kubernetes di gestione. Per informazioni generali, vedere Panoramica del bridge di risorse di Azure Arc.
Problemi generali
Raccolta di log
In caso di problemi con il bridge di risorse di Arc, raccogliere i log per un'analisi più approfondita usando il comando az arcappliance logs
dell'interfaccia della riga di comando di Azure. Questo comando deve essere eseguito dal computer di gestione usato per distribuire il bridge di risorse di Arc. Se si usa un computer diverso, questo deve soddisfare i requisiti dei computer di gestione.
Se si verifica un problema durante la raccolta dei log, è probabile che il computer di gestione non sia in grado di raggiungere la macchina virtuale dell'appliance. Contattare l'amministratore di rete per consentire la comunicazione SSH dal computer di gestione alla macchina virtuale dell'appliance sulla porta TCP 22.
È possibile raccogliere i log del bridge di risorse di Arc passando l'indirizzo IP della macchina virtuale dell'appliance o kubeconfig nel comando dei log.
Per raccogliere i log del bridge di risorse di Arc in VMware usando l'indirizzo IP della macchina virtuale dell'appliance:
az arcappliance logs vmware --ip <appliance VM IP> --username <vSphere username> --password <vSphere password> --address <vCenter address> --out-dir <path to output directory>
Per raccogliere i log del bridge di risorse Arc in Azure Stack HCI, vedere Raccogliere i log.
Se non si è certi dell'indirizzo IP della macchina virtuale dell'appliance, è anche possibile usare kubeconfig. È possibile recuperare kubeconfig eseguendo il comando get-credentials quindi eseguire il comando dei log.
Per recuperare kubeconfig e la chiave dei log e poi raccogliere i log per VMware abilitato per Arc da un computer diverso da quello usato per distribuire il bridge di risorse di Arc per VMware abilitato per 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 connettività di download/upload non è ottimale
Se la rete è lenta, potrebbe non essere possibile scaricare correttamente l'immagine della macchina virtuale del bridge di risorse Arc causando questo errore: 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.
Come soluzione alternativa, provare a creare una macchina virtuale direttamente nel cloud privato locale e quindi eseguire lo script di distribuzione del bridge di risorse Arc da tale macchina virtuale. Questa operazione dovrebbe comportare un caricamento più rapido dell'immagine nell'archivio dati.
Timeout del contesto durante la fase ApplyingKvaImageOperator
Quando si distribuisce il bridge di risorse Arc, è possibile che venga visualizzato questo errore: 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}_ }
Questo errore si verifica in genere quando si tenta di scaricare l'immagine KVAIO
(400 MB compressi) in una rete rallentata o con connettività intermittente. Il gestore del controller KVAIO
è in attesa del completamento del download dell'immagine e si verifica un timeout.
È consigliabile verificare che la velocità di rete tra la macchina virtuale del bridge di risorse Arc e il Registro contenitori di Microsoft (mcr.microsoft.com
) sia stabile e di almeno 2 Mbps. Se la connettività e la velocità di rete sono stabili e si riceve ancora questo errore, attendere almeno 30 minuti prima di riprovare perché Registro artefatti Microsoft potrebbe stare ricevendo un volume elevato di traffico.
Timeout del contesto durante la fase WaitingForAPIServer
Quando si distribuisce il bridge di risorse Arc, è possibile che venga visualizzato questo errore: 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
Questo errore indica che il computer di distribuzione non è in grado di contattare l'indirizzo IP del piano di controllo per il bridge di risorse Arc entro il limite di tempo. Le cause comuni dell'errore sono spesso correlate alla rete, ad esempio se la comunicazione tra il computer di distribuzione e l'indirizzo IP del piano di controllo viene instradata tramite un proxy. Il traffico dal computer di distribuzione al piano di controllo e agli indirizzi IP della macchina virtuale dell'appliance non devono passare attraverso il proxy. Se il traffico viene inoltrato tramite proxy, configurare le impostazioni del proxy nella rete o nel computer di distribuzione per non instradare il traffico tra il computer di distribuzione e gli indirizzi IP del piano di controllo e della macchina virtuale dell'appliance attraverso il proxy. Un'altra causa di questo errore è che un firewall chiude l'accesso alla porta 6443 e alla porta 22 tra il computer di distribuzione e l'IP del piano di controllo o il computer di distribuzione e gli indirizzi IP della macchina virtuale dell'appliance.
403 Sito non consentito o 404 non trovato
Quando si distribuisce il bridge di risorse Arc, è possibile che venga visualizzato questo errore: { _errorCode_: _UploadError_, _errorResponse_: _{\n\_message\_: \_Pre-deployment validation of your download/upload connectivity was not successful. {\\n \\\_code\\\_: \\\_ImageProvisionError\\\_,\\n \\\_message\\\_: \\\_403 Forbidden
o { _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
Questo errore si verifica quando le immagini devono essere scaricate dai registri Microsoft nel computer di distribuzione, ma un proxy o un firewall blocca il download. Esaminare i requisiti di rete e verificare che tutti gli URL necessari siano raggiungibili. Potrebbe essere necessario aggiornare le impostazioni no proxy per assicurarsi che il traffico dal computer di distribuzione agli URL richiesti da Microsoft non attraversi un proxy.
Accesso alla cartella SSH negato
L'interfaccia della riga di comando richiede l'autorizzazione per accedere alla cartella SSH durante la distribuzione o le operazioni che comportano l'accesso ai file all'interno della cartella. Questa cartella contiene file essenziali come la chiave kubeconfig e logs per la macchina virtuale del dispositivo. Ad esempio, l'interfaccia della riga di comando deve accedere alla chiave di log archiviata nella cartella SSH per raccogliere i log dalla macchina virtuale del dispositivo.
Potrebbe essere visualizzato questo errore: 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
. Questo errore può essere dovuto a due cause comuni:
- Autorizzazioni insufficienti: l'interfaccia della riga di comando non dispone delle autorizzazioni necessarie per accedere alla cartella SSH. Assicurarsi che l'account utente che esegue l'interfaccia della riga di comando disponga delle autorizzazioni appropriate per accedere alla cartella SSH.
- Accesso simultaneo ai file: un'altra istanza dell'interfaccia della riga di comando sta usando il file nella cartella SSH. Questo accade spesso nelle postazioni di lavoro con profili condivisi. Assicurarsi che qualsiasi altra istanza dell'interfaccia della riga di comando completi o termini l'operazione prima di procedere.
Il bridge di risorse di Arc è offline
Le modifiche di rete nell'infrastruttura, nell'ambiente o nel cluster possono impedire alla macchina virtuale dell'appliance di comunicare con la risorsa di Azure corrispondente. Se non è possibile individuare la modifica, è possibile riavviare la macchina virtuale dell'appliance, raccogliere i log e inviare un ticket di supporto per ulteriori indagini.
PowerShell remoto non è supportato
Se si eseguono comandi dell'interfaccia della riga di comando az arcappliance
per il bridge di risorse Arc tramite PowerShell remoto, è possibile che venga visualizzato un errore di handshake autenticazione quando si tenta di installare il bridge di risorse in un cluster Azure Stack HCI o un altro tipo di errore.
L'uso di comandi az arcappliance
da PowerShell remoto non è attualmente supportato. In alternativa, accedere al nodo tramite Remote Desktop Protocol (RDP) o usare una sessione della console.
Non è possibile aggiornare le configurazioni del bridge di risorse
In questa versione, tutti i parametri vengono specificati al momento della creazione. Per aggiornare il bridge di risorse di Azure Arc, è necessario eliminarlo e ridistribuirlo.
Ad esempio, se è stato specificato il percorso errato o la sottoscrizione durante la distribuzione, in seguito la creazione della risorsa avrà esito negativo. Se si tenta solo di ricreare la risorsa senza ridistribuire la macchina virtuale del bridge di risorse, verrà visualizzato il blocco dello stato con WaitForHeartBeat
.
Per risolvere questo problema, eliminare l'appliance e aggiornare il file YAML dell'appliance. Successivamente, ridistribuire e creare il bridge di risorse.
Rete dell'appliance non disponibile
Se bridge di risorse Arc riscontra problemi di rete, è possibile che venga visualizzato un errore Appliance Network Unavailable
. In generale, qualsiasi problema di connettività di rete o dell'infrastruttura alla macchina virtuale dell'appliance può causare questo errore. Questo errore può anche essere visualizzato come Error while dialing dial tcp xx.xx.xxx.xx:55000: connect: no route to host
. Il problema potrebbe essere che la comunicazione dall'host alla macchina virtuale del bridge di risorse di Arc deve essere aperta sulla porta TCP 22 con l'aiuto dell'amministratore di rete. Un problema di rete temporaneo potrebbe non consentire all'host di raggiungere la macchina virtuale del bridge di risorse di Arc. Dopo aver risolto il problema di rete, è possibile ritentare l'operazione. È anche possibile verificare che la macchina virtuale dell'appliance per il bridge di risorse di Arc non sia arrestata o offline. Con Azure Stack HCI, questo errore può essere causato quando l'archiviazione host è piena.
Errore di aggiornamento del token
Quando si eseguono i comandi dell'interfaccia della riga di comando di Azure, è possibile che venga visualizzato l'errore seguente: The refresh token has expired or is invalid due to sign-in frequency checks by conditional access.
Questo errore si verifica perché quando si accede ad Azure, il token ha una durata massima. Quando viene raggiunto il limite di durata, è necessario accedere di nuovo ad Azure usando il comando az login
.
I pool di risorse dell'host predefinito non sono disponibili per la distribuzione
Quando si usa il comando az arcappliance createconfig
o il comando az arcappliance run
, un’esperienza interattiva mostra l’elenco delle entità VMware che è possibile selezionare per distribuire l’appliance virtuale. Questo elenco mostra tutti i pool di risorse creati dall'utente insieme ai pool di risorse cluster predefiniti, ma i pool di risorse host predefiniti non sono elencati. Quando l'appliance viene distribuita in un pool di risorse dell'host, non c'è una disponibilità elevata se l'hardware dell'host non riesce. È consigliabile non distribuire l'appliance in un pool di risorse dell'host.
Lo stato del bridge di risorse è Offline e lo stato del provisioning non è riuscito
Quando si distribuisce il bridge di risorse Arc, il bridge potrebbe sembrare distribuito correttamente, perché non sono stati rilevati errori durante l'esecuzione di az arcappliance deploy
o az arcappliance create
. Tuttavia, quando si visualizza il bridge nel portale di Azure, è possibile che lo stato venga visualizzato come Offline
e az arcappliance show
potrebbe mostrare provisioningState
come Failed
. Ciò si verifica quando i provider necessari non vengono registrati prima della distribuzione del bridge.
Per Azure Stack HCI versione 23H2 e successive, il bridge di risorse Arc viene distribuito automaticamente durante la distribuzione del cluster e l'installazione manuale non è più necessaria.
Se il bridge di risorse Arc è offline, provare a riavviare la macchina virtuale del bridge di risorse Arc. Se il problema persiste, contattare il supporto tecnico Microsoft.
Nota
La reinstallazione del bridge di risorse Arc in Azure Stack HCI potrebbe causare problemi con le risorse di Azure esistenti.
Per risolvere questo problema, eliminare il bridge di risorse, registrare i provider e quindi ridistribuire il bridge di risorse.
Eliminare il bridge di risorse:
az arcappliance delete <fabric> --config-file <path to appliance.yaml>
Registrare i provider:
az provider register --namespace Microsoft.ExtendedLocation –-wait az provider register --namespace Microsoft.ResourceConnector –-wait
Ridistribuire il bridge di risorse.
Nota
Per i prodotti partner, ad esempio VMware vSphere abilitato per Arc, potrebbero essere necessario registrare i propri provider obbligatori. Per informazioni su questi provider aggiuntivi, vedere la documentazione del prodotto.
Credenziali scadute nella macchina virtuale dell'appliance
Il bridge di risorse di Arc è costituito da una macchina virtuale dell'appliance distribuita nell'infrastruttura locale. La macchina virtuale dell'appliance gestisce una connessione all'endpoint di gestione dell'infrastruttura locale usando le credenziali archiviate in locale. Se queste credenziali non vengono aggiornate, il bridge di risorse non è più in grado di comunicare con l'endpoint di gestione. Ciò può causare problemi quando si tenta di aggiornare il bridge di risorse o di gestire le macchine virtuali tramite Azure.
Per risolvere questo problema, è necessario aggiornare le credenziali nella macchina virtuale dell'appliance. Per altre informazioni, vedere Aggiornare le credenziali nella macchina virtuale dell'appliance.
Il collegamento privato non supportato
Il bridge di risorse di Arc non supporta il collegamento privato. Le chiamate provenienti dalla macchina virtuale dell'appliance non devono passare attraverso la configurazione del collegamento privato. Gli indirizzi IP del collegamento privato possono entrare in conflitto con l'intervallo di pool di indirizzi IP dell'appliance, che non è configurabile nel bridge di risorse. Il bridge di risorse di Arc raggiunge gli URL necessari che non devono passare attraverso una connessione del collegamento privato. È necessario distribuire il bridge di risorse di Arc in un segmento di rete separato non correlato alla configurazione del collegamento privato.
Problemi di rete
Errore Backoff di pull dell'immagine
Quando si tenta di distribuire il bridge di risorse di Arc, è possibile che venga visualizzato un errore che contiene back-off pulling image \\\"url"\\\: FailFastPodCondition
. Questo errore si verifica quando la macchina virtuale dell'appliance non riesce a raggiungere l'URL specificato nell'errore. Per risolvere questo problema, assicurarsi che la macchina virtuale dell'appliance soddisfi i requisiti di sistema, inclusa la connettività di accesso a Internet per gli URL consentiti necessari.
Computer di gestione non in grado di raggiungere l’appliance
Quando si tenta di distribuire il bridge di risorse di Arc, è possibile che venga visualizzato un messaggio di errore simile al seguente:
{ _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_: __ }
Questo errore si verifica quando il computer di gestione non riesce a raggiungere l'IP della macchina virtuale del bridge di risorse Arc tramite SSH (porta 22) o il server API (porta 6443). Potrebbe verificarsi anche se è in corso il proxy del server API del bridge di risorse ARC. È necessario aggiungere il server API del bridge di risorse ARC alle impostazioni noproxy. Per altre informazioni, vedere Requisiti di rete del bridge di risorse di Azure Arc.
Non è possibile connettersi all'URL
Se viene visualizzato un errore che contiene Not able to connect to https://example.url.com
, rivolgersi all'amministratore di rete per assicurarsi che la rete consenta a tutti gli URL del firewall e del proxy necessari di distribuire il bridge di risorse di Arc. Per altre informazioni, vedere Requisiti di rete del bridge di risorse di Azure Arc.
Non è possibile connettersi: la convalida della connettività Internet e di rete non è riuscita
Quando si distribuisce il bridge di risorse ARC, è possibile che venga visualizzato un errore con errorCode
come PostOperationsError
e errorResponse
come codice GuestInternetConnectivityError
con un URL che specifica la porta 53 (DNS). Questo errore può essere dovuto all’impossibilità degli indirizzi IP delle macchine virtuali dell’appliance di raggiungere i server DNS, in modo che non possano risolvere l’endpoint specificato nell’errore.
Esempi di errore:
{ _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}_ }
Per risolvere l’errore, rivolgersi all’amministratore di rete per consentire agli indirizzi IP delle macchine virtuali dell’appliance di raggiungere i server DNS. Per altre informazioni, vedere Requisiti di rete del bridge di risorse di Azure Arc.
Il server Http2 ha inviato GOAWAY
Quando si tenta di distribuire il bridge di risorse Arc, è possibile che vengano visualizzati messaggi di errore simili a quelli seguenti:
"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.
Questi errori possono verificarsi quando un firewall o un proxy ha l'ispezione SSL/TLS abilitata e blocca le chiamate http2 dal computer usato per distribuire il bridge di risorse. Per verificare che questo sia il problema, eseguire il cmdlet di PowerShell seguente per richiamare la richiesta Web con http2 (richiede PowerShell versione 7 o successiva), sostituendo l'area nell'URL e api-version
(per esempio, 2019-11-01
) con i valori dell'errore:
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 il risultato è The response ended prematurely while waiting for the next frame from the server
, la chiamata http2 viene bloccata e deve essere consentita. Contattare l'amministratore di rete per disabilitare l'ispezione SSL/TLS per consentire le chiamate http2 dal computer usato e distribuire il bridge.
Nessun host di questo tipo - .local
non supportato
Quando si tenta di impostare la configurazione per il bridge di risorse di Arc, è possibile che venga visualizzato un messaggio di errore simile al seguente:
"message": "Post \"https://esx.lab.local/52c-acac707ce02c/disk-0.vmdk\": dial tcp: lookup esx.lab.local: no such host"
Ciò si verifica quando viene fornito un percorso .local
per un'impostazione di configurazione, ad esempio proxy, DNS, archivio dati o endpoint di gestione, ad esempio vCenter. La macchina virtuale dell'appliance del bridge di risorse di Arc usa il sistema operativo Linux di Azure, che non supporta .local
per impostazione predefinita. Una soluzione alternativa può essere quella di fornire l'indirizzo IP, quando possibile.
Il bridge di risorse di Azure Arc non è raggiungibile
Il bridge di risorse di Azure Arc esegue un cluster Kubernetes e il relativo piano di controllo richiede un indirizzo IP statico. L'indirizzo IP viene specificato nel file infra.yaml
. Se l'indirizzo IP viene assegnato da un server DHCP, l'indirizzo può cambiare se non è riservato. Il riavvio del bridge di risorse o della macchina virtuale di Azure Arc può attivare una modifica dell'indirizzo IP e causare errori nei servizi.
Il bridge di risorse di Arc può perdere in modo intermittente la configurazione dell'IP riservato. Questa perdita è dovuta al comportamento descritto in Perdita di indirizzi VIP quando systemd-networkd
viene riavviato. Quando l'indirizzo IP non viene assegnato alla macchina virtuale del bridge di risorse di Azure Arc, qualsiasi chiamata al server API del bridge di risorse ha esito negativo. Le operazioni di base, ad esempio la creazione di una nuova risorsa, la connessione al cloud privato da Azure o la creazione di una posizione personalizzata, non funzioneranno come previsto.
Per risolvere questo problema, riavviare la macchina virtuale del bridge di risorse: il suo indirizzo IP dovrebbe essere recuperato. Se l'indirizzo viene assegnato da un server DHCP, riservare l'indirizzo IP associato al bridge di risorse.
Il bridge di risorse di Arc potrebbe anche non essere raggiungibile a causa di un rallentamento dell'accesso al disco. Il bridge di risorse di Azure Arc usa l'albero della configurazione estesa (ETCD) di Kubernetes, che richiede una latenza di 10 ms o inferiore. Se il disco sottostante ha prestazioni ridotte, questo si riflette sulle operazioni e possono verificarsi errori.
Problemi di configurazione del proxy SSL
Assicurarsi che il server proxy nel computer di gestione consideri attendibile sia il certificato SSL per il proxy SSL che il certificato SSL dei server di download Microsoft. Per altre informazioni, vedere Configurazione del proxy SSL.
Nessun host di questo tipo: dp.kubernetesconfiguration.azure.com
Un errore che contiene dial tcp: lookup westeurope.dp.kubernetesconfiguration.azure.com: no such host
durante la distribuzione del bridge di risorse Arc indica che il piano dati di configurazione non è attualmente disponibile nell'area specificata. Il servizio potrebbe essere temporaneamente non disponibile. Attendere che il servizio sia disponibile e quindi ripetere la distribuzione.
TCP di connessione del proxy: nessun host di questo tipo per l'URL necessario del bridge di risorse di Arc
Un errore che contiene un URL obbligatorio del bridge di risorse Arc con il messaggio proxyconnect tcp: dial tcp: lookup http: no such host
indica che il DNS non è in grado di risolvere l'URL. L'errore potrebbe essere simile a questo esempio, in cui l'URL richiesto è 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}_ }
Questo errore può verificarsi se le impostazioni DNS fornite durante la distribuzione non sono corrette o si è verificato un problema con i server DNS. È possibile verificare se il server DNS è in grado di risolvere l'URL eseguendo il comando seguente dal computer di gestione o da un computer che ha accesso ai server DNS:
nslookup
> set debug
> <hostname> <DNS server IP>
Per risolvere l'errore, configurare i server DNS per risolvere tutti gli URL necessari per il bridge di risorse Arc. I server DNS devono essere forniti correttamente quando si distribuisce Arc Resource Bridge.
Errore di timeout di KVA
L'errore di timeout di KVA è un errore generico causato da una varietà di errori di configurazione della rete che coinvolgono il computer di gestione. Ad esempio, la macchina virtuale dell'appliance o l'indirizzo IP del piano di controllo possono non comunicare tra loro, con Internet o con gli URL necessari. Questo errore di comunicazione è spesso dovuto a problemi di risoluzione del DNS, impostazioni del proxy, configurazione di rete o accesso a Internet.
Per maggiore chiarezza, il computer di gestione fa riferimento al computer in cui vengono eseguiti i comandi dell'interfaccia della riga di comando di distribuzione. La macchina virtuale dell'appliance è la macchina virtuale che ospita il bridge di risorse di Arc. L'indirizzo IP del piano di controllo è l'indirizzo IP del piano di controllo per il cluster di gestione di Kubernetes nella macchina virtuale dell'appliance.
Principali cause dell'errore di timeout di KVA
- Il computer di gestione non è in grado di comunicare con l'indirizzo IP del piano di controllo e l'indirizzo IP della macchina virtuale dell'appliance.
- La macchina virtuale dell'appliance non è in grado di comunicare con il computer di gestione, l'endpoint vCenter (per VMware) o l'endpoint dell'agente cloud MOC (per Azure Stack HCI).
- La macchina virtuale dell'appliance non ha accesso a Internet.
- La macchina virtuale dell'appliance ha accesso a Internet, ma la connettività a uno o più URL necessari viene bloccata, probabilmente a causa di un proxy o di un firewall.
- La macchina virtuale dell'appliance non riesce a raggiungere un server DNS in grado di risolvere i nomi interni, ad esempio l'endpoint vCenter per vSphere o l'endpoint dell'agente cloud per Azure Stack HCI. Il server DNS deve anche essere in grado di risolvere gli indirizzi esterni, ad esempio indirizzi del servizio di Azure e nomi del registro contenitori.
- La configurazione del server proxy nel computer di gestione o nei file di configurazione del bridge di risorse di Arc non è corretta. Questo può influire sia sul computer di gestione che sulla macchina virtuale dell'appliance. Quando viene eseguito il comando
az arcappliance prepare
e il proxy host non è configurato correttamente, il computer di gestione non sarà in grado di connettersi e scaricare immagini del sistema operativo. L'accesso a Internet nella macchina virtuale dell'appliance potrebbe essere interrotto da una configurazione errata o mancante del proxy, che influisce sulla capacità della macchina virtuale di eseguire il pull delle immagini del contenitore.
Risolvere l'errore di timeout di KVA
Per risolvere l'errore, potrebbe essere necessario risolvere uno o più errori di configurazione di rete.
Il primo passaggio consiste nel raccogliere i log dall'indirizzo IP della macchina virtuale dell'appliance (non da kubeconfig, perché kubeconfig potrebbe essere vuoto se il comando di distribuzione non è stato completato). I problemi di raccolta dei log sono molto probabilmente dovuti all'impossibilità del computer di gestione di raggiungere la macchina virtuale dell'appliance.
Dopo aver raccolto i log, estrarre la cartella e aprire
kva.log
. Esaminare il log per informazioni che potrebbero aiutare a individuare la causa dell'errore di timeout KVA.Il computer di gestione deve essere in grado di comunicare con l'indirizzo IP della macchina virtuale dell'appliance e l'indirizzo IP del piano di controllo. Eseguire il ping degli indirizzi IP della macchina virtuale dell'appliance e del piano di controllo dal computer di gestione e verificare che sia presente una risposta da entrambi gli indirizzi IP.
Se si verifica il timeout di una richiesta, il computer di gestione non riesce a comunicare con gli indirizzi IP. Questo problema potrebbe essere causato da una porta chiusa, da una configurazione errata della rete o da un blocco del firewall. Contattare l'amministratore di rete per consentire la comunicazione tra il computer di gestione e gli indirizzi IP della macchina virtuale dell'appliance e del piano di controllo.
Gli indirizzi IP della macchina virtuale dell'appliance e del piano di controllo devono essere in grado di comunicare con il computer di gestione e l'endpoint del server vCenter (per VMware) o l'endpoint dell'agente cloud MOC (per HCI). Contattare l'amministratore di rete per assicurarsi che la rete sia configurata per consentire questa operazione. Potrebbe essere necessario aggiungere una regola del firewall per aprire la porta 443 dall'indirizzo IP della macchina virtuale dell'appliance e dall'indirizzo IP del piano di controllo verso il server vCenter o per aprire la porta 65000 e 55000 per l'agente cloud MOC di Azure Stack HCI. Esaminare irequisiti di rete per Azure Stack HCI e VMware per il bridge di risorse di Arc.
L'indirizzo IP della macchina virtuale dell'appliance e l'indirizzo IP del piano di controllo richiedono l'accesso a Internet per questi URL necessari. Azure Stack HCI richiede URL aggiuntivi. Contattare l'amministratore di rete per assicurarsi che gli indirizzi IP possano accedere agli URL necessari.
In un ambiente non proxy, il computer di gestione deve avere una risoluzione DNS esterna e interna. Il computer di gestione deve essere in grado di raggiungere un server DNS in grado di risolvere i nomi interni, ad esempio l'endpoint del server vCenter per vSphere o l'endpoint dell'agente cloud per Azure Stack HCI. Il server DNS deve anche essere in grado di risolvere gli indirizzi esterni, ad esempio gli URL di Azure e gli URL di download dell'immagini del sistema operativo. Contattare l'amministratore di sistema per assicurarsi che il computer di gestione abbia una risoluzione DNS interna ed esterna. In un ambiente proxy, la risoluzione DNS nel server proxy deve risolvere gli endpoint interni e gli indirizzi esterni necessari.
Per testare la risoluzione DNS per un indirizzo interno dal computer di gestione in uno scenario non proxy, aprire il prompt dei comandi ed eseguire
nslookup <vCenter endpoint or HCI MOC cloud agent IP>
. Si dovrebbe ricevere una risposta se il computer di gestione ha una risoluzione DNS interna in uno scenario non proxy.
La macchina virtuale dell'appliance deve essere in grado di raggiungere un server DNS in grado di risolvere i nomi interni, ad esempio l'endpoint del server vCenter per vSphere o l'endpoint dell'agente cloud per Azure Stack HCI. Il server DNS deve anche essere in grado di risolvere gli indirizzi esterni/interni, ad esempio gli indirizzi del servizio di Azure e i nomi del registro contenitori per il download delle immagini del contenitore del bridge di risorse di Arc dal cloud.
Verificare che l'indirizzo IP del server DNS usato per creare i file di configurazione abbia una risoluzione degli indirizzi interna ed esterna. Se non è presente, eliminare l'appliance, ricreare i file di configurazione del bridge di risorse di Arc con le impostazioni del server DNS corrette e quindi distribuire il bridge di risorse di Arc usando i nuovi file di configurazione.
Spostare la posizione del bridge di risorse di Arc
Lo spostamento delle risorse del bridge di risorse di Arc non è attualmente supportato. Eliminare invece il bridge di risorse Arc e ridistribuirlo nella posizione desiderata.
Problemi relativi alle macchine virtuali abilitate per Azure Arc in Azure Stack HCI
Per informazioni generali sulla risoluzione dei problemi relativi alle macchine virtuali abilitate per Azure Arc in Azure Stack HCI, vedere Risolvere i problemi relativi alle macchine virtuali abilitate per Azure Arc.
Se si esegue Azure Stack HCI versione 23H2 o successiva e il bridge di risorse Arc è offline, non tentare di reinstallare o eliminare il bridge di risorse Arc. Provare invece a riavviare la macchina virtuale del bridge di risorse Arc per riportarla online. Se il problema persiste, contattare il Supporto tecnico Microsoft.
Azione non riuscita: nessun host di questo tipo
Quando si distribuisce il bridge di risorse ARC, se viene visualizzato un errore con errorCode
come PostOperationsError
, errorResponse
come codice GuestInternetConnectivityError
e no such host
, gli IP delle macchine virtuali dell’appliance potrebbero non essere in grado di raggiungere l’endpoint specificato nell’errore.
Esempio di errore:
{ _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
Nell’esempio, gli indirizzi IP delle macchine virtuali dell’appliance non sono in grado di accedere a http://aszhcitest01.company.org:55000
, ovvero l’endpoint MOC. Collaborare con l’amministratore di rete per assicurarsi che il server DNS sia in grado di risolvere gli URL necessari.
Per testare la connettività al server DNS:
ping <dns-server.com>
Per verificare se il server DNS è in grado di risolvere un indirizzo, eseguire questo comando da un computer in grado di raggiungere i server DNS:
Resolve-DnsName -Name "http://aszhcitest01.company.org:55000" -Server "<dns-server.com>"
Problemi del server VMware vCenter abilitato per Azure Arc
errorResponse: error getting the vsphere sdk client
Gli errori con errorCode: CreateConfigKvaCustomerError
e errorResponse: error getting the vsphere sdk client
si verificano quando il computer di distribuzione sta tentando di stabilire una connessione TCP all'indirizzo del server vCenter ma riscontra un problema. Ciò può verificarsi quando l'indirizzo vCenter non è corretto (errore 403 o 404) o perché una configurazione di rete/proxy/firewall lo blocca (tentativo di connessione non riuscito).
Se si immette l'indirizzo del server vCenter come nome host e si riceve l'errore no such host
, il computer di distribuzione non è in grado di risolvere il nome host del server vCenter tramite il DNS del client. È possibile che venga visualizzato un errore se il computer di distribuzione è in grado di risolvere il nome host del server vCenter, ma il computer di distribuzione non riesce a raggiungere l'indirizzo IP ricevuto dal DNS. È anche possibile che questo errore sia visualizzato se l'endpoint restituito dal DNS non è l'indirizzo del server vCenter o se il traffico è stato intercettato dal proxy. Se il computer di distribuzione è in grado di comunicare con l'indirizzo vCenter, verificare che il nome utente e la password siano corretti.
Client SDK di vSphere: tentativo di connessione non riuscito
Se viene visualizzato un errore durante la distribuzione, che indica: 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._ }
, significa che il computer di gestione non è in grado di comunicare con il server vCenter.
Assicurarsi che il computer di gestione soddisfi i requisiti del computer di gestione e che non sia presente un firewall o un proxy che blocca la comunicazione.
Client SDK di vSphere: 403 Accesso negato o 404 non trovato
Gli errori che contengono errorCode_: _CreateConfigKvaCustomerError_, _errorResponse_: _error getting the vsphere sdk client: POST \_/sdk\_: 403 Forbidden
o 404 not found
durante la distribuzione del bridge di risorse Arc sono probabilmente dovuti a un indirizzo vCenter non corretto. Questo indirizzo viene fornito durante la creazione del file di configurazione, quando viene richiesto di immettere l'indirizzo vCenter come nome host o indirizzo IP.
Esistono diversi modi per trovare l'indirizzo del server vCenter. Un'opzione consiste nell'accedere al client vSphere tramite l'interfaccia Web. Il nome host del server vCenter o l'indirizzo IP è in genere quello usato nel browser per accedere al client vSphere. Se è già stato effettuato l'accesso, è possibile esaminare la barra degli indirizzi del browser; l'URL usato per accedere a vSphere è il nome host o l'indirizzo IP del server vCenter. Verificare l'indirizzo vCenter e quindi riprovare a eseguire la distribuzione.
Client SDK di vSphere: nessun host di questo tipo
L'errore { _errorCode_: _CreateConfigKvaCustomerError_, _errorResponse_: _error getting the vsphere sdk client: Post \_https://your.vcenter.hostname/sdk\_: dial tcp: lookup your.vcenter.hostname: no such host_ }
può verificarsi durante la distribuzione, quando il computer di distribuzione non riesce a risolvere il nome host del server vCenter in un indirizzo IP. Questo problema si verifica perché il processo di distribuzione tenta di stabilire una connessione TCP dal computer di distribuzione al nome host del server vCenter ma la connessione non riesce a causa di problemi di risoluzione del DNS.
Per risolvere questo problema, verificare che la configurazione del DNS nel computer di distribuzione sia corretta, verificare che il server DNS sia online e verificare che non manchi una voce DNS per il nome host del server vCenter. È possibile testare la risoluzione DNS eseguendo nslookup your.vcenter.hostname
o ping your.vcenter.hostname
nel computer di distribuzione. Se l'indirizzo del server vCenter è stato specificato come nome host, è consigliabile usare direttamente l'indirizzo IP.
Errori di convalida pre-distribuzione
Quando si distribuisce il bridge di risorse Arc è possibile che vengano visualizzati diversi errori pre-deployment validation of your download\upload connectivity wasn't successful
, ad esempio:
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
Una combinazione di questi errori indica in genere che il computer di gestione ha perso la connessione all'archivio dati o che si è verificato un problema di rete che causa l'irraggiungibilità dell'archivio dati. Questa connessione è necessaria per caricare l'OVA dal computer di gestione usato per compilare la macchina virtuale dell'appliance nel server vCenter.
Per risolvere il problema, ristabilire la connessione tra il computer di gestione e l'archivio dati, quindi provare di nuovo a distribuire il bridge di risorse Arc.
x509: il certificato è scaduto o non è ancora valido
Quando si distribuisce il bridge di risorse di Arc, è possibile che venga visualizzato l'errore:
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
Questo errore si verifica quando c'è una differenza di clock/ora tra gli host ESXi e il computer di gestione in cui vengono eseguiti i comandi di distribuzione per il bridge di risorse Arc. Per risolvere questo problema, attivare la sincronizzazione dell'ora NTP negli host ESXi, verificare che il computer di gestione sia sincronizzato anche con NTP, quindi ritentare la distribuzione.
Risoluzione in più reti
Durante la distribuzione o l’aggiornamento del bridge di risorse ARC, è possibile che si verifichi un errore simile al seguente:
{ "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 }\"" }
Questo errore si verifica quando il segmento di rete vSphere esegue una risoluzione in più reti a causa di più segmenti di rete vSphere con lo stesso nome specificato nell’errore. Per risolvere questo errore, è possibile modificare il nome di rete duplicato in vCenter, non la rete con la macchina virtuale dell’appliance, o distribuire il bridge di risorse ARC in una rete diversa.
Lo stato del bridge di risorse di Arc è disconnesso
Quando si esegue lo script iniziale di onboarding VMware abilitato per Arc, viene richiesto di fornire un account vSphere. Questo account viene archiviato in locale all'interno del bridge di risorse di Arc come segreto crittografato di Kubernetes. L'account viene usato per consentire al bridge di risorse di Arc di interagire con vCenter.
Se l'account vSphere archiviato localmente all'interno del bridge di risorse scade, lo stato del bridge di risorse Arc può essere disconnesso. È necessario aggiornare le credenziali all'interno del bridge di risorse Arc e per VMware abilitato per Arc seguendo le istruzioni per l'aggiornamento delle credenziali dell'account vSphere.
Errore durante la configurazione dell'host
Se si usa lo stesso modello per distribuire ed eliminare più volte il bridge di risorse Arc, è possibile che venga visualizzato l'errore seguente:
Appliance cluster deployment failed with error: Error: An error occurred during host configuration
Per risolvere questo problema, eliminare manualmente il modello esistente. Eseguire quindi az arcappliance prepare
per scaricare un nuovo modello per la distribuzione.
Impossibile trovare le cartelle
Quando si distribuisce il bridge di risorse Arc in VMware, specificare la cartella in cui vengono creati il modello e la macchina virtuale. La cartella selezionata deve essere una macchina virtuale e un tipo di cartella modello. Non è possibile usare altri tipi di cartella, ad esempio cartelle di archiviazione, cartelle di rete o cartelle host e cluster, per la distribuzione del bridge di risorse.
Non è possibile recuperare la risorsa: la risorsa non è stata trovata o non esiste
Quando si distribuisce Arc Resource Bridge, si specifica dove viene distribuita la macchina virtuale dell'appliance. La VM dell'appliance non può essere spostata da tale percorso. Se la macchina virtuale dell'appliance sposta la posizione e si tenta di eseguire l'aggiornamento, potrebbero verificarsi errori simili al seguente:
{\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 }"
Per correggere questi errori, usare una di queste opzioni:
- Spostare nuovamente la macchina virtuale dell’appliance nella sua posizione originale e assicurarsi che le credenziali del controllo degli accessi in base al ruolo vengano aggiornate per la modifica della posizione.
- Creare una risorsa con lo stesso nome, quindi spostare il bridge di risorse ARC in tale nuova risorsa.
- Se si usa VMware abilitato per ARC, eseguire lo script del ripristino di emergenza VMware abilitato per ARC. Lo script eliminerà l'appliance, distribuirà una nuova appliance e riconnetterà l'appliance con il percorso personalizzato distribuito in precedenza, l'estensione del cluster e le VM abilitate per Arc.
- Eliminare e ridistribuire il bridge di risorse Arc.
Privilegi insufficienti
Quando si distribuisce o si aggiorna il bridge di risorse in VMware vCenter, è possibile che venga visualizzato un errore simile al seguente:
{ ""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 }
Quando si distribuisce Arc Resource Bridge, si forniscono le credenziali di vCenter. Il bridge di risorse ARC archivia localmente queste credenziali di vCenter per interagire con vCenter. Per risolvere il problema relativo ai privilegi mancanti, l’account vCenter usato dal bridge di risorse richiede i privilegi seguenti in VMware vCenter:
Datastore (Archivio dati):
- Allocare spazio
- Browse Datastore (Sfoglia archivio dati)
- Operazioni di file di basso livello
Cartella:
- Creare la cartella
Assegnazione di tag a vSphere:
- Assegnare o annullare l'assegnazione di un tag a vSphere
Rete:
- Assegnare la rete
Resource (Risorsa):
- Assegnare una macchina virtuale al pool di risorse
- Eseguire la migrazione della macchina virtuale inattiva
- Eseguire la migrazione della macchina virtuale attiva
Sessioni:
- Convalidare la sessione
vApp:
- Assegnare un pool di risorse
- Import
Virtual machine (Macchina virtuale):
- Cambiare la configurazione
- Acquisire il lease del disco
- Aggiungere un disco esistente
- Aggiungere un nuovo disco
- Aggiungere o rimuovere un dispositivo
- Configurazione avanzata
- Modificare il numero di CPU
- Cambiare la memoria
- Modificare le impostazioni
- Cambiare la risorsa
- Configurare managedBy
- Visualizzare la impostazioni di connessione
- Estendere il disco virtuale
- Modificare le impostazioni del dispositivo
- Eseguire query sulla compatibilità della tolleranza di errore
- Eseguire query sui file senza proprietario
- Ricaricare dal percorso
- Rimuovere il disco
- Rinomina
- Reimpostare le informazioni guest
- Impostare l'annotazione
- Attivare/disattivare il rilevamento delle modifiche del disco
- Attivare/disattivare il fork padre
- Aggiornare la compatibilità delle macchine virtuali
- Modificare l'inventario
- Creare da esistente
- Crea nuovo
- Registrazione
- Rimuovi
- Unregister
- Operazioni guest
- Modifica dell'alias dell'operazione guest
- Modifiche all'operazione guest
- Esecuzione del programma dell'operazione guest
- Query sulle operazioni guest
- Interazione
- Connettere dispositivi
- Interazione della console
- Gestione del sistema operativo guest tramite l'API VIX
- Installare gli strumenti VMware
- Spegnere
- Accendere
- Reset
- Sospendi
- Provisioning
- Consentire l'accesso al disco
- Consentire l'accesso ai file
- Consentire l'accesso al disco in sola lettura
- Consentire il download della macchina virtuale
- Consentire il caricamento dei file della macchina virtuale
- Clonare la macchina virtuale
- Distribuire un modello
- Contrassegnare come modello
- Contrassegnare come macchina virtuale
- Personalizzare guest
- Gestione degli snapshot
- Crea snapshot
- Rimuovere uno snapshot
- Ripristinare uno snapshot
Passaggi successivi
Se il problema riscontrato non è presente qui o se non si riesce a risolverlo, visitare uno dei canali seguenti per ottenere assistenza:
- Ottenere risposte dagli esperti di Azure tramite Microsoft Q&A.
- Connettersi con @AzureSupport, l'account ufficiale Microsoft Azure per migliorare l'esperienza del cliente. Il supporto di Azure mette in contatto la community di Azure con le risorse giuste: risposte, supporto ed esperti.
- Creare una richiesta di supporto tecnico di Azure.