Browse Category


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

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

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”