WilliamLam.com

Quick Tip - How do I tell if NSX-V or NSX-T is installed?

by // 1 Comment

This question came up last week asking for a programmatic method to identify whether NSX-V or NSX-T is deployed in your environment. With NSX-V, vCenter Server is a requirement but for NSX-T, vCenter Server is not a requirement, especially for multi-hypervisor support. In this post, I will assume for NSX-T deployments, you have configured a vCenter Compute Manager.

Both NSX-V and NSX-T uses the ExtensionManager API to register themselves with vCenter Server and we can leverage this interface to easily tell if either solutions are installed. NSX-V uses the com.vmware.vShieldManager string to identify itself and NSX-T uses the com.vmware.nsx.management.nsxt string to identify itself.

Here is a quick PowerCLI snippet that demonstrates the use of the vSphere API to check whether NSX-V or NSX-T is installed and provides the version shown in the registration:

$extensionManager = Get-View ExtensionManager

foreach ($extension in $extensionManager.ExtensionList) {
    if($extension.key -eq "com.vmware.vShieldManager") {
        Write-Host "NSX-V is installed with version"$extension.Version
    } elseif($extension.key -eq "com.vmware.nsx.management.nsxt") {
        Write-Host "NSX-T is installed with version"$extension.Version
    }
}

Here is a screenshot from my environment which has both NSX-V (6.4) and NSX-T (2.1) installed:


Note: Due to some current testing, I have not upgraded my NSX-T deployment to the latest 2.2 release, so I do not know if the version gets bumped to match the actual released version

Automated Pivotal Container Service (PKS) Lab Deployment 

by // 3 Comments

While working on my Getting started with VMware Pivotal Container Service (PKS) blog series awhile back, one of the things I was also working on was some automation to help build out the required infrastructure NSX-T (Manager, Controller & Edge), Nested ESXi hosts configured with VSAN for the Compute vSphere Cluster and Pivotal Ops Manager. This was not only useful for my own learning purposes, but that I could easily rebuild my lab if I had messed something up and allowed me to focus more on the PKS solution rather than standing up the infrastructure itself.

To be honest, I had about 95% of the script done but I was not able to figure out one of the NSX-T APIs and I got busy and had left the script on the back burner. This past weekend while cleaning out some of my PKS research documents, I came across the script and funny enough, in about 30minutes I was able to solve the problem which I was stuck for weeks prior. I just finished putting the final touches on the script along with adding some documentation. Simliar to my other vGhetto Lab Automation scripts, I have created a Github repo vGhetto Automated PKS Lab Deployment

UPDATE (06/19/18) - I have just updated the script to also include the deployment and configuration of the PKS components (Ops Manager, BOSH Director, Harbor & Stemcell). The script by default will now configure everything end-2-end and you will have a fully functional PKS environment that you can start playing around with. For complete details, please see the Github repo which has the updated requirements and documentation. Below is a screenshot of the PKS deployment and configuration which requires the use of the Ops Manager CLI (OM).


The script will deploy the following components which will be placed inside of a vApp as shown in the screenshot below:

  • NSX-T Manager
  • NSX-T Controller x 3 (though you technically only need one for lab/poc purposes)
  • NSX-T Edge
  • Nested ESXi VMs x 3 (VSAN will be configured)
  • Ops Manager


The script follows my PKS blog series and automates Part 3 (NSX-T) and the start of Part 4 (Ops Manager deploy), please refer to these individual blog posts for more information. The goal of the script is to enable folks to jump right into the PKS configuration workflows and not have to worry about setting up the actual infrastructure that is needed for PKS. Once the script has finished, you can jump right into Ops Manager and start your PKS journey.

Here is a sample execution of the script which took ~29 minutes to complete.


The full requirements for using the script be found on the Github repo and below are the software versions that I had used to deploy and configure PKS:

Feedback on default behavior for VM Storage Policy

by // 1 Comment

Today, the vCenter REST (vSphere Automation) APIs currently does not support the use of VM Storage Policies when relocating (vMotion, Cross Datacenter vMotion & Storage vMotion) or cloning an existing Virtual Machine. Customers have provided feedback that this is something that they would like to see get added to the current REST APIs and while this is being looked at, there were a couple of open questions from Engineering.

The following 2-question survey below is to help us understand what the "default" behavior should be when a Virtual Machine is being relocated or cloned within a vCenter Server and a VM Storage Policy is NOT specified when using the APIs. The reason for this is that our existing APIs for relocate and clone today are very flexible and not everything needs to be specified as part of the relocate or clone API specification. However, due to this flexibility, you may observe different behaviors and we would like to understand what the default behavior should be when some of these paraemters are not specified. In the case where you want to be explicit, you can always specify the VM Storage Policy, but the survey is to understand when it is not specified.

Survey: https://goo.gl/forms/aQjVTly2MmVHeRsp1

Thank you  for taking the time to provide your feedback, this will help us build an easy and robust API when dealing with relocate and clone operations using the vCenter REST APIs.