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

Starting with NSX 3.2.2, you can enable support of multiple NSX Managers managing a single VMware vCenter.
Important: You can only enable the multiple NSX Managers managing a single VMware vCenter feature (configured by enabling the Multi NSX flag on the NSX UI) in VMware vCenter 7.0 and later versions.

For more details on how the Multi NSX flag is enabled in VMware vCenter, 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 appends the cluster, hosts and DVS extensions with a key that indicates these objects are managed by a certain VMware vCenter.

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

NSX changes the old extension (com.vmware.nsx.management.nsxt) to a custom extension key (com.vmware.nsx.management.nsxt.<computemanager-id>), where the <computemanager-id> is the VMware vCenter ID in NSX.

On the Hosts → Clusters page, NSX discovers all clusters managed by the same VMware vCenter, 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 Mode to Multiple NSX Mode

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

In Multiple NSX Mode, all NSX Managers registered to the same VMware vCenter 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-1.

  • Prepare Cluster-2 using TNP of NSX-2.

  • In VMware vCenter UI, move one host from Cluster-1 to Cluster-2.
    • On the host that is moved to cluster-2, NSX-1 uninstalls NSX 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 System > Fabric > Hosts > Clusters does NSX Manager-2 start installation on the host.
  • NSX 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-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 VMware vCenter.
    • It is part of a VMware vCenter but TNP is detached from the cluster.
    • It is part of the datacenter in a VMware vCenter.
  • Before moving Host-1 to a NSX-managed cluster do the following:
    • Uninstall NSX from Host-1 transport node.
    • Add Host-1 to a VMware vCenter-managed cluster.
    • TNP is automatically applied to Host-1 and NSX is installed.
  • Prepare Cluster-1 comprising of Host-1 Transport Node using TNP in NSX Manager-1.
  • Prepare Cluster-2 using TNP in NSX Manager-2.
  • Host-1 is a static member of NSGroup in NSX Manager-1.
  • From VMware vCenter, move Host-1 Transport Node to Cluster-2.
  • NSX cannot be removed from Host-1 Transport Node because it is part of NSGroup and the same host cannot be prepared in NSX Manager-2. You can find more details in log files.
Note: This issue can occur even if Multi NSX functionality is not enabled. It can happen when you try to move a host between clusters.

Limitations of Multiple NSX Managers Managing a Single VMware vCenter 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.
  • Even though you can enable Multi NSX on a VMware vCenter, where the version is NSX 3.2.2, do not register the same VMware vCenter with NSX 3.2.1 or any previous release.
  • Ensure the desired user roles have permissions to update Global.ManageCustomFields in VMware vCenter. The NSX 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 VMware vCenter, you cannot enable Kubernetes cluster or vLCM cluster to work on the same VMware vCenter.
  • If you deactivate Multi NSX on a VMware vCenter, you cannot use the same VMware vCenter to register with another NSX instance.
  • If any custom or legacy VMware vCenter extension is not deleted from VMware vCenter for reason such as failure of NSX to come up, you will have to manually delete extension from VMware vCenter.

  • 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.

Interoperability Matrix

The following table lists the solutions that are interoperable with the Multi NSX feature.

Feature/Solution Supported
NSX Guest Introspection (GI)​ Platform No
NSX Service Insertion (SI)​ Yes
VMware vSphere with Tanzu No
vSphere Lifecycle Manager (vLCM) No
NSX Virtual Distributed Switch (N-VDS)
Note: N-VDS is supported in versions before NSX 4.0.
Yes
NSX Federation Yes
VMware vSphere Distributed Resource Scheduler (DRS), VMware vSphere High Availability (HA) , VMware vMotion Yes