Get the root password for a Guest Introspection VM (SVM)

I recently had an issue where I needed to collect logs from a Guest Introspection VM as part of troubleshooting McAfee Anti-Virus performance problems. In order to collect the logs I needed to obtain the root password for my Guest Introspection VMs. I quickly realized there wasn’t a great source online for doing so and decided to publish this article.

  • SSH to the NSX Manager appliance and login with the admin account.
  • Enter the following command to elevate to root. When prompted, enter the root password you set while deploying the NSX Manager appliance.


  • Enter the following command to enter tech support mode. When prompted for the password type:

st eng

  • Issue the following command to output the root password for the Guest Introspection VMs:



KMS & AD Based Activation

What is KMS?


KMS, or Key Management Services, is the deprecated method to activate licenses within an environment. A KMS server is deployed and then configured for each product that needs to be licensed (i.e Server, Office, Windows 10 etc). Then, for each product, a public KMS key is used to tell that product to activate against the KMS server in the environment. KMS is ideal for large or isolated environments that may have issues activating products with MAKs (multiple activation keys).

What is AD Based Activation?

AD Based Activation was introduced with Server 2016 and represents the next generation of KMS. One shortcoming of KMS is that it was installed on a single server and thus was a single point of failure. AD Based Activation serves the same purpose as KMS but instead, it stores it’s activation information within AD and replicates it to all other DCs thus eliminating the single point of failure. The one catch to the AD Based Activation is that it can only be used to activate software for the following products:

  • Server 2016+
  • Windows 10+
  • Office 2016+

If you need to activate older versions of these products then you need to use KMS to do so.

UCS – Rebuild a Failed FlexFlash Array


When running a RAID1 array with two SD cards on a UCS FlexFlash controller you may encounter a situation where one of the SD cards has failed and you need to replace and rebuild the RAID array. Unfortunately, the steps to resolve this issue are slightly different then how you would with an HDD RAID array.


  • Verify the RAID array is unhealthy.
  • In UCS Manager click the Servers section and then click on the Server in question.
  • Click Inventory -> Storage
  • Click the FlexFlash controller in the list of controllers
  • Expand the FlexFlash Cards section
  • Verify the status of the RAID array and note which card has failed.









  • Physically replace the SD card
  • Go back into Servers -> Server -> Inventory -> Storage and click on the FlexFlash controller
  • Click Configure Auto-sync
  • Ensure that mirror mode is set to pair
  • Admin slot number should be set to the healthy SD card
    • If you get this step backwards you will erase your healthy SD card. The example below shows a scenario where SD card is unhealthy and the data should be mirror from 1 to 2.












  • Click Ok
  • Refresh the page and notice that the unhealthy card’s status is now Initializing
  • This will take 30-60 minutes and then the RAID array will be healthy.


UCS – Change the Bootable LUN


I recently ran into an issue in UCS Manager where I had multiple local LUNs configured and it was setting the wrong LUN as bootable. I finally ended up opening a support case as I didn’t see anywhere to change the bootable LUN.

Change Bootable LUN

The bootable LUN is controlled by the boot policy. The steps below walk you through finding the name of your local LUN and setting the boot policy to boot from that LUN.

  • Login to UCS Manager
  • Browse to the Storage Section and look at the Storage Profile
  • Within the Storage Profile you should have a list of Local LUNs. In the example below I have 1 Local LUN named OS.

Read More

Cisco HyperFlex – Change NTP Server After Deployment



Recently I was in the process of deploying a HyperFlex cluster and one of the NTP servers came back as invalid due to a missing firewall rule on the network. I wanted to proceed as I still had one valid NTP server but I wasn’t sure how difficult it would be to reconfigure NTP after the HyperFlex installation. Luckily it’s pretty easy and this page can walk you through the process.

Read More

UCS – Change Fabric Interconnect (FI) IP Addresses and/or Host Names


Recently I ran into a situation where I was required to reconfigure the Fabric Interconnects to use a different IP address and host name. Initially, I was worried that this could be fairly complex as it might be deeply ingrained in the UCS configuration. I’m happy to report that it’s one of the easiest changes I’ve ever made. I only saw it partially documented on a single blog so I wanted to create another post in case someone else is in my same situation.


  1. Serial connection to both FI-A and FI-B
  2. New IP addresses for FI-A, FI-B and the cluster
  3. A new root host name

Read More