Operators need NSX groups to list the city's ESXi clusters, hosts, and VMs. How does vCenter interact with NSX Manager in that architecture?
Select an answer to reveal the explanation.
Short Explanation
vCenter is the city's headcount list for compute. NSX Manager asks that compute manager who the clusters, hosts, and VMs are, then uses them in groups. vSAN and Horizon are not that inventory feed.
Full Explanation
When vCenter is registered as a compute manager, NSX Manager queries it for clusters, hosts, and virtual machines used in inventory, transport-node preparation, and grouping. vCenter is the city's headcount list for compute; NSX asks that list who the ESXi clusters, hosts, and VMs are, then uses those objects in Inventory Groups and security policy. NSX Manager does not invent VM inventory without a compute manager registration, so groups that depend on vSphere objects will stay empty if registration is missing. Each ESXi host does not post its VM list to Horizon instead of NSX for this architecture path. vSAN is the software-defined storage pillar and is not the compute manager that feeds NSX groups or transport-node inventory. Exam caveat: many dynamic Inventory Groups depend on compute-manager discovery; if registration is missing or unhealthy, tag-based or VM-based groups will not populate as operators expect for DFW sources and destinations. Operational check: in NSX Manager, verify the compute manager connection shows healthy, open Inventory then Virtual Machines to confirm city VMs appear from vCenter, and document that Horizon and vSAN were rejected as the inventory feed for NSX groups.