PowerCLI

Workload Management PowerCLI Module for automating vSphere with Kubernetes

05/19/2020 by William Lam Leave a Comment

One of the last things on my to-do list after creating my Automated vSphere 7 and vSphere with Kubernetes Lab Deployment Script which is still the quickest and most reliable way to have a fully deployed and configured environment to try out vSphere with Kubernetes using Nested ESXi, was to also automate the enablement of Workload Management for a given vSphere Cluster.

There are two new vCenter Server REST APIs to be aware of as it pertains to vSphere with Kubernetes:

namespaces = Manages the lifecycle and access control to a vSphere Namespace
namespace-management = Despite the name, this refers to lifecycle and management of a Workload Management Cluster

I also have to mention that Vikas Shitole, who works on vCenter Server, has fantastic blog series covering various parts of the new vSphere with Kubernetes API along with Python examples if you want to dive further. Since Vikas has done a great job covering Python, I figure I will demonstrate how to consume these new vSphere with Kubernetes API using PowerCLI, which many of our customers use to automate.

I have created a new WorkloadManagement.psm1 PowerCLI module which includes following functions:

Get-WorkloadManagement
New-WorkloadManagement
Remove-WorkloadManagement

Below are the two steps required to get started with the Workload Management PowerCLI Module.

Step 1 - Download and import the WorkloadManagement PowerCLI Module by running the following command:

Import-Module ./VMware.WorkloadManagement.psm1

Step 2 - A connection to the vCenter REST API endpoint using the Connect-CisServer cmdlet is required for enabling and disabling Workload Management Cluster

Connect-CisServer -Server pacific-vcsa-2.cpbu.corp -User *protected email* -Password VMware1!

A connection to vCenter Server using Connect-VIServer cmdlet is only required if you wish to retrieve information about an existing Workload Management Cluster

Connect-VIServer -Server pacific-vcsa-2.cpbu.corp -User *protected email* -Password VMware1!

NSX-T Edge OVF property to automatically join NSX-T Management Plane

04/20/2020 by William Lam 2 Comments

After publishing my vSphere 7 with Kubernetes automation lab deployment script, I was looking at my NSX-T Edge code which leverages the vSphere VM Keystroke API to automate the joining of the the NSX-T Edge to the NSX-T Management Plane. This technique is used to avoid the need for SSH access to both NSX-T Edge and Manager which is the official VMware method as outlined in the documentation for configuring the Edge.

This is certainly unfortunate as most customers normally disable SSH by default and only enable it for troubleshooting/debugging purposes. As far as I know, there are no remote NSX-T APIs for configuring an NSX-T Edge that has been deployed outside of NSX-T Manager, which has its own implications.

I recently had a chance to revisit some research I had made a note of when I had first started working with NSX-T. While inspecting the NSX-T Edge OVA, I found several OVF properties that begin with mp which per the description was referring to the NSX-T Manager. At the time, I was not able to figure out which the required combination of keys and values. Taking a closer look and poking around the appliance and logs, I was able to finally figure out the correct combination which turned out to be easy, once you knew what it was expecting.

To help demonstrate this functionality, I have created a basic PowerCLI script edge-auto-join-nsxt-management-plane.ps1 which uses information from your already deployed NSX-T Manager to automatically deploy the desired number of NSX-T Edge(s) which will automatically join the NSX-T Management Plane upon initial setup.

The way this works is that the following four OVF properties must be filled as part of the NSX-T Edge deployment:

Automating the creation of NSX-T “Disconnected” Segments for DR testing on VMware Cloud on AWS

03/05/2020 by William Lam 1 Comment

Disaster Recovery (DR) and Disaster Avoidance (DA) on VMware Cloud on AWS is still one of the most popular use case amongst our customers, just second to Datacenter Migration and Evacuation. The VMware Site Recovery service makes it extremely easy and cost effective for customers to protect their critical workloads without having to worry about the underlying infrastructure. Most often, the biggest cost of having a dedicated DR site is the on-going operational and maintenance cost of that infrastructure.

Most recently I have seen several requests come in where customers were looking to streamline their DR testing which is fantastic to hear. Just having a DR solution is not enough, you actually need to exercise it and verify that your workloads and applications are functioning as expected. Today, customers can verify that their applications are functioning as expected by creating NSX-T network segments that are "Disconnected" and then using a VM-based router to provide internal connectivity between these isolated environments.

Here is a screenshot of the VMware Cloud console and under the Networking & Security tab, when creating a new segment you can specify whether the segment is "Connected" (Routed) or "Disconnected".

Obviously, the NSX-T UI is just one way of creating a segment. In fact, most customers that have asked about this is wanting to do this via Automation which not only brings speed to testing but also consistency! With that, I have updated my NSX-T PowerShell Community Module for VMC to include two new updates. If you have never used this VMC module before, please take a look at the Getting Started guide here.

Using PowerCLI to automate the retrieval of VCSA Identity Sources

03/02/2020 by William Lam 3 Comments

Similiar to automating the retrieval of the vCenter Server Appliance (VCSA) password policies using PowerCLI, we can extend that example and leverage the Guest Operations API via Invoke-VMScript cmdlet to also retrieve the identity sources configured for a given VCSA without requiring SSH access.

I have created a new VCSA.psm1 PowerCLI Module which now includes the previous Get-VCSAPasswordPolicy function along with the new Get-VCSAIdentitySource function which accepts the name of the VCSA VM and root password to the VM as shown in the screenshot below.

If you need to add a specific Identity Source such as an Active Directory Domain which you have joined the VCSA, you can simply use Invoke-VMScript cmdlet and pass in the following command:

/opt/vmware/bin/sso-config.sh -add_identity_source -type nativead -domain vmware.corp

How to automate the creation multiple routable VLANs on single L2 network using VyOS

02/12/2020 by William Lam 4 Comments

My personal homelab has a very simple network topology, everything is connected to a single flat network. This has served me well over the years, but sometimes it can prevent me from deploying more complex scenarios. Most recently while working with NSX-T and Project Pacific, I had a need for additional VLANs which my home router does not support. There are a number of software solutions that can be used including the popular pfSense, which I have used before.

Over the Winter break, a colleague introduced me to VyOS, which is another popular software firewall and router solution. I had not heard of VyOS before but later realized it was derived from Vyatta, which I had heard of, but development of that solution had stopped and VyOS is now the open source version of that software. Having never played with VyoS before, I thought this might be a good learning opopournity and started to dabble with VyOS over the holiday. At a high level, I have VyOS connected to two networks: Outside network as VyOS refers which is your local LAN and Inside network as VyOS refers which is an is an isolated vSphere Portgroup (VSS/VDS) that is not connected to anything and configured to pass all traffic (4095). From here, you can create multiple VLANs in VyOS which can then be untagged using Virtual Guest Tagging (VGT) by placing a Nested ESXi VM on the same isolated portgroup and then creating the respective portgroups within the Nested ESXi VM mapping to the VyOS VLANs you have created.

One of the nice benefits of this solution is that you can create multiple "Isolated" yet routable networks that can still reach your primary LAN network and still have to access core infrastructure services running like Active Directory, DNS, etc. which was one of my requirements. After figuring out how VyOS works and applying that to my specific use case, I thought why not build some basic automation to setup this solution as I probably will forget how I setup everything. Initially I was using the VyOS OVA but later found out it was an extremely out of date there was no public version of the latest VyOS release in OVA form. I decided to use their latest rolling release and apply some vSphere API Automation to not only install VyOS but also fully configure based on template containing VyOS commands. I know the latest version of VyOS now includes a REST API but its a bit of a chicken/egg to enable and not very friendly to use compared to the solution I have built.

Listing all Events for vCenter Server

12/16/2019 by William Lam 2 Comments

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 🙂