Azure Stack HCI 24H2 Deployment error dial tcp: lookup clustername.domain: i/o timeout. Arc Resource Bridge network and internet connectivity validation failed:

Question

Azure Stack HCI 24H2 Deployment error dial tcp: lookup clustername.domain: i/o timeout. Arc Resource Bridge network and internet connectivity validation failed:

Rozario, Peter 25

PostOperationsError", "errorResponse": "{\n"message": "{\n \"code\": \"GuestInternetConnectivityError\",\n \"message\": \"Name: cloud-agent-connectivity-test. Message: Not able to connect to <personal information>Error returned: action failed after 5 attempts: Get \\\"http://clustername.domain:55000\\\": dial tcp: lookup cluster.inside.domain: i/o timeout. Arc Resource Bridge network and internet connectivity validation failed: cloud-agent-connectivity-test. 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. There is no proxy and firewall between host machine and the appliance. The appliance is running on the host machine and Test-Netconnection URL -port 55000 from the host is true. But still while deployment we are facing this error again and again. We are not able to login to the appliance VM to troubleshoot this timeout issue. Please help!

Vinodh247 40,031 Reputation points MVP Volunteer Moderator

2025-11-23T15:32:07.7566667+00:00
This error is almost always caused by a DNS or network reachability mismatch between the appliance VM’s actual network namespace and the host’s network assumptions. Even if the host can reach clustername.domain:55000, the appliance VM often cannot, especially during early Arc Resource Bridge bootstrap.

Appliance VM usually uses its own virtual NIC and its own DNS servers, separate from the host. If the DNS servers in the deployment JSON or ARC bridge config are wrong, the VM fails to resolve clustername.domain.

The appliance VM cannot resolve the cluster FQDN, so it keeps retrying the HTTP call and times out.

Host-level Test-NetConnection does not prove anything because the VM’s network stack is isolated.

In 24H2, most failures come from one of these: • Incorrect DNS servers passed during deployment • Missing forward lookup zone for the cluster name • Appliance VM blocked from resolving internal names due to upstream DNS recursion rules • Wrong default gateway or missing static route inside the appliance VM network

You cannot log in to the appliance VM, but you can validate the deployment parameters: • Make sure the DNS server list is reachable from the appliance subnet • Ensure the cluster FQDN resolves via the same DNS servers • Ensure the appliance VM’s subnet has a working gateway • Ensure no NSG, vSwitch ACL, or vLAN isolation is blocking internal DNS responses

Add the cluster FQDN and host A records to the DNS zone explicitly • Explicitly set DNS servers again in the deployment JSON (do not rely on automatic detection) • Use IP instead of FQDN during initial validation to confirm it is a DNS-only issue • Recreate the appliance with a clean vSwitch and validated DNS path

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.

2 answers

Your answer

Vinodh247 40,031 Reputation points MVP Volunteer Moderator

2025-11-23T15:32:07.7566667+00:00

This error is almost always caused by a DNS or network reachability mismatch between the appliance VM’s actual network namespace and the host’s network assumptions. Even if the host can reach clustername.domain:55000, the appliance VM often cannot, especially during early Arc Resource Bridge bootstrap.

Appliance VM usually uses its own virtual NIC and its own DNS servers, separate from the host. If the DNS servers in the deployment JSON or ARC bridge config are wrong, the VM fails to resolve clustername.domain.

The appliance VM cannot resolve the cluster FQDN, so it keeps retrying the HTTP call and times out.

Host-level Test-NetConnection does not prove anything because the VM’s network stack is isolated.

In 24H2, most failures come from one of these: • Incorrect DNS servers passed during deployment • Missing forward lookup zone for the cluster name • Appliance VM blocked from resolving internal names due to upstream DNS recursion rules • Wrong default gateway or missing static route inside the appliance VM network

You cannot log in to the appliance VM, but you can validate the deployment parameters: • Make sure the DNS server list is reachable from the appliance subnet • Ensure the cluster FQDN resolves via the same DNS servers • Ensure the appliance VM’s subnet has a working gateway • Ensure no NSG, vSwitch ACL, or vLAN isolation is blocking internal DNS responses

Add the cluster FQDN and host A records to the DNS zone explicitly • Explicitly set DNS servers again in the deployment JSON (do not rely on automatic detection) • Use IP instead of FQDN during initial validation to confirm it is a DNS-only issue • Recreate the appliance with a clean vSwitch and validated DNS path

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.

Answer 1

Hello Vinodh247,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that you are having Azure Stack HCI 24H2 Deployment error dial tcp: lookup clustername.domain: i/o timeout, and Arc Resource Bridge network and internet connectivity validation failed.

The first step in resolving this Azure Stack HCI 24H2 deployment error is to enable access to the appliance VM for proper diagnostics. Since the error originates from DNS resolution within the appliance, host-level tests like Test-NetConnection are insufficient. Use the Serial Console or Emergency Console to gain access to the VM environment. - https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/windows/serial-console-overview and https://learn.microsoft.com/en-us/cli/azure/serial-console?view=azure-cli-latest provide more details. This access allows you to inspect network settings directly inside the VM, which is critical for troubleshooting connectivity issues.

Once inside the appliance VM, validate its DNS and network configuration. Run commands such as ipconfig /all to confirm DNS servers and gateway settings, and use nslookup clustername.domain <DNS_IP> to verify that the cluster FQDN resolves correctly. Additionally, test connectivity to the cluster using Test-NetConnection clustername.domain -Port 55000. If these checks fail, the issue likely lies in incorrect DNS server assignment or missing A records. Ensure that the DNS servers specified in your deployment template are reachable from the appliance subnet and that the cluster FQDN exists in the DNS zone.

The next step is to review and explicitly configure DNS settings in your deployment JSON or ARM template. This prevents reliance on defaults that may not apply in your environment. For example, include the following snippet in your deployment configuration:

"networkProfile": {

"dnsServers": ["10.0.0.5", "10.0.0.6"]

}

This ensures the appliance uses the correct DNS servers during deployment. Refer to Microsoft’s schema documentation for network profiles: Azure Resource Manager Templates.

After DNS validation, confirm that the appliance VM has a valid default gateway and routing configuration. Misconfigured gateways or blocked routes can prevent DNS queries from reaching the server. Check subnet assignments and verify that NSGs or vSwitch ACLs are not restricting traffic between the appliance and DNS servers. If necessary, temporarily relax firewall rules or adjust routing tables to allow connectivity. Microsoft’s networking best practices for Azure Stack HCI can be found here: https://learn.microsoft.com/en-za/azure-stack/hci/deploy/network-atc and https://learn.microsoft.com/en-ca/azure-stack/hci/concepts/plan-software-defined-networking-infrastructure

If the deployment still fails after these adjustments, redeploy with verbose logging enabled using PowerShell or CLI by adding -Verbose or -Debug flags. This captures detailed network-phase logs for further analysis. Additionally, consider opening a support case with Microsoft and referencing the GitHub supportability guide for Azure Stack HCI: Azure Stack HCI Supportability. This ensures that unresolved issues are escalated with full diagnostic context.

Finally, avoid assumptions based on host-level connectivity tests. Appliance-level validation is mandatory because the VM operates in an isolated network namespace.

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

Answer 2

Rozario, Peter 25

Hi Sina, We are deploying Azure local OS 24h2 and the Azure Resource bridge appliance is created automatically in the deployment process. The appliance VM is a kubernetes cluster running on Azure linux. We cannot see this VM in the Azure portal to take access via serial console. We are not able to login to this appliance VM to troubleshoot the DNS network issue. We cab use az arcappliance validate hci but that shows the network test passed. But still while deployment its getting stuck and not able to complete. We don't have any dynamic DNS. And our DNS is able to resolve all domains. Please suggest what else we can do here.

Sina Salam 26,661 Reputation points Volunteer Moderator

2025-11-24T14:33:47.4566667+00:00
Hi Rozario, Peter,

Thanks for your feedback.

The reason you cannot see it, the Azure Resource Bridge appliance is deployed as a Kubernetes cluster running on Azure Linux, but it’s managed by Azure Arc and Azure Stack HCI, not as a regular VM in the Azure portal. This means you won’t see it in the Azure portal VM list or have direct serial console access like a normal VM.

About your Issues:

Deployment is stuck even though az arcappliance validate hci reports network test passed.

You have no dynamic DNS, but your DNS resolves all domains.

The appliance needs stable DNS resolution for Azure endpoints and proper outbound connectivity for Kubernetes pods.

Run these PowerShell checks from the HCI host (not the appliance):

nslookup`` management.azure.com

nslookup`` login.microsoftonline.com

nslookup`` packages.microsoft.com

If any fail, add static DNS entries or ensure your DNS forwarders can resolve public Azure domains

Secondly, if you have no dynamic DNS, ensure:

Appliance hostname is resolvable by adding it to your DNS manually.

Or add entries in /etc/hosts inside the appliance for critical endpoints.

Lastly, On the HCI host using PowerShell command Get``-AzStackHciDeploymentLog

Look for errors related to networking or DNS. Most common root causes are:

Missing outbound connectivity to Azure endpoints.

DNS resolving internally but not for external Azure services.

Proxy/firewall blocking Kubernetes pods from pulling images.

Success.

Share via

Azure Stack HCI 24H2 Deployment error dial tcp: lookup clustername.domain: i/o timeout. Arc Resource Bridge network and internet connectivity validation failed:

2 answers

Your answer