[NAPP] - Activate TKGs Supervisor Cluster: 500 Internal Server Error

Issue

Today I was deploying the NSX Application Platform (NAPP) in automated way, when I received the following error message:

[Activate TKGs Supervisor Cluster] POST https://{vCenter}/api/vcenter/namespace-management/clusters/domain-c{ID}?action=enable: 500 Internal Server Error

Before to see the solution a brief introduction to what NAPP is.

The NSX Application Platform is a modern microservices platform that hosts the following NSX features that collect, ingest, and correlate network traffic data in your NSX environment.

• VMware NSX® Intelligence™
  
• VMware NSX® Network Detection and Response™
  
• VMware NSX® Malware Prevention
  
• VMware NSX® Metrics
  

NAPP is a microservices application platform based on Kubernets and can be installed in two ways:

• manually
  
• automated
  

By choosing an automated NAPP installation, the customer does not need to be concerned with the installation and maintenance of the individual NAPP platform components including TKGs (Kubernetes).
Further information on how to "Getting Started with NSX Application Platform (NAPP)" can be found here.

Solution

The encountered error "500 internal server error" could be triggered if the vCenter/TKGs license is invalid as indicated here.

Tanzu licenses expired was exactly my case.
Looking inside the Workload Management, I discovered multiple incompatibilities.

Incompatibility reasons was related to "expired license".

Entered the new Tanzu license ... restarted the deployment task ... the process resumed from the previous point and TKGs was successfully deployed.

That's it.

[DELL Server] - Lifecycle Controller in Recovery Mode

Issue

Today I was working on a new PowerEdge R650xs, when in a start up face I noticed the message "Lifecycle Controller in Recovery Mode"

Solution

To solve this issue, press F2 to enter in System Setup

Enter into iDrac Settings menu ...

... Lifecycle Controller

Select Enabled in Lifecycle Controller and click on Back

Hit Finish...

... and save changes pressing YES.

If the changes have been saved correctly, press OK and Reboot the system

At the next start up the error message is no longer present.

That's it.

How to quick check NSX DFW rules of a VMs on ESXi host

Issue

I need to know if a NSX-T firewall rules are deployed on a host and are applied to virtual machines.

Solution

The commands to use to verify that the firewall rules are deployed on a host and are applied to virtual machines are :

# summarize-dvfilter and  vsipioctl

Let's see how to use them below, I would like to say that those tests were carried out on the HOL (hands on labs) made available by vmware, but nothing change on the real life.

In our test, we would like to validate the DFW rule for the VM web-01a.
Located the VM that we want to validate we get SSH into the ESXi host.

So, once logged in, we type ...

# summarize-dvfilter | grep -A 3 vmm0:web-01a 

... and we look for the name under vNIC slot.

Then to show the appliade rules, we use the command vsipioctl getrules like below:

# vsipioctl getrules -f nic-269171-eth0-vmware-sfw.2 

Alternatively, we can use the combined commands as follows ...

# vsipioctl getrules -f `summarize-dvfilter | grep -A 3 vmm0:web-01a | grep name | awk '{print $2}'` 

As we can see from the previous picture, the rules ID 2031, 2032, 2033 are not present on the VM. Why??
Simply, because they are not enabled.

Once enabled and published ...

...if we rerun the command ...

# vsipioctl getrules -f `summarize-dvfilter | grep -A 3 vmm0:web-01a | grep name | awk '{print $2}'` 

... we can see now, them applied to the VM.

That's it.