WilliamLam.com

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

by // 1 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 // 19 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...]

Adding a customized notification banner in the vSphere UI

by // 1 Comment

I was recently reminded of an old vCenter Server feature called Message of the Day (MOTD) that I had used quite extensively when I was a customer to easily communicate upcoming patch windows, downtime, updates and other interesting news to my internal users. Back in the day, the vSphere UI was known as the VI Client (C# Client or Thick Client) and once the MOTD is configured, users logging in would see this this custom notification banner across their UI Client.

It has been ages since I had used vCenter's MOTD feature but after sharing this tidbit on Twitter yesterday, I found a mix of folks that were still using this awesome feature including a VMware Cloud on AWS use case to that helped them easily identify a particular environments to users who was just learning about this feature for the first time.

In addition to bringing some awareness to this oldie but goodie feature of vCenter Server, I also wanted to share some details on how you might automate this as I had a few questions about this on Twitter.

Here is a screenshot of my vSphere 7.0 Update 2 environment which has been configured with an MOTD and you can see that it can also properly render emojis, so you can certainly have some fun here 🙂


To configure an MOTD, click on the vCenter Server inventory object and then navigate to Configure->Settings->Message of Day and set or disable the message.


For those that wish to configure the MOTD programmatically, you can do so using the vSphere API with your favorite vSphere SDK of your choice including PowerCLI. You will need to use the UpdateServiceMessage() method which is part of the SessionManager object.

If you wish to view or check whether an MOTD is configured, the following PowerCLI snippet can be used:

Get-AdvancedSetting -Entity $global:DefaultVIServer -Name vpxd.motd | select Value

However, to configure the MOTD, you can NOT use the Set-AdvancedSetting cmdlet as the advanced setting is a read only value and you must use the vSphere API directly.

Using PowerCLI, here is how to view the current MOTD:

$sm = Get-View $global:DefaultVIServer.ExtensionData.Content.SessionManager
$sm.Message

Using PowerCLI, here is how to update/change the MOTD:

$motd = "🚨This is William Lam's environment, it is NOT supported. Use at your own risk 😎"
$sm = Get-View $global:DefaultVIServer.ExtensionData.Content.SessionManager
$sm.UpdateServiceMessage($motd)