WilliamLam.com

What is vc-ws1a-broker service on vCenter Server Appliance (VCSA)?

by // 1 Comment

When vSphere 8.0 Update 1 was released, I noticed an interesting message about containers being installed while deploying the vCenter Server Appliance (VCSA) ...

As shared in the Tweet/X above, it turns out this was for a service called vc-ws1a-broker, which I came to learn was for enabling the new Identity Federation Provider for the VCSA with Okta.

I ended up correctly guessing that the vc-ws1a-broker process was indeed our very own VMware Workspace One Access (WS1A) application but running as a Container workload within the VCSA. In vSphere 8.0 Update 2, support for Microsoft EntraID (formally Azure AD) is now also possible as additional identity provider option.

One important thing to be aware of the vc-ws1a-broker service is that it is configured to be able to consume up to 2GB of memory, as shown using the cloudvm-ram-size utility in the screenshot below.

[Read more...]

vSphere Pods using VDS based Supervisor in vSphere with Tanzu?

by // 12 Comments

vSphere with Tanzu has received an exciting update with the release of vSphere 8.0 Update 1, which removes the restriction for requiring NSX-based networking to deploy Supervisor Services. This is really cool because customers with only a VDS based Supervisor can now also get the benefits of the various Supervisor Services that vSphere with Tanzu supports!


For those not aware, Supervisor Services are deployed as vSphere Pods, which is a super tiny VM that boots up a Photon OS kernel and is configured with just enough resources to run one or more Linux containers. In earlier releases of vSphere with Tanzu, vSphere Pods required an NSX based Supervisor, but with this restriction removed in vSphere 8.0 Update 1, it seems like deploying vSphere Pods should also be possible with just a VDS based Supervisor? 🤔

[Read more...]

How to bootstrap vSAN Express Storage Architecture (ESA) on unsupported hardware?

by // Leave a Comment

I was recently chatting with a fellow colleague who asked an interesting question about the memory overhead between running vSAN Original Storage Architecture (OSA) versus the new vSAN Express Storage Architecture (ESA) from a VMware Homelab perspective. I honestly did not know the answer as I am only using vSAN OSA for my personal homelab. I was curious myself, especially its implicationn on small form factor (SFF) systems which typically max at out 64GB of memory.

Today, vSAN ESA is only officially supported when using vSAN ESA Ready Nodes which are all listed in the vSAN ESA HCL and the minimum amount of memory is 512GB. For the best possible experience and supported configurations, customers should only use approved vSAN ESA hardware and the use of any other systems will not yield the same benefits nor outcomes. As an aside, a fantastic resource for all things vSAN ESA can be found on the vSAN ESA TechZone page, which I highly recommend bookmarking as there is a lot of in-depth technical resources and collateral.

Disclaimer: This is not officially supported by VMware and is purely for educational purposes, use at your own risk.

[Read more...]