After an AHV VLAN and bond change, Prism Central reports that cluster services cannot resolve hostnames. Other LCM and health checks pass, and VMs on the new network can ping IP addresses. Which action should the administrator perform first to isolate the issue?
Select an answer to reveal the explanation.
Short Explanation
Think of hostname resolution like a phone book behind the firewall: if the CVMs can't reach DNS, everything looks broken even when IPs work. You check DNS reachability from the CVMs first, because services run there and name lookups depend on it. Don't chase Flow or bonds until you've proven the DNS path.
Full Explanation
Hostname resolution failures after an AHV VLAN or bond change usually separate into two paths: whether IP transport is up, and whether the cluster control services can reach the configured DNS resolvers. CVM-hosted services depend on DNS for Prism, cluster identity, and many health or lifecycle operations, so a CVM-level reachability test confirms the exact path used by those services. A successful ping from workloads to IP addresses does not prove that CVMs can send UDP or TCP queries to DNS. Flow network security policy changes can block selected application traffic, but they are not the first place to look when cluster-wide service name resolution fails while IP connectivity remains. Bridge and bond validation matters after physical or logical network changes, yet if the network already carries IP traffic and other health checks pass, the failing component is more likely resolver reachability than link state. Restarting DNS-related services on management nodes is premature without evidence of a local daemon failure and can mask a routing, VLAN, firewall, or resolver issue. Exam caveat: treat hostname resolution as a control-plane dependency, not a VM networking symptom. Operational check: from a CVM shell, query the configured DNS server IP with a DNS lookup tool and confirm a response before changing network or service settings.