![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(137.6, 48%, 23%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDW%3C/text%3E%3C/svg%3E)
Azure Arc
A Microsoft cloud service that enables deployment of Azure services across hybrid and multicloud environments.
Hello Daniel Wilkins,
Greetings! Thanks for raising this question in the Q&A forum.
Both of the issues you ran into match documented behavior for Arc resource bridge on VMware, and the workarounds you landed on are the correct ones.
Issue 1 — datastore reference after moving off the original vVol datastore
This is a known limitation rather than a bug in the upgrade logic itself. Arc resource bridge tracks the appliance VM's original deployment path (datastore, resource pool, folder) internally, and Microsoft's own troubleshooting documentation confirms that editing the config YAML file or manually relocating the VM in vCenter does not update these internal references, which is exactly what you hit: the upgrade got further after your YAML edit but then failed again referencing the old, deleted vVol datastore. The appliance VM effectively can't be moved from its original location path; if any component in that path changes, the appliance loses its Azure connection, and the only supported path forward at that point is what you did, deploying a new resource bridge rather than trying to force the existing one to recognize the new path. For future moves, plan to redeploy the appliance rather than relocate it or hand-edit the YAML.
Issue 2 — DNS resolution failure for the vCenter FQDN during the 1.8.0 upgrade
This also matches two documented causes. First, Microsoft's troubleshooting guide notes that the appliance VM must be able to reach a DNS server that resolves internal names such as the vCenter endpoint, and that this must work independently of whatever's configured in your YAML at deploy time, since the upgrade process stages a new appliance VM and control plane that need working DNS resolution during that staging window. Second, if your vCenter FQDN uses a .local suffix, there's a separate documented issue: the appliance VM runs Azure Linux OS, which does not resolve .local domains by default (that suffix is reserved for multicast DNS on most Linux distributions), and the documented workaround is exactly what you did, supplying the IP address instead of the FQDN. The 10.96.0.10 address you saw is very likely the internal Kubernetes cluster DNS service IP that the resource bridge's own control plane uses, rather than a value read directly from your YAML, which explains why editing the YAML's DNS entry didn't change what you saw in the error.
Where to report this so it gets tracked as a bug
Since you've already worked around both issues, if you'd still like Microsoft to look at these as potential product gaps (particularly the datastore reference not updating from a YAML edit), the best path is either:
- Open a Support case against Azure Arc so it gets logged against the resource bridge product group with your appliance's diagnostic logs attached, or
- File an issue against the Azure/ArcResourceBridge GitHub repository, which Microsoft uses to track resource bridge release notes and known issues.
If this answer helps you kindly accept the answer which will help others who have similar questions.
Best Regards,
Jerald Felix.