When vSphere 8.0 Update 1 was released, I noticed an interesting message about containers being installed while deploying the vCenter Server Appliance (VCSA) ...
Interesting ... while runc has been part of the VCSA for a few releases, it looks like it now launches ws1a-broker container in #vSphere80U1 by default ... ws1a-broker = Workspace One Broker? pic.twitter.com/cNVwx2vwFA
— William Lam (@lamw.bsky.social | @*protected email*) (@lamw) April 18, 2023
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.
This was something I had also indirectly discovered when comparing a "Tiny" VCSA deployment between vSphere 8.0 and 8.0 Update 1 release, where I noticed an additional 2GB of memory had been allocated for each deployment size. I confirmed this with Engineering that the additional 2GB of memory was indeed for the vc-ws1a-broker service also known as VMware Identity Single Container Service.
In fact, this very question came up recently on the VMTN communities about this additional 2GB of memory and whether the vc-ws1a-broker service could be disabled if you are not using the feature?
While I will not speak from a support standpoint, but from a technical point of view you can disable the vc-ws1a-broker service and reduce the memory footprint of your VCSA by 2GB if you have no intentions of using the new identity federation features. I currently do this for my homelab setup and that was also the basis of the VMTN post in an effort to reduce the amount of memory needed to run the VCSA.
Disclaimer: Disabling the vc-ws1a-broker service may lead to other unintentional impact, this should not be done in a production environment and GSS support should be consulted if you wish to disable this service.
By default, the vc-ws1a-broker service is configured to automatically start up which you can confirm by using the following command:
vmon-cli -s vc-ws1a-broker
If you wish to disable the service from starting up, you first need stop the vc-ws1a-broker service and then disable it by running the following two commands:
vmon-cli --stop vc-ws1a-broker
vmon-cli --update vc-ws1a-broker --starttype DISABLE
If we re-check the vc-ws1a-broker service, we can now see that it is now disabled and will not start when VCSA boots up.
vmon-cli -s vc-ws1a-broker
Finally, you can shutdown the VCSA and reduce the overall configured memory by 2GB to 12GB which is currently what I use in my homelab.
I was also interested to see whether updating or patching the VCSA would revert the disablement of the the vc-ws1a-broker service. I ran quick experiment by deploying VCSA 8.0 Update 1, disable the vc-ws1a-broker service and then update it to latest VCSA 8.0 Update 1c and it looks to maintain the disabled service, which is good.
With that said, it is possible that in future upgrades, especially when using a migration-based VCSA upgrade, that the default behavior of the VM will be configured with the additional 2GB of memory along with the vc-ws1a-broker service being enabled and you may need to periodically check and update.
Worked perfectly, thanks!