WilliamLam.com

Quick Tip - Using VCF CLI to login to vSphere Supervisor when configured with VCF Automation

by // 1 Comment

When a vSphere Supervisor Cluster is configured to be consumed by VCF Automation, the Identity Provider (IdP) for that vSphere Supervisor is automatically configured to redirect to VCF Automation (VCFA) as an OIDC relay.


When an end user wishes to access or manage their resources, they will be directed to the IdP that has been configured for their Organization Portal. To create a k8s login context, they will need to create a VCFA API token that is then passed to the VCF CLI before they can interact with their resources using kubectl.

Below is an example VCF CLI command where I am logging into an Organization Portal called legal and I have specified my VCFA endpoint along with the VCFA API Token to login as an end user.

vcf context create legal --endpoint auto01.vcf.lab --api-token $VCF_CLI_VCFA_API_TOKEN --insecure-skip-tls-verify --type cci --tenant-name legal

However, if you are an administrator who is managing the underlying VCF Infrastructure and need to troubleshoot or access the vSphere Supervisor Cluster, an alternative workflow will be required.

[Read more...]

Quick Tip - vSphere Supervisor fails to complete due to vSAN Health Check Alerts

by // 1 Comment

I just re-deployed my VMware Cloud Foundation (VCF) 9.0.1 lab setup this evening, and after configuring configuring VCF Networking with VPC, I proceeded with vSphere Supervisor enablement using VPC. I had exported my previous vSphere Supervisor configuration to JSON, so the enablement should have been a no-op but as it was about to complete, I noticed there was this "Apply Solution" vCenter Server task that just kept failing with the following error message:

A general system error occurred: Health Check for 'esx03.vcf.lab' failed


I was really baffled by the error message and what health check was failing!?! I did know the Apply Solution typically would involve EAM (ESX Agent Manager), but I did not see anything out of the blue and I was in the process of filing an internal bug.

While I was waiting for the support bundles to generate and download, I figured I try searching for the keywords in our internal Google Chat in case someone had ran into error before. While there were few matches, there were no follow-ups or resolution. I was about to give up and then I saw a comment from Maher AlAsfar mentioning that if you use vSAN, make sure to silence all vSAN alerts as that is being checked by vSphere Lifecycle Manager (vLCM) as part of its healh check compliance!

Sure enough, I had two vSAN Health Check Alerts!


Once I silenced the vSAN alerts, the Apply Solution task completed immediately, and about a minute later, the vSphere Supervisor enablement also finished.

Quick Tip - Configuring vSphere Supervisor Services with self-signed container registry

by // 2 Comments

When deploying additional vSphere Supervisor Services including the new Data Services Operator enabling Database-as-a-Service (DBaaS), the container images that are used are hosted on Broadcom's container registry (projects.packages.broadcom.com).

For air-gapped deployments where you need to use an internal container registry, there is a process to relocate the Broadcom's container images into your own container registry, which has been possible since vSphere 8.0 Update 3.

While attempting to install the DSM Operator Supervisor Service, which had already been relocated into my standalone Harbor registry, I ran into the classic issue where the self-signed TLS certificate could not be trusted as you can see from the screenshot below.


While the validation error message was clear on why the installation will fail, it did not provide any details on how to actually add the trust the self-signed TLS certificate from my container registry.

After checking internally with a few folks, I was able to resolve this, but it took several attempts. I have already made a request to improve the official documentation to make these steps clearer.

[Read more...]