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

How to configure the vCenter Extension vService using ovftool?

by // 9 Comments

A really neat capability that is available in some of VMware's Virtual Appliance is a feature called vCenter Extension vService which leverages the vCenter Solutions Manager and vServices SDK. This feature allows a virtual appliance solution to automatically register itself as an extension with vCenter Server without requiring user to provide vCenter Server connection information and thus simplifying the deployment of a virtual appliance based solution. Some examples of VMware Virtual Appliances that can advantage of this feature are vSphere Replication and vSphere Infrastructure Navigator. If you have deployed either of these solutions, you may have seen a screenshot like the one shown below.

vCenter-extension-installation-vService-0
When going through the vSphere C#/Web Client to deploy a virtual appliance that requires vCenter Extension vService, the process is quite simple. You simply click on the drop down menu and select the one and only option as seen in the screenshot above. However, if you are looking to automate the virtual appliance deployment using something like ovftool, you might be asking how do you go about configuring this parameter? This was actually a recent question that I received on an older blog post regarding the automated deployment of vSphere Infrastructure Navigator.

The good news is that ovftool provides a way to configure the vCenter Extension vService using an option called --vService and expected syntax is the following:

--vService:<dependencyId>=<providerId>

To find the dependencyId, you will need to inspect the virtual appliance OVF/OVA. You can simply do this by running ovftool and passing in the OVF/OVA as input. Using the latest vSphere Infrastructure Navigator 5.8 OVA, the dependencyId is simply named "installation" as seen in the VService Dependency section in the screenshot below.

vCenter-extension-installation-vService-1
The providerId refers to the vCenter Server and from what I can tell, this statically defined as com.vmware.vim.vsm:extension_vservice

Putting all this together, if you wish to configure the vService, you will need to pass in the following option to the ovftool:

--vService:installation=com.vmware.vim.vsm:extension_vservice

How to Update vSphere Infrastructure Navigator (VIN) After Changing vCenter Server IP Address

by // 2 Comments

If vSphere Infrastructure Navigator (VIN) is deployed in your environment and you change the IP Address of the vCenter Server, VIN will no longer function even after a reboot. The reason for this is that when VIN first registers with the vCenter Server, information is generated and stored within VIN such as the IP Address as well as security thumbprint. Since the IP Address of the vCenter Server has changed, we simply just need to re-register VIN with the vCenter Extension vService.

In my lab I have VIN deployed and connected to a vCenter Server (note the IP Address 172.30.0.229):

I then update the vCenter Server's IP Address to 172.30.0.230 which will break communication with VIN. To resolve this, start off by shutting down the VIN appliance. Once it is shutdown, edit the settings and click on "Manage->vServices" and at the bottom click on the Edit button. Next change the Provider drop down to "No Provider" and then click OK.

Now we will reset the Provider back to the vCenter Extension vService by going through the same workflow again but now selecting "vCenter Extension vService" as the provider.

You will also notice at the bottom there is a validation message and you should also see the new IP Address of your vCenter Server. Once you are done, click OK to save the settings and then power back on your VIN appliance. Once VIN is up, connect to the vSphere Web Client and you should be able to see your VIN data again!