Enablement decisions you cannot take back

Five is the number that decides whether your activation runs clean. Not three, which is what almost everyone reserves, because a Supervisor has three control plane virtual machines and three feels like the obvious answer. Broadcom documents a block of five consecutive management addresses: one for each control plane VM, one floating address that moves to whichever control plane VM is currently the etcd leader, and one held in reserve so a failed control plane VM can be replaced without another trip to the address management team. Reserve three, and nothing rejects you at the time. You discover the gap forty minutes later when Config Status has not moved off Configuring and no error has been raised.

Objective 3.4 asks you to create the process of enabling a Supervisor cluster, and the word process is carrying the weight in that sentence. Nobody is checking whether you can find the Get Started button. What is being checked is whether you know which inputs are gathered before the wizard opens, which order they are consumed in, which of them are permanent, and what evidence proves the activation actually succeeded rather than merely finished. A candidate who has only ever clicked through a lab build tends to know the screens and none of the consequences.

Everything downstream inherits this hour. Namespaces inherit the workload network and its address pools. Storage classes inherit the policies you attach. VM classes, content libraries, Supervisor Services and every VKS cluster anyone provisions later all sit inside a boundary you drew during activation. When a workload cluster refuses to come up in Part 20 or Part 30, the honest first question is almost never about the cluster. It is about which Supervisor object was configured wrongly at activation and has been quietly wrong ever since.

One naming note, said once and then left alone. VKS is the product formerly called TKG Service or TKGS, and the rename stopped at the marketing layer. You will see tkg in resource short names, API groups and log paths throughout this procedure, and it does not mean you are looking at a deprecated product. It means the plumbing was never renamed.

Enablement decision lock table. Print it, fill it in before the wizard opens, and keep it with the build record.

Preflight checks before the wizard opens

Pin your versions first, because half the study material you will find online was written against vSphere with Tanzu on vSphere 8 and the screens have moved.

Now prove the estate rather than assuming it. Four checks catch most of what goes wrong: vCenter build, the target clusters and their zone mapping, at least one storage policy that the control plane VMs can actually land on, and forward DNS for the name you intend to use as the API server address. Read the vCenter password from an environment variable so it never lands in your shell history or a build document.

That last line matters more than it looks. Login to a Supervisor by fully qualified domain name is required to avoid certificate problems, because Server Name Indication is used to present the correct certificate to incoming requests, and the certificate only carries names you declared. On my first run of this build I skipped the API Server DNS Names field on the Advanced Setting page, pointed DNS at the address anyway, and got this on the first login attempt.

Recoverable, because API server DNS names can be edited afterwards and the certificate regenerates. It still cost an API server disruption on a cluster I had just told people was ready, which is a bad first impression to make on a platform team. Type the FQDN into the wizard.

Activation procedure with VCF Networking and VPC

VPC is the recommended workload network for a VCF stack and it is the supported network stack for VCF Automation, so it is the path this series builds on. Three prerequisites gate it: the general Supervisor cluster prerequisites are met, the Centralized Gateway is configured, and Avi is installed if you want it, because NSX falls back to the NSX Edge load balancer when it does not detect Avi.

flowchart TD
  A[Preflight, versions, zones, storage policy, DNS] --> B[vCenter Server and Network, pick VPC stack]
  B --> C[Supervisor location, zones and storage policy]
  C --> D[Management Network, five address block]
  D --> E[Workload Network, NSX project and connectivity profile]
  E --> F[Advanced Setting, control plane size and DNS names]
  F --> G[Export configuration to JSON]
  G --> H[Finish, control plane VMs deploy]
  H --> I{Config Status reaches Running}
  I -->|yes| J[Verification, login, nodes, services]
  I -->|no| K[wcpsvc log, fix, retry is automatic]
  K --> I

1. Open Supervisor Management from the vCenter home menu and click Get Started.
2. vCenter Server and Network page. Select the vCenter system, then select VCF Networking with VPC as the networking stack. This is the single most irreversible click in the whole wizard.
3. Supervisor location page. Enter a Supervisor name, tick Enable control plane high availability, choose the data center holding your zones, and select a compatible vSphere Zone. Cluster Deployment places the Supervisor on one Management Zone and gives host level high availability for the control plane. A three zone deployment makes all three mapped vSphere clusters into one Supervisor and puts one control plane VM in each zone, which is cluster level high availability. Control plane HA is mandatory on a three zone activation. One caveat worth memorising: in VCF 9 you cannot select a management network per control plane node in the vSphere UI, because that requires a shared vSphere Distributed Switch, so you must use the API for that case.
4. Storage policy. Select the policy for placement of the control plane VMs. On the reference estate this is vks-silver-default, backed by vSAN.
5. Management Network page. Choose DHCP or Static. In DHCP mode the floating IP requires a DHCP server that supports client identifiers, because all control plane VMs use stable DHCP client identifiers. In Static mode you enter the block of five addresses, the subnet mask, the gateway, DNS servers, DNS search domains and NTP servers. Changing control plane VM addresses or the floating IP afterwards is not supported.
6. Workload Network page. Select the NSX Project, the VPC Connectivity Profile, the Private (VPC) CIDRs from which private subnets are allocated, a DNS server and the NTP servers that NSX Manager uses. Note a VCF 9.0 behaviour change: on a new Supervisor, if the same DNS servers are shared between management and workload networks, control plane DNS lookups route through the management network, where an existing Supervisor keeps routing them through the workload network.
7. Advanced Setting page. Set Supervisor Control Plane Size, enter the API Server DNS Names, and use Export Configuration to produce a JSON file of everything you just entered.
8. Click Finish. Activation now creates and configures the control plane VMs and the rest of the components. Kubernetes, Velero and VM Service are enabled as part of that process.

Export Configuration is the step people skip and later wish they had not. That JSON file is your only faithful record of what was entered, it can be edited and imported to redeploy the same Supervisor, and it is the fastest way to stamp a second Supervisor with matching settings. Treat it as a build artifact and commit it next to your infrastructure code.

Write out the management block explicitly before you touch step five. Ambiguity here is what produces the forty minute silence.

Storage is 32 GB at every size, so the only levers are CPU and memory, and both move in one direction.

Verification and what green looks like

A Config Status of Running in the vCenter UI is necessary and not sufficient. Prove it from the client side, using kubectl with the vSphere plugin rather than a raw kubeconfig, because the plugin is what exchanges your vCenter Single Sign On credentials for a token and writes contexts for every namespace your account can see. That token exchange is exactly what breaks when the certificate or the identity provider is wrong, so making it the first verification step tells you two things at once.

Three control plane VMs with UUID style names, plus one agent node per ESX host, is what a healthy single zone activation looks like. On a three zone activation you get the same three control plane nodes, one per zone, and agent nodes from all three clusters. Watch the version strings: control plane nodes report a standard Kubernetes version with a vmware suffix, agent nodes report a Spherelet build, and a mismatch between them is a genuine signal rather than cosmetic noise.

Now the failure you should expect on a freshly activated Supervisor, and the place the tkg naming shows through.

I have watched capable admins raise a support case at this exact line, convinced activation had half failed. It had not. Activation gives you a Supervisor, not a catalogue. Knowing which empty output is normal is a real part of Objective 3.4, because the process does not end at Running and it does not include content library association either.

Rollback paths and enablement failures

Rollback is blunt. Disable Supervisor from the vCenter UI is the only supported way back, and it destroys the control plane VMs, every vSphere Namespace and every workload sitting on them. Nothing about it is a partial undo. This is why the decision lock table matters more than any single command in this Part: the fallback for a wrong permanent choice is a rebuild, and the only cheap moment to catch it is before Finish.

Short of that, activation retries itself. Workload Control Plane on vCenter runs a state machine that keeps reconciling, so fixing the underlying fault often clears the condition without any operator action. Watching that state machine is far more informative than refreshing the UI.

Activation failure to remediation lookup. Four of these eight are consequences of choosing the simplified flow.

Exam focus for objective 3.4

Objective checkpoint

Activation call for this estate

Field note, and it is the reason the chart above has an outlined bar. On a customer build I chose DHCP for the management network, because their DHCP estate was well run and the alternative meant waiting two days for a static reservation. Control plane VMs picked up addresses in about nine minutes and I relaxed. Config Status then sat at Configuring for fifty one minutes with no error anywhere in the UI, while wcpsvc.log repeated a single warning about the floating IP every sixty seconds. Their DHCP server did not honour client identifiers. We tore the whole thing down, waited for the static block, and the second attempt reached Running in twenty six minutes. Total loss was two hours and ten minutes plus a change window I could not get back, over a requirement that is one sentence in the documentation.

My pick for the reference estate is a three zone activation on VCF Networking with VPC, control plane HA on, Small control plane size, and a static block of five management addresses with the API server FQDN entered on the Advanced Setting page. Three zones costs about twelve extra minutes of wall clock and buys cluster level high availability for the control plane, which is the cheapest resilience you will ever purchase on this platform. What I would avoid is the advice you will read everywhere, that the simplified deployment flow is a fine way to get moving because you can add a load balancer afterwards. For a study estate it is actively harmful. It gives you VM Service and nothing else, which means vSphere Pods, Supervisor Services and persistent volumes, the subject matter of Objectives 4.3, 4.4 and 4.11, simply do not exist on it. You will build muscle memory for a Supervisor that is not the one being examined. Build the full activation, even if it takes an afternoon.

Tonight, in your own lab, do one thing: open Advanced Setting on your existing Supervisor and write down its control plane size, then work out what you would do if it needed to be smaller. If the honest answer is redeploy, you have understood this objective. Readers who want the product level walkthrough beneath the exam view should keep the VKS complete guide open alongside this series, the networking objects behind the VPC fields are covered in the NSX complete guide, and the load balancer sizing that feeds step two lives in Part 11. Part 15 turns to service mesh design on VKS, the last stop in Section 3 before the hands on run of Section 4 begins.

References

• Deploy a Supervisor with NSX VPC, VMware Cloud Foundation 9.0, Broadcom TechDocs
• Limitations of Simplified Supervisor Configurations, VMware Cloud Foundation 9.0, Broadcom TechDocs
• Supervisor Architecture and Deployment Options, VMware Cloud Foundation 9.0, Broadcom TechDocs
• Requirements for Simplified Supervisor Deployment, VMware Cloud Foundation 9.0, Broadcom TechDocs

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts