Browse Category


Replacing the LocalManager certificate in NSX

In this blog we will go over replacing the LocalManager certificate in NSX. In this example I will be using the UI to generate the self signed certificate and then an API call to replace the certificate.

In my case the LocalManager certificate has already expired

In the top menu bar I went to Generate -> Generate Self Signed Certificate

Next I had to grab the new certificate ID

The next step is to replace the old certificate with the new certificate via an API call. For this I used Postman but any other tool could potentially be used.

The URL for the post call would go against https://nsx_fqdn/api/v1/trust-management/certificates?action=set_pi_certificate_for_federation

For authentication I used basic, per best practices we should be using a token.

For headers had to add Content-Type application\json ex

In the body I picket raw and added the following in

{ "cert_id": "8d56e224-52a0-462a-a971-9f2c19c1d33a",

"service_type": "LOCAL_MANAGER" }

The cert ID is from the certificate I generated earlier. ex

Once I clicked send I was presented back with a 200 OK

Going in the web browser I can also see that the new certificate is now used and the old one doesn’t have anything assigned to it ex

The final step I did was removing the old certificate by clicking on the 3 dots to left and picking delete from the menu

Simplifying NSX Edge Removal in VMware Cloud Foundation (VCF) Environment

VMware Cloud Foundation (VCF) has revolutionized data center virtualization by seamlessly integrating compute, storage, and networking components. In a VCF environment, the NSX platform provides crucial software-defined networking capabilities. At times, removing NSX edges becomes necessary due to infrastructure changes, optimization efforts, or other reasons. To simplify this process, VMware has introduced the NSX Edge Removal Tool. In this blog post, we will explore how this tool can streamline the removal of NSX edges in a VCF environment while preserving dependencies.

Understanding the NSX Edge Removal Tool

The NSX Edge Removal Tool is a powerful utility developed by VMware to assist with removing NSX edges in a VCF environment. It simplifies the edge removal process and ensures the preservation of critical dependencies. Let’s delve into the steps involved in using this tool effectively.

Step 1: Preparing for NSX Edge Removal

Before utilizing the NSX Edge Removal Tool, it is crucial to thoroughly understand your VCF environment and identify all dependencies associated with the NSX edges you plan to remove. Review your network configuration, firewall rules, security policies, and any applications or services relying on the edges. This assessment will help you plan and execute the edge removal process more efficiently.

Step 2: Installing and Configuring the NSX Edge Removal Tool

To begin, download the NSX Edge Removal Tool from the VMware website. As of the writing of this blog the latest download can be found here. Follow the installation and configuration instructions provided by VMware to integrate the tool into your VCF environment seamlessly. Ensure that you have the necessary credentials and permissions to access and modify the NSX edges. In my case I downloaded edge_cluster_cleaner_0.27.tar.gz and transferred it to the server.

Step 3: Running the NSX Edge Removal Tool

Once the tool is installed and configured, it’s time to execute the removal process. Launch the NSX Edge Removal Tool and provide the required information, such as the NSX Manager IP address, credentials, and the specific edges you wish to remove. The tool will validate the environment and dependencies, ensuring a safe removal process. ex ./ --cluster WLD1-edge-cluster --workload SDDC-MGT --user [email protected]

Step 4: Verifying and Analyzing the Dependency Report

After executing the removal process, the NSX Edge Removal Tool generates a dependency report. This report provides crucial insights into the dependencies associated with the removed NSX edges. Review the report thoroughly to understand any potential impacts on your network infrastructure and applications.

Step 5: Addressing Dependencies and Network Adjustments

Based on the generated dependency report, it’s essential to address the identified dependencies and make necessary adjustments to your network configuration. Collaborate with network administrators, application owners, and other stakeholders to migrate the dependencies to alternative network resources. Update firewall rules, adjust routing configurations, and ensure seamless connectivity for critical services.

Step 6: Post-Removal Validation and Testing

After addressing the dependencies and making the required adjustments, perform comprehensive validation and testing to ensure that the network connectivity and critical services are functioning optimally. Monitor the network closely for any abnormalities or performance issues, and address them promptly.


The NSX Edge Removal Tool provides a streamlined approach to removing NSX edges in a VMware Cloud Foundation (VCF) environment while preserving critical dependencies. By following the steps outlined in this blog post and utilizing the tool effectively, you can simplify the edge removal process and ensure the smooth operation of your VCF environment. Embrace this tool to optimize your network infrastructure and enhance the agility of your virtualized data center.

How to forcibly delete an NSX-T 3 Segment

I recently ran in to a problem where i couldnt delete an NSX segment so i went exploring the API. The API guide can be found here

The method used is delete policy/api/v1/infra/segments/{segment-id}?force=true

It would look like this in Postman:

To list the segments we can use a get request towards /policy/api/v1/infra/segments/

Removing NSX stale packages from ESXi host

I recently ran in to a problem where i wanted to perform a clean configuration of one of my ESXi hosts from an NSX perspective, however i ran in to a problem where NSX was reporting that the packages are already installed. To fix the issue i had to run the following to list the packages installed:

esxcli software vib list | grep -i nsx

Once i had the list all i had to do is uninstall them using:

esxcli software vib remove -n packagename1 -n packagename2 ...

Once the uninstall was complete i was able to redeploy NSX from the NSX Manager

Configure NSX-T to use vIDM as authentication

I needed to create a few additional accounts in NSX-T for outside sources. Instead of creating individual accounts i wanted to use the existing ones from AD.

To get started we need to get the certificate from the vIDM server. Log on to the vIDM server as root and run the following:

openssl1 s_client -connect <FQDN of vIDM host>:443 < /dev/null 2> /dev/null | openssl x509 -sha256 -fingerprint -noout -in /dev/stdin

Next we need to create the OAuth client ID in vIDM. Log in to the vIDM UI using the url <FQDN of vIDM host>SAAS/admin/app/page#!/dashboard as admin and Navigate to Catalog -> Settings

Navigate to Remote App Access -> Clients -> Create Client

In the Access Type chose Service Client Token, Client ID can be anything. Under Advanced click on Generate Shared Secret (take a note of this because we need it on the NSX side)

Next, log in to the NSX-T cluster and go to System -> Users and Roles -> VMWARE IDENTITY MANAGER -> Edit

Next fill in all the required fields with the existing data that we generated in the previous steps

Next we can see the integration as enabled and the connection as up

Next we can go to USERS click on ADD -> Role Assignment for VIDM

As you type in a user the system will try to auto complete it

Once the users and groups are defined all is left is to test out the authentication and validate that everything works

Extracting SSL Thumbprint

I recently ran in to an issue where i had to re-register my NSX server with vIDM.

The ask was to extract the Thumbprint from vIDM. The command i ran to extract it was:

echo -n | openssl s_client -connect hostname:443 2>/dev/null | openssl x509 -noout -fingerprint -sha256

This can be used across multiple products where the Thumbprint needs to be extracted

NSX 2.5.0 to NSX 2.5.1 fails with error “restart service install-upgrade” on the NSX Manager.

I`ve recently ran through a problem when trying to upgrade NSX-T from version 2.5.0 to 2.5.1. When using the Upgrade function within the UI i was getting the following error:

This page is only available on the NSX Manager where Upgrade Coordinator is running. To configure the service, run the command “restart service install-upgrade” on the NSX Manager.

White checking the status of the service the service seemed to be running with no issues. I also checked the release notes for a couple of releases back and i found a similar issue in the release notes for the 2.3 release

Due to my install being a home lab i could not contact support. If you are experiencing this issue i would strongly advise to contact support before continuing further. VMware support contact information can be found here:

White reading the NSX-T 2.5.1 Upgrade guide from vmware documentation at page 22 i stumbled on instructions to upgrade the CSM. The instructions reference a .nub file but with no instructions on how to retrieve it. Based on whats available on the vmware download portal i was able to find a .mub file.

In order to bypass the error i was experiencing i downloaded the 2.5.1 version of the .mub file from vmware download portal.

After downloading the .mub file i used an unrachiver in my case 7-zip trying to extract an archive from the .mub file. Ive found that the .mub file included a .tar.gz archive and a .sig file. After extracting the tar.gz archive i was presented with a number of folders that included the VMware-NSX-unified-appliance-<version>.nub file i was looking for.

The file should be under Manager\nub. Once extracted it should be uploaded to /image/vmware/nsx/file-store/ on the nsx manager server

Verify the upgrade bundle by running: verify upgrade-bundle VMware-NSX-unified-appliance-<version> as the admin user. The output in my case was

verify upgrade-bundle VMware-NSX-unified-appliance-
Checking upgrade bundle /var/vmware/nsx/file-store/VMware-NSX-unified-appliance- contents
Verifying bundle VMware-NSX-unified-appliance- with signature VMware-NSX-unified-appliance-
Moving bundle to /image/VMware-NSX-unified-appliance-
Extracting bundle payload
Successfully verified upgrade bundle
Bundle manifest:
appliance_type: ‘nsx-unified-appliance’
version: ‘’
os_image_path: ‘files/nsx-root.squashfs’
os_image_md5_path: ‘files/nsx-root.squashfs.md5’
Current upgrade info:
“info”: “”,
“body”: {
“meta”: {
“from_version”: “”,
“old_config_dev”: “/dev/mapper/nsx-config”,
“to_version”: “”,
“new_config_dev”: “/dev/mapper/nsx-config__bak”,
“old_os_dev”: “/dev/sda2”,
“bundle_path”: “/image/VMware-NSX-unified-appliance-”,
“new_os_dev”: “/dev/sda3”
“history”: []
“state”: 1,
“state_text”: “CMD_SUCCESS”

The next step was to upgrade using the bundle:

start upgrade-bundle VMware-NSX-unified-appliance- playbook VMware-NSX-manager-

Node Upgrade is in progress. Please do not make any changes, until
the upgrade operation is complete.

2020-04-20 01:03:25,418 – Validating playbook /var/vmware/nsx/file-store/VMware-NSX-manager-
2020-04-20 01:03:25,492 – Running “unregister_ccp” (step 1 of 13)
2020-04-20 01:03:30,930 – Running “shutdown_manager” (step 2 of 13)
2020-04-20 01:05:18,077 – Running “install_os” (step 3 of 13)
2020-04-20 01:06:14,179 – Running “migrate_manager_config” (step 4 of 13)
2020-04-20 01:06:17,657 – Running “switch_os” (step 5 of 13)
2020-04-20 01:06:30,330 –

System will now reboot (step 6 of 13)
“info”: “”,
“body”: null,
“state”: 1,
“state_text”: “CMD_SUCCESS”

  • 1
  • 2