virtuallyGhetto

Automation

Automated Lab Deployment Script for vSphere with Tanzu using NSX Advanced Load Balancer (NSX ALB)

by 2 Comments

After spending a few days playing with the NSX Advanced Load Balancer (NSX ALB) APIs, I am happy to share my latest automation lab deployment script for deploying vSphere with Tanzu using the new NSX ALB which was introduced with the latest vSphere 7.0 Update 2 release.

Lab Deployment Automation

You can find the new automation script along with all the details at the following Github Repo: https://github.com/lamw/vsphere-with-tanzu-nsx-advanced-lb-automated-lab-deployment#enable-workload-management


In my environment, it took about ~32 minutes for the deployment to finish, but YMMV based on the performance of your underlying hardware.

Workload Management Automation

In addition to the automated lab deployment script above, I have also updated my community VMware.WorkloadManagement module to add support for enabling Workload Management on a vSphere Cluster using NSX ALB. This is introduced as a new function creatively called New-WorkloadManagement3. You use the Get-Help cmdlet to get a list of supported arguments or you can take a look at this example.

Automating default admin password change for NSX Advanced Load Balancer (NSX ALB)

by 5 Comments

Over the weekend I got a chance to deploy my first vSphere with Tanzu environment using the new NSX Advanced Load Balancer (NSX ALB) which I had shared on Twitter.

This was also my first time getting exposed to NSX ALB (formally AVI Networks) and this detailed blog post from my buddy Cormac Hogan was instrumental in helping me quickly get started and get into the specific configurations needed for a two network design with vSphere with Tanzu. For me personally, there were just too many different configuration pages a user needed to navigate to and context switching between them made it non-intuitive for a new user like myself. After going through this once, I knew Automation was the next step for me and this was also an opportunity to try out the NSX ALB API, which I also have never used before.

[Read more...] about Automating default admin password change for NSX Advanced Load Balancer (NSX ALB)

Quick Tip – Disable vSphere with Tanzu prompt during TKG Management Cluster deployment

by Leave a Comment

When you attempt to deploy a new Tanzu Kubernetes Grid (TKG) Management Cluster to a vSphere 7.0 environment, you may have noticed a message stating that you may want to enable the Tanzu Kubernetes Grid Service (TKGs) alternatively.


Running TKG and TKGs on vSphere 7.0 is fully supported and depending on your use case, you may want to enable one or the other. In either situation, you are always prompted with a question which you must answer before you can continue. Awhile back I was looking into whether there were any CLI options to override this behavior and simply answer in advanced but did not see anything in the CLI help menu.

I recently ran into this again and while asking around, I came to learn that were are indeed two (hidden) options that can be used to override and disable these prompts, which can be useful for unattended automation purposes. Although these options are hidden from the CLI help options, I am not exactly sure why this is the case, they are officially documented in the TKG documentation.

  • --deploy-tkg-on-vSphere7 can be used to confirm that you wish to deploy a TKG Management Cluster on vSphere 7
  • --enable-tkgs-on-vSphere7 can be used to confirm that you will be using the TKGs as your Management Cluster in vSphere 7

With this information, we can now pass in the --deploy-tkg-on-vSphere7 option as shown in the example below and you will no longer be prompted:

tkg init -i vsphere -p dev --name tkg-mgmt --vsphere-controlplane-endpoint-ip 192.168.30.127 --deploy-tkg-on-vSphere7

Simplified Nested ESXi installation in ESXi 7.0 Update 2 using HTTP Boot over VirtualEFI

by 17 Comments

Deploying an ESXi scripted installation aka Kickstart running within a VM (Nested ESXi) has a number of benefits, especially for testing and development purposes. This was something I did regularly as a customer, especially with new releases of ESXi to ensure our existing automation scripts and processes continued to work before rolling out into production. ESXi kickstart itself is pretty straight forward, but the required supporting infrastructure (PXE Server, DHCP, TFTP, etc) that needs to be configured, especially for a greenfield deployment can often be challenging for new comers.

Even with an existing PXE infrastructure, it can often be difficult to configure or troubleshoot depending on your level of access which does not add any value in actually testing or automating the ESXi scripted installation process. In ESXi 7.0 Update 2, an enhancement was made to the Virtual Machine's UEFI firmware called VirtualEFI that would enable ESXi to perform an HTTP Boot given the ESXi bootloader URL and without requiring any of the traditional PXE infrastructure.

To take advantage of this new capability, you just need to have a physical server running ESXi 7.0 Update 2 and a VM that is configured with the latest vHW19 compatibility. To configure HTTP boot, you will need to add the following two VM Advanced Settings:

  • networkBootProtocol - httpv4 or httpv6
  • networkBootUri - HTTP URL to the ESXi bootloader (bootx64.efi)

Disclaimer: Nested ESXi and Nested Virtualization is not officially supported by VMware

[Read more...] about Simplified Nested ESXi installation in ESXi 7.0 Update 2 using HTTP Boot over VirtualEFI

Quick Tip – Using ESXi to send Wake-on-Lan (WoL) packet

by 1 Comment

The ability to power on a system over the network using Wake-on-Lan (WoL) can be extremely useful, especially if you are not physically near the system or after a power outage. I personally have been using the wakeonlan utility on my macOS system for several years now.

The syntax is super easy, you just provide the MAC Address of your system:

wakeonlan 54:b2:03:9e:70:fc
Sending magic packet to 255.255.255.255:9 with 54:b2:03:9e:70:fc

I recently came to learn that ESXi itself has the ability to send a WoL packet from the ESXi Shell! This could be handy without having to install WoL client, especially if you have access to an ESXi host.

vsish -e set /net/tcpip/instances/defaultTcpipStack/sendWOL 192.168.30.255 9 54:b2:03:9e:70:fc vmk0

This uses the not supported vsish CLI to send WoL packet. The first argument is the network broadcast address, so if you have a network of 192.168.30.0/24, then the address would be 192.168.30.255. The second argument is a value of 9, which is probably related to the magic packet as you can see the same value from the wakeonlan utility abvoce. The third argument is the MAC Address of the system and finally the fourth and final argument is the ESXi VMkernel interface to send the packet out of.

Decoding Services Roles/Permissions from a VMware Cloud Services Platform (CSP) Token

by Leave a Comment

To programmatically access the various VMware Cloud Services (CSP) such as VMware Cloud on AWS as an example, a user must first generate a CSP Refresh Token using the CSP Console.


When creating a new CSP Refresh Token, you have the option to scope access to a specific set organization roles and service roles which will enable you to limit the permissions of this token to specific CSP Services. In the example below, I have created a new token which is scoped to the organization owner role along with two VMware Cloud on AWS Service Roles: Administrator (Delete Restricted) and NSX Cloud Admin to be able to grant access to a VMware Cloud on AWS SDDC.


One common issue that I see folks run into when working with some of the CSP Services including VMware Cloud on AWS from a programmatic standpoint is that they did not properly create a token with the correct permissions which usually will lead to some type of invalid request.

For popular services like VMware Cloud on AWS, it is usually pretty easy to track down, especially if the user who is using the CSP Refresh Token is the same person who created it. However, if you are not the person who created the original token or if you have forgotten or you may have access to multiple token, it can be a little bit difficult to troubleshoot.

The good news and probably lesser known detail about how CSP Refresh Tokens work is that you can actually decode these tokens to understand what specific scopes were used to create the initial token. Below are two methods to decode these tokens, both CSP Refresh Tokens (generated from the CSP UI) as well as CSP Access Token, which is returned when you request access providing your CSP Refresh Token.

[Read more...] about Decoding Services Roles/Permissions from a VMware Cloud Services Platform (CSP) Token