PowerCLI

Listing all Events for vCenter Server

12/16/2019 by William Lam 1 Comment

I had a conversation with one of our VMware Cloud on AWS field leaders a couple of weeks ago at reInvent on his initial experience with the vCenter Event Broker Appliance (VEBA) Fling. There were lots great feedback but one thing that stood out to me which looks to have been a barrier to getting started was being able to figure out a specific vCenter Event and its respective identifier. Although the list of "default" vCenter Events are documented in the vSphere API, it is definitely not the first place most folks would go to look nor is it very intuitive to browse.

To be honest, this is not a unique ask for VEBA. I have also seen this requests come up from customers who are automating vCenter Alarms, which can also be based off of vCenter Events and the same question has come up on before. One challenge with such a request is that the number and the types of vCenter Events will vary from customer to customer depending on the number of 2nd and 3rd party solutions deployed, not to mention it will also vary from version to version. In addition, as a customer, you can also publish your own custom Events into vCenter Server which makes this difficult to provide a single list that would cover all possible scenarios.

Ultimately, this ask is completely valid and I started to look at the vSphere API to see if there was something that could help. It did not take look before I stumbled onto the EventDescription which is part of the EventManager, which provides a nice registry for all currently registered vCenter Events. Time for some Automation 🙂

Configure NSX-T Enhanced Data path / Network Stack (ENS) for Nested ESXi

12/10/2019 by William Lam Leave a Comment

After publishing my Running Nested ESXi, NSX-V or NSX-T on top of NSX-T article which actually turned out to be quite popular, I received an interesting question on whether ENS for NSX-T could also be configured within a Nested ESXi deployment? I was a little familiar with ENS, which I will explain in a second. However, I was not completely sure about the benefits of running ENS in a Nested environment.

With the help from my friend Frank Escaros-Buechsel, who actually works in our NFV group at VMware. Frank helped validate the instructions but he also provided some additional insights on why this could be useful in a lab setup for verifying configuration and behaviors when additional tuning maybe required. If you are NOT running NFV-based workloads, ENS is not something you need to configure when running NSX-T using Nested ESXi.

So what is ENS? Enhanced Network Stack (ENS) also referred to as Enhanced Data Path is an NSX-T capability which was first introduced with NSX-T 2.3. ENS is specifically designed for Network Function Virtualization (NFV) workloads that require a high performance data path. Such workloads include Telco, 5G and IoT based deployments where improved packet throughput is critical for the responsiveness of these applications.

Customizing vCenter Alarm Email Subject and Body

11/20/2019 by William Lam 1 Comment

One of the automated actions that can be configured when a vCenter Server Alarm is triggered is to send an email notification. Over the years, I have seen a number of requests and questions about customizing the email and whether an email template exists. I personally have not used this feature much which has been around since the introduction of vCenter Server and mainly because I have always worked in an environment where we had dedicated monitoring tools that provide notifications including emails.

Most recently, I noticed an increase number of questions around this topic and I was curious on whether a solution exists today or if this is still a gap today? A quick Google search landed me on this 2013 VMTN thread which included several workarounds that customers have found. However, the only viable "supported" and "persisted" option at the time within that thread was to use the vSphere API/PowerCLI to customize the alarm action.

While going through this exercise myself, I found that our vSphere UI has had some enhancements since that 2013 thread and I thought it was worth sharing an update in 2019 on how customers can customize both the email subject and body for vCenter Alarms. One thing to note is that there is no generic email template that can be edited, the email customizations are applied on a per-Alarm action basis and this is applicable for both vCenter Server running in a traditional on-premises environment as well as for VMware Cloud on AWS or Dell EMC.

How to debug NSX-T API Automation with PowerCLI?

10/25/2019 by William Lam Leave a Comment

I recently needed to deploy the latest version of NSX-T (2.5) for some work I was doing with Project Pacific and of course it was related to Automation 🙂 It has been some time since I have touched the NSX-T Manager API (2.0) and although most of my existing code still worked, there were some things that broke due to API deprecation and also net new functionality that I needed to use.

I normally use PowerCLI for my Automation work and/or for prototyping purposes, not only is it easy to do but PowerCLI is still one of the most popular tool used by our customers and it means that they can easily benefit from my work. However, one of my pet peeves when working with the NSX-T APIs and PowerCLI is simply the lack of useful error messages. Here is the generic error message that you would normally see even checking the $Error[0].Exception.ServerError variable, it generally does not contain anything useful or actionable.

A server error occurred: 'com.vmware.vapi.std.errors.invalid_request': . Check $Error[0].Exception.ServerError for more details.

Here is a concrete example where I am attempting to create a new Transport Zone but I am purposing leaving out a required parameter and as you can see from the output, the same generic error message is shown and not very actionable.

I normally debug NSX-T API issue whether it is a syntax or usage problem by SSH'ing to the NSX-T Manager and monitoring the actual API logs to figure out what is actually going. It usually has exactly what I am looking for in terms of the actual server error message along with details on how to fix the problem.

Automating HCX Multi-Site Service Mesh configuration using the new HCX PowerCLI cmdlets

07/01/2019 by William Lam Leave a Comment

With the latest Hybrid Cloud Extension (HCX) R121 release, the new HCX Multi-Site Service Mesh configuration option is now the default and preferred method for setting up HCX. In fact, the legacy "HCX Components" method, which is focused on deploying individual HCX Appliances has been deprecated in the latest release and will be removed in the future, in favor of the new simplified deployment option.

As many of you know, I have been doing quite a bit of HCX Automation with VMware Cloud on AWS (VMC) and with the recent PowerCLI 11.3 release which now includes new HCX Multi-Site Service Mesh (MSSM) cmdlets, I figured this would be a good time to update my automation to take advantage of the new HCX MSSM feature.

While trying out the new MSSM cmdlets, I ran into a couple of issues which took me awhile to figure out. The issue stems from the fact that you can not simply create some of the MSSM objects such as a Network or Compute Profile and then save the output to a variable for use with other CSSM cmdlets, which I found to be quite strange as that is one of the biggest benefit of PowerShell and being able to pipe objects between cmdlets. You have to perform a "GET" operation on the object that you had just created because the types returned are different between the New and Get cmdlets. In any case, here is a sample end-to-end workflow using the new MSSM cmdlets as I figured others may run into this problem scratching their head and the PowerCLI documentation was not very clear about this behavior, at least it was not apparent to me.

Automating HCX Add On for VMware Cloud on AWS

06/19/2019 by William Lam 1 Comment

Enabling Hybrid Cloud Extension (HCX) for a VMware Cloud on AWS SDDC is just a click of a button and is completely self-service which makes consuming the HCX Service extremely easy! All the hard work of deploying and configuring the required HCX infrastructure for your SDDC is completely automated for you by VMware when you click on "Deploy HCX" button.

Once the HCX infrastructure has been deployed in your SDDC, you can then deploy the respective HCX components for your on-premises vSphere environment which you can fully automate end-to-end which I have blogged about here.

Although the deployment of the HCX components for the SDDC is just click of a button, I recently had a need to automate this and I figure this would be a nice addition to my HCX PowerShell Community Module and complete the end-to-end story quite nicely from enabling the HCX Cloud Service to automating the deployment and configuration of the on-premises HCX components.