Improve the operational efficiency with multiple NSX Managers managing a single vCenter Server. Admins can manage different clusters in the same vCenter Server by using different NSX Managers.

Starting with NSX-T Data Center 3.2.2, you can enable support of multiple NSX Managers managing a single vCenter Server.

For more details on how the Multi NSX flag is enabled in vCenter Server, see Add a Compute Manager.

When configuring a compute manager, enable the Multi NSX flag.

After you prepare a cluster or a host as a transport node, NSX-T appends the cluster, hosts and DVS extensions with a key that indicates these objects are managed by a certain vCenter Server.

NSX appends cluster, hosts and DVS extensions with the vCenter Server key that manages these objects.

NSX-T changes the old extension ( to a custom extension key (<computemanager-id>), where the <computemanager-id> is the vCenter Server ID in NSX-T.

On the Hosts → Clusters page, NSX-T discovers all clusters managed by the same vCenter Server, where a different NSX Manager can manage its own clusters. If another NSX Manager owns a cluster, you cannot prepare or edit it. These clusters are in read-only mode.

Clusters owned by a different NSX Manager are available in read-only mode. Such clusters can only be managed by the NSX Manager that owns it.

Switching between Single NSX-T Mode to Mulitple NSX-T Mode

When you enable Multi NSX flag on the vCenter Server, NSX-T appends its managed objects of NSX-T (cluster, host, Distributed Virtual Switch switch) with the custom extension (<computemanager-id>).

In Mulitple NSX-T Mode, all NSX Managers registered to the same vCenter Server must have Multi NSX flag enabled. You cannot configure Multi NSX enabled for NSX Manager-1 and deactivate on NSX Manager-2.

Host Movement Scenarios

Scenario Action/Result
  • Prepare Cluster-1 using TNP of NSX-T-1.
  • Prepare Cluster-2 using TNP of NSX-T-2.

  • In vCenter Server UI, move one host from Cluster-1 to Cluster-2.
    • On the host that is moved to cluster-2, NSX-T-1 uninstalls NSX-T vibs from the host. NSX Manager-1 removes its ownership from the host. Only after NSX Manager-1 removes its ownership and the Lock icon disappears from the Host Transport Node page does NSX Manager-2 start installation on the host.
  • NSX-T is uninstalled on the host that is moved to Cluster-2. After the host is moved, the host will be prepared by the TNP of NSX-T-2, which is attached to Cluster-2.
  • If there are any uninstallation-related errors, check the Host → Clusters page. Click Resolve to fix issues and proceed.
  • Host-1 is prepared individually as a transport node in any of the following environments where:
    • It is not part of a vCenter Server.
    • It is part of a vCenter Server but TNP is detached from the cluster.
    • It is part of the datacenter in a vCenter Server.
  • Before moving Host-1 to a NSX-T-managed cluster do the following:
    • Uninstall NSX-T from Host-1 transport node.
    • Add Host-1 to a vCenter Server-managed cluster.
    • TNP is automatically applied to Host-1 and NSX-T is installed.

Limitations of Multiple NSX Managers Managing a Single vCenter Server Setup

  • If NSX Manager-1 has stamped its ownership on managed objects (cluster, host, or Distributed Virtual Switch (DVS)), these objects cannot be owned by NSX Manager-2 until the first manager gives up the ownership or ownership is forcefully passed on to another manager. See <xref-topic>.
  • Even though you can enable Multi NSX on a vCenter Server, where the version is NSX-T 3.2.2, do not register the same vCenter Server with NSX-T 3.2.1 or any previous release.
  • Ensure the desired user roles have permissions to update Global.ManageCustomFields in vCenter Server. The NSX-T Custom Attribute must not be appended on any of the managed objects. It can lead to disruption of the setup.
  • With Multi NSX enabled on a vCenter Server, you cannot enable Kubernetes cluster or vLCM cluster to work on the same vCenter Server.
  • If you deactivate Multi NSX on a vCenter Server, you cannot use the same vCenter Server to register with another NSX-T instance.
  • If any custom or legacy vCenter Server extension is not deleted from vCenter Server for reason such as failure of NSX to come up, you will have to manually delete extension from vCenter Server.
  • Does not support collapsed cluster environments (where management and workloads are deployed on the same transport node). With Multi NSX flag enabled in a collapsed cluster environment, you cannot deploy new NSX Manager nodes. The workaround is to create a new cluster and deploy NSX Manager nodes.