To provision machines in a cross vCenter NSX environment when using NSX universal objects, you must provision to a vCenter in which the NSX compute manager has the primary role.

In a cross vCenter NSX environment, you can have multiple vCenter servers, each of which must be paired with its own NSX manager. One NSX manager is assigned the role of primary NSX manager, and the others are assigned the role of secondary NSX manager.

The primary NSX manager can create universal objects, such as universal logical switches. These objects are synchronized to the secondary NSX managers. You can view these objects from the secondary NSX managers, but you cannot edit them there. You must use the primary NSX manager to manage universal objects. The primary NSX manager can be used to configure any of the secondary NSX managers in the environment.

For more information about the NSX cross-vCenter environment, see Overview of Cross-vCenter Networking and Security in the NSX Administration Guide in the NSX product documentation.

For a vSphere (vCenter) endpoint that is associated to the NSX endpoint of a primary NSX manager, vRealize Automation supports NSX local objects, such as local logical switches, local edge gateways, and local load balancers, security groups, and security tags. It also supports NAT one-to-one and one-to-many networks with universal transport zone, routed networks with universal transport zone and universal distributed logical routers (DLRs), and a load balancer with any type of network.

vRealize Automation does not support NSX existing and on-demand universal security groups or tags.

To provision local on-demand networks as the primary NSX manager, use a vCenter-specific local transport zone. You can configure vRealize Automation reservations to use the local transport zone and virtual wires for deployments in that local vCenter.

If you connect a vSphere (vCenter) endpoint to a corresponding secondary NSX manager endpoint, you can only provision and use local objects.

You can only associate an NSX endpoint to one vSphere endpoint. This association constraint means that you cannot provision a universal on-demand network and attach it to vSphere machines that are provisioned on different vCenters.

vRealize Automation can consume an NSX universal logical switch as an external network. If a universal switch exists, it is data-collected and then attached to or consumed by each machine in the deployment.

  • Provisioning an on-demand network to a universal transport zone can create a new universal logical switch.

  • Provisioning an on-demand network to a universal transport zone on the primary NSX manager creates a universal logical switch.

  • Provisioning an on-demand network to a universal transport zone on a secondary NSX manager fails, as NSX cannot create a universal logical switch on a secondary NSX manager.

See the VMware Knowledge Base article Deployment of vRealize Automation blueprints with NSX objects fail (2147240) at for more information about NSX universal objects.