My lab printed this at 19:04 on a Friday, forty minutes into an activation that had already deployed three control plane virtual machines and was sitting at 68 percent:

Nothing in that message names a license and nothing in it names a product version, yet both were the cause. I had chosen NSX VPC as the workload network on an estate whose Avi Load Balancer Enterprise entitlement had quietly lapsed, and NSX VPC accepts exactly one load balancer provider. That is the shape of Objective 4.1. It is not a wizard walkthrough. It is a compatibility question wearing a runbook costume, and the exam asks it as a matching exercise far more often than as a click exercise.

Five legal pairs behind one activation API

Every activation path in this objective ends at the same place: a POST against namespace-management/clusters on vCenter, driven either by the Activate Supervisor wizard in the vSphere Client, by DCLI, or by a REST call from a pipeline. What differs between paths is not the verb. It is the payload, and more importantly the set of objects that must already exist before the payload is legal. A Supervisor is a single object that inherits its network model, its address ranges and its load balancer for life, and every namespace, VM class binding and VKS cluster you create later inherits those choices in turn. Get this call wrong and you are not troubleshooting a cluster three weeks from now, you are rebuilding a Supervisor.

Start from the compatibility grid rather than the wizard. Three workload network types exist: vSphere Distributed Switch, NSX Segment and NSX Virtual Private Cloud. Three platform load balancer providers exist: Foundation Load Balancer, NSX Load Balancer and Avi Load Balancer Enterprise. Nine combinations are conceivable. Broadcom supports five. Four of the nine will let you get as far as a summary page and then fail, which is precisely why the failure above looked so unhelpful.

Print this table and keep it next to you. It is the reference artifact for this Part, and it answers roughly half of what Objective 4.1 can ask.

Foundation Load Balancer and NSX Load Balancer are Layer 4 only. Avi Enterprise adds Layer 7, web application firewall, analytics and global server load balancing at the platform level, and it carries a separate license.

Time cost differs sharply between those five pairs, and it is worth knowing before you plan a rebuild session. I activated and disabled each pair three times on the reference estate and took the median wall clock from clicking Finish to kubernetes_status: READY. Avi in the path adds roughly a quarter of an hour every time, because the Service Engines have to be placed, powered on and registered before the control plane virtual IP answers.

Preflight that changes with the networking model

Where we left the estate: Part 14 activated a single Supervisor on the workload domain with VCF Networking and VPC. For this Part I disabled it, so we start from a clean workload domain with three vSphere Zones mapped to three clusters, NSX in place, Avi Controller reachable, and vSAN offering two storage policies. Everything below assumes that starting point.

Stamp your versions first. Half of the confusion candidates bring to this objective comes from following a guide written against a different build.

An empty result from clusters list is the correct pre-activation state. Once activation begins, that same command becomes your progress meter, and it is far more honest than the percentage bar in the client.

Anything carrying overlay traffic needs an MTU of 1700 or greater, and NSX takes 1700 as its global default. This single check catches more stalled activations than any other, because a Supervisor on NSX will happily deploy three control plane virtual machines and then never bring their networking to a ready state. Validate it before you click anything. NSX transport preparation itself belongs to the NSX series and I will not repeat it here.

Address planning is where the five paths genuinely diverge. Reserve five consecutive management addresses in every case, as Part 14 established, and then add whatever the workload network demands on top. This is the numbers table for the objective.

Activation procedure for each supported pair

Order matters here and the exam knows it. Run these steps in sequence and the path you chose only changes what happens inside step three.

flowchart TD
  A[Is NSX deployed on this workload domain] -->|no| B[vDS workload network]
  A -->|yes| C{Do you need per tenant isolation and zero IP overlap}
  B --> D{Do you hold an Avi Enterprise license}
  D -->|no| E[vDS plus Foundation Load Balancer]
  D -->|yes| F[vDS plus Avi]
  C -->|no| G{Avi Enterprise license held}
  C -->|yes| H[NSX VPC plus Avi, VKS 3.3.1 required]
  G -->|no| I[NSX Segment plus NSX Load Balancer]
  G -->|yes| J[NSX Segment plus Avi]

Step 1. Confirm the entitlement before touching the cluster. Foundation Load Balancer ships with vSphere Foundation or VCF. NSX Load Balancer needs VCF. Avi Enterprise is a separate license and its absence is not detected until activation is already running. Check it first and you save yourself the forty minutes I lost.

Step 2. Pre-create the network objects from the numbers table above. For NSX VPC that means a connectivity profile with a transit gateway and both IP blocks defined before the wizard opens, because the wizard offers you existing profiles rather than creating them.

Step 3. Start activation. In the vSphere Client, right click the target cluster and choose Activate Supervisor, then pick zones, storage policy, network provider and load balancer. For a repeatable estate, drive the same operation through the API instead.

Only two stanzas of that JSON body change between the five paths, the workload network provider and the load balancer block. Everything else, zones, storage policy, control plane size and content library, stays identical. Confirm the exact field names against the namespace management API reference for your vCenter build before you script it, because the spec has been renamed between releases [VERIFY].

Step 4. Watch the reconciler, not the progress bar. Poll clusters list every thirty seconds. A config_status of CONFIGURING with a slowly changing message is healthy. A config_status of ERROR is not, and it will sit there indefinitely rather than rolling back.

Step 5. Register the load balancer trust when Avi is in the path. This is the single most common Avi failure and it is entirely avoidable.

Verification, rollback and failure signatures

Green is three things at once: a RUNNING config_status, a READY kubernetes_status, and three control plane nodes answering kubectl. Two out of three is a Supervisor that will disappoint you the moment somebody creates a namespace.

Rollback has exactly two gears and no middle one. If activation is stuck in ERROR and nothing has been consumed yet, correct the underlying condition, certificate, MTU, license, and the reconciler retries on its own. If the choice itself was wrong, network provider or an immutable CIDR, then disabling is the only route, and disabling destroys every namespace, every VKS cluster and every persistent volume claim on that Supervisor. Treat the second command below as irreversible.

Six failures account for nearly every activation that goes wrong on this estate. Learn the message, not the screenshot.

Exam focus for objective 4.1

Study advice you will hear and should ignore: build one Supervisor, learn the wizard, move on. That produces a candidate who can click confidently through a single path and freezes on the other four. Objective 4.1 is plural in its own wording. Build the cheap one repeatedly instead. At twenty six minutes for vDS with Foundation Load Balancer, you can activate, verify, disable and reactivate three times in a two hour session, which is worth more than a single perfect NSX VPC build you never take apart.

Objective checkpoint

Activation path call for this estate

For the reference estate, three zones, NSX with VPC enabled and Avi already in the path, my pick is NSX VPC plus Avi. It gives per tenant address isolation without hand carving CIDRs, it is the model VCF Automation expects, and at thirty seven minutes it is not the slowest path despite being the richest. Pair to avoid: vDS plus Avi. It pays the full Avi Enterprise license and the full forty one minute activation while giving up NSX segmentation entirely, and I have yet to see a design where that trade made sense outside a proof of concept with no NSX available.

A clean result looks like this: config_status RUNNING and kubernetes_status READY from clusters list; three control plane nodes Ready under kubectl get nodes; at least one release listed by kubectl get tkr; the control plane VIP answering kubectl vsphere login from a workstation outside the management network; and a change ticket that names the pairing in words. If any one of those five is missing, you have an activation that succeeded on paper and will fail on the first namespace.

Tonight, do one thing in your own lab. Activate a Supervisor on vDS with Foundation Load Balancer, time it, disable it, and reactivate on a different legal pair. Two activations and one disable will teach you more about Objective 4.1 than a week of reading, and you will never again mistake a licensing gate for a networking fault. If you arrived here from a TKGI estate, the migration path is covered separately in the TKGI to VKS series, and the product level walkthrough of everything above lives in the VKS series. Next Part moves off the Supervisor itself and into carving it up, namespaces and zones under Objective 4.2.

References

• Load Balancing in vSphere 9.0+ and VMware Cloud Foundation 9.0+, VCF Blog, July 2026
• Top 10 vSphere Kubernetes Service Activation Questions, VCF Blog, August 2026
• Requirements for Supervisor Deployment with VCF Networking with VPC, Broadcom TechDocs
• VCAP-VKS 3V0-24.25 exam guide, revision 11/14/2025 [VERIFY]

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