WilliamLam.com

Single node Supervisor Control Plane VM for vSphere with Tanzu now possible in vSphere 7.0 Update 3

by // 8 Comments

Last year, when vSphere with Kubernetes (original name of what is now vSphere with Tanzu) was first released, I had shared a process on how to deploy a minimal setup including a detailed write-up for setting up vSphere with Tanzu on an Intel NUC with just 32GB of memory.

I am always looking for ways to simplify and ease the consumption of various VMware technologies within a homelab and I was pretty happy with the tweaks that I could make to reduce the amount of resources needed to run vSphere with Tanzu. Instead of needing to deploy three Supervisor Control Plane VMs, the modification to the vSphere with Tanzu configuration, allowed me to deploy just two Supervisor Control Plane VMs. It was unfortunate that deploying only a single Supervisor Control Plane VM at the time was not possible due to a known issue.

While deploying a pre-release of vSphere 7.0 Update 3 in one of my lab environments, I was going through the process of tweaking the vSphere with Tanzu configuration before enablement and I figure why not try the one node setting, in case it was fixed 🤷 I honestly was not expecting it to work since there was an internal bug that was filed awhile back and I had not seen the bug closed. To my complete surprise, vSphere with Tanzu enabled successfully and there was just a single Supervisor Control Plane VM!


It turns out that someone from Engineering must have fixed the issue and a single Supervisor Control Plane VM is now possible with the upcoming release of vSphere 7.0 Update 3! 🥳

UPDATE (07/02/24) - As of vSphere 8.0 Update 3, you no longer have the ability to configure a single Supervisor Control Plane VM using the minmaster and maxmasters parameters, which have also been removed from /etc/vmware/wcp/wcpsvc.yaml in favor of allowing users to control this configuration programmatically as part of enabling vSphere IaaS (formally known as vSphere with Tanzu). The updated vSphere IaaS API that allows users to specify number of Supervisor Control Plane VM will not be available until the next major vSphere release. While this regressed capability is unfortunate, it was also not an officially supported configuration and for users who wish to specify the number of Supervisor Control Plane VM using YAML method, you will need to use an earlier version of vSphere.

To change the settings, you will need to SSH to the VCSA and edit the following configuration file /etc/vmware/wcp/wcpsvc.yaml and search for minmasters and maxmasters and change the value from 3 to 1.

minmasters: 1
maxmasters: 1

For the changes to go into effect, you will need to restart the vSphere with Tanzu service which is listed as wcp by running the following command:

service-control --restart wcp

In addition, for homelab purposes, you may also want to change the controlplane_vm_disk_provisioning parameter, which defaults the Supervisor Control Plane VM to Thick provisioned rather than Thin, which many folks use in their labs.

controlplane_vm_disk_provisioning: "thin"

Considerations for future vSphere Homelabs due to upcoming removal of SD card/USB support for ESXi

by // 16 Comments

In case you have not heard the news, VMware had recently published a new knowledge base article (KB 85685) outlining details for the future removal of SD card/USB as a standalone boot device for ESXi.

If you have not read the KB, please take a few minutes and carefully read the article, especially as you think about future hardware upgrades and purchases.

There has certainly been no shortage of discussions and debates since the publishing of the VMware KB. One topic that I know many of you have been wondering and asking about is what is the impact to vSphere Homelabs? This was something that had already crossed my mind after I first read the KB and I was thinking about this a bit more this week and specifically some of the potential options that are available to customers right now but also some of the considerations you may want to account for in with future homelab upgrades.

Disclaimer: These are my own personal opinions and do not reflect any official guidance or recommendations from VMware.

[Read more...]

Custom webhook function to publish events into VMware Event Broker Appliance (VEBA)

by // Leave a Comment

In my previous article, I demonstrated how you can leverage the upcoming v0.7 release of the VMware Event Broker Appliance (VEBA) to publish and consume custom events to easily extend your event-driven automation to other event sources. As a recap, this is accomplished by constructing and sending a conformant CloudEvent to VEBA, which can then be consumed by your functions.


This is perfect for external event sources that can create a custom HTTP payload that conforms to the CloudEvent specification, however not all solutions have this type of functionality or flexibility. An alternative solution to this is to simply create a VEBA function that can accept a custom payload and then handle the transformation of the data into a valid CloudEvent and then forward that off to broker running within VEBA. This is just one of the many benefits of Knative, the backend for VEBA, where each function deployment includes an endpoint that is automatically served as a subdomain to the VEBA hostname (e.g. https://my-function.NAMESPACE.VEBA-FQDN)


This solution would enable external "Event Producer" to send a non-CloudEvent payload which can then be processed by your function and re-publish as a conformant CloudEvent that can then be consumed by other function and services.

  1. Event Provider would make HTTP request to the function webhook with a custom payload
  2. A conformant CloudEvent payload is constructed by the webhook function
  3. Webhook function will then forward the CloudEvent internally to the VMware Event Broker Appliance
  4. VEBA functions can now react to these custom CloudEvents

[Read more...]