WilliamLam.com

How to unregister Hybrid Cloud Extension (HCX) from your onPrem vCenter Server?

by // 1 Comment

I recently had to redeploy my Hybrid Cloud Extension (HCX) setup on my onPrem vCenter Server as a newer version had been released since the last time I had looked at this which was some time last year. I had already deleted my HCX Manager and cleaned up the other HCX VMs but one thing that is not handled for you currently are the extension plugins that HCX uses to register with vCenter Server, which is no different than any other solution that integrates with vCenter Server.

Today, the only easy way to unregister an extension is to use the vSphere MOB, which I have blogged about in the past here. As you can see from the screenshot below, HCX has a number of plugins and because this is done by hand, its entirely possible that you may accidentally unregister the wrong extension which could severely impact your vCenter Server.


To help reduce that risk, an alternative and recommended method is to simply use the vSphere API (which is exactly what the vSphere MOB is talking to) and specifying the specific extensions to unregister. Below is a quick PowerCLI snippet which talks to the vSphere API and unregisters the 8 extensions related to HCX. After this, if you are still logged into the vSphere Client, you simply need to logout and log back in for the UI components to go away. If you are still seeing the UI plugins, you may need to restart the vSphere Client service.

$extensionManager = Get-View $global:DefaultVIServer.ExtensionData.Content.ExtensionManager

$hcxExtensions = @(
"com.vmware.hybridity"
"com.vmware.hybridity.dr"
"com.vmware.hybridity.hcsp-dashboard"
"com.vmware.hybridity.publisher"
"com.vmware.hybridity.troubleshooting"
"com.vmware.hybridity.hybrid-interconnect-ui"
"com.vmware.hybridity.auditlog-ui"
"com.vmware.vca.marketing.ngc.ui"
"com.vmware.hybridity.mobility-app"
"com.vmware.hcsp.alarm"
)

foreach ($hcxExtension in $hcxExtensions) {
    $extensionManager.UnregisterExtension($hcxExtension)
}

Once the HCX extensions have been removed, you can now download the new HCX Manager appliance from the VMC portal and redeploy.

If you are still seeing the HCX Plugin in the vSphere UI after unregistering the extension, I have found that you also needed to clear the H5 Plugins on the vCenter Server itself. Here is what I needed to do to fully clean it up. Login to the VCSA and then run the following commands:

cd /etc/vmware/vsphere-ui/vc-packages/vsphere-client-serenity/
rm -rf com.vmware.hybridity*
rm com.vmware.vca.marketing.*
cd /usr/lib/vmware-vsphere-ui/server/pickup/
rm -rf com.vmware.hybridity*
rm com.vmware.vca.marketing.*

Getting started with the new NSX-T Policy API in VMC

by // 26 Comments

Today, when you deploy a new SDDC on VMware Cloud on AWS (VMC), NSX-T is now the default networking stack and NSX-V is no longer used for net new deployments. In fact, we are about to start migrating existing VMC customers who have an NSX-V SDDC and converting them to an NSX-T SDDC. Humair Ahmed who works over in our Networking & Security Business Unit has an excellent blog post here that goes into more details on what NSX-T brings to VMC.


Upon first glance, you might think that this is the exact same version of NSX-T that we have been shipping to our on-premises customers but in fact, it is actually a brand new and improved version. Similar to vSphere (vCenter and ESXi) and VSAN, VMC is always running a newer version of our software than our on-prem customers. One immediate difference that you should be aware of when using NSX-T in VMC is that the current NSX-T API is not available and instead a new NSX-T Policy API has been introduced to help simplify the consumption of NSX-T. All functionality in the current on-prem NSX-T API can be consumed using the new Policy API.

At VMworld, I spoke to a number of current and upcoming customers with NSX-T based SDDCs and they were really interested in using the new NSX-T Policy API and as the title of this blog post suggests, this will be a quick primer on how to do that. Before we get started, confirm that you have an NSX-T based SDDC deployed. If you are not sure, there are a few ways to determine this using either the VMC Console UI or API, instructions can be found here and here.

[Read more...]

VSAN Managed Object Browser (MOB) in vSphere 6.7 & vSphere 6.7 Update 1

by // 1 Comment

If you have ever spent any time using the vSphere API, you probably have heard of or have used the vSphere Managed Objected Browser (MOB) which is an extremely useful learning and debugging tool when working with the vSphere API. The vSphere MOB is accessed through a web browser connecting to either vCenter Server or ESXi and provides a graphical interface, allowing you to discovery/explore the underlying vSphere API and its data in a very intuitive manner.

As an avid user of the VSAN Management API since its release, I have always wanted something similar, especially when I first got started. I was quite happy when I found out in vSphere 6.7 and VSAN 6.7, the VSAN team has added a VSAN MOB interface directly on ESXi, for the VSAN specific APIs that are available only on an ESXi host. Just like the vSphere MOB which is also available on ESXi host, it is disabled by default and must be enabled.

The following ESXCLI commands can be used to enable/disable the VSAN MOB on ESXi 6.7:

esxcli vsan debug mob start
esxcli vsan debug mob stop

However, when I tried to enable the VSAN MOB, I ran into the following error message:

hostname 'localhost.localdomain' doesn't match '192.168.30.10'


It turns out there is an issue where it fails to match the IP Address of the ESXi host to the default localhost.localdomain and hence it fails to start the VSAN MOB. This issue is fixed in the upcoming vSphere & VSAN 6.7 Update 1, but in the mean time, there is a workaround.

[Read more...]