The vSphere Client crashes after editing Replication Cluster in NSX
search cancel

The vSphere Client crashes after editing Replication Cluster in NSX

book

Article ID: 321280

calendar_today

Updated On:

Products

VMware NSX for vSphere

Issue/Introduction

This article provides information on the new "force" option added to the API for deleting members of a PTEP cluster.

In the NSX Networking and Security > Service Definitions - Hardware Devices, when you edit the Replication Cluster, the flash vSphere Client crashes.

Environment

  • VMware NSX for vSphere 6.4.x
  • VMware NSX for vSphere 6.3.x

Cause

This issue occurs when a host or hosts has been removed from the vCenter Server inventory, but not removed from the Replication cluster first, which causes an inconsistency in the NSX Manager database with the vCenter Sever database.

Resolution

This issue is resolved in VMware NSX for vSphere 6.3.6.

Note: This is still a known issue affecting VMware NSX for vSphere 6.4.x

Workaround:

Under some circumstances, one of the NSX Manager tables, the tor_ptep_cluster can have residual entries for hosts that were once members of the PTEP cluster but which no longer exist in the vCenter Server inventory.
Because the logic to manipulate these entries involves validating against the inventory, different operations start failing once a stale entry appears in the table.

For example: The User Interface may throw errors and it may be difficult to add or delete hosts from the PTEP cluster from either the UI or by using the API.

To resolve this issue, a new API at version 4.0 has been added. It is a PUT call that behaves identically to the corresponding 2.0 call and is invoked as:

PUT https://NSXMGR_IP/api/4.0/vdn/hardwaregateways/replicationcluster?force=true

The body of the call is identical to that of the 2.0 API. Without the force=true query parameter, the call should behave identically with the 2.0 API.

For example: It will fail when stale entries are present in the tor_ptep_cluster table.