You do not choose a load balancer for vSphere Supervisor. You choose a workload network, and the workload network hands you a shortlist you are then stuck with. Candidates who study this objective as a load balancer comparison get the causality backwards, and the exam punishes that specific inversion more than it punishes any missing feature fact.

Networking stack decides your load balancer, not the reverse

Broadcom documents three workload networking models for Supervisor and three platform load balancers, and the two lists do not form a free grid. Foundation Load Balancer is available on VDS only. NSX Load Balancer is available on NSX Segment deployments. Avi Load Balancer Enterprise is the only option that spans all three, and on NSX VPC it is the option Broadcom names when it walks through selection by workload network. Read that asymmetry once and most of the objective falls out of it: if a scenario tells you the estate runs NSX VPC and the customer refuses to buy an Avi Enterprise entitlement, the correct answer is not a different load balancer, it is a different workload network.

Something else follows from the same asymmetry and it is the part experienced admins skip. Platform load balancer choice governs Layer 4 connectivity for Supervisor managed objects: VM Service virtual machines, vSphere Pods, and VKS cluster control plane endpoints. It does not govern what application teams do inside a VKS cluster. A VKS cluster is upstream conformant, so a team can run Contour, Istio or a Gateway API implementation inside the cluster regardless of whether the platform underneath is FLB, NSX-LB or Avi. Scenario items lean on that separation constantly, usually by describing a Layer 7 requirement that sounds like it forces Avi and does not.

Here is the artifact worth keeping. Print it, stick it above your desk, and stop reading load balancer datasheets. One honest caveat on the VPC row: Broadcom’s own July 2026 selection guidance names Avi for NSX VPC, while the summary table lower down that same post also lists NSX Load Balancer against VPC. I have built the row from the selection guidance because that is the section written to answer this exact design question, and I would confirm against your build before committing a design document to either reading.

flowchart TD
  A[Workload network chosen at activation] --> B[VDS]
  A --> C[NSX Segment]
  A --> D[NSX VPC]
  B --> E[Foundation Load Balancer]
  B --> F[Avi Enterprise]
  C --> G[NSX Load Balancer]
  C --> F
  D --> F
  E --> H[Layer 4 only at platform]
  G --> H
  F --> I[Layer 4 and Layer 7 at platform]
  H --> J[Ingress controller runs inside the VKS cluster]
  I --> J

Three stacks, side by side

On VDS, all hosts from every vSphere cluster backing the Supervisor connect to the same distributed switch, and Supervisor consumes distributed port groups as workload networks. One of those is the Primary workload network, which carries Supervisor control plane traffic. You can hand the same network to every vSphere Namespace or give each namespace its own. In a three zone Supervisor on VDS the workload networks span all three zones, which means your namespace level isolation is exactly as good as your port group discipline and nothing more.

On NSX segments, NCP creates one shared tier 1 gateway for system namespaces, then a tier 1 gateway and a load balancer for each namespace by default. Workloads in the same namespace, whether they are vSphere Pods, VM Service virtual machines or VKS cluster nodes, share one SNAT IP for north south traffic. East to west between namespaces is not SNAT translated. That single sentence answers a surprising number of connectivity troubleshooting scenarios, and it comes straight from the Supervisor networking documentation rather than from a blog post.

On NSX VPC, which vSphere Supervisor 9.0 introduced and which needs VKS 3.3.1 or later before a workload cluster can consume it, the tenancy boundary moves up. You get a network container with its own address blocks instead of a per namespace tier 1 assembled by NCP, which is the point of the model. It is also the model where Avi stops being a preference and becomes a dependency. Anyone designing a VPC based estate on the assumption they can fall back to the NSX Edge load balancer is designing a rebuild.

Discovery commands that name your stack

Every command below runs against the reference estate this series has been building since Part 3: one vCenter, one workload domain, three vSphere Zones mapped to three clusters, NSX with VPC networking enabled, Avi in the load balancing path, and vSAN behind two storage policies. Last Part we activated the Supervisor and resized its control plane. This Part we prove which networking stack it actually landed on, because the wizard screenshot in your notes is not evidence.

Log in with the vSphere plugin rather than a raw kubeconfig. Doing it once explains why for the rest of the series: the plugin exchanges your vCenter Single Sign On credentials for a token scoped to the vSphere Namespaces you actually have a role binding on, so what you can see afterwards is itself a diagnostic signal. Read the password from an environment variable, never a flag.

Two namespaces in that list settle the question. Presence of an NSX operator namespace means this is an NSX backed Supervisor rather than a VDS one, and presence of an AKO namespace means Avi is doing the load balancing rather than the NSX Edge. A VDS Supervisor using Foundation Load Balancer shows neither. Namespace naming does move between releases, so treat the exact strings as a signal to confirm in the vSphere Client under Workload Management, not as an API contract. [VERIFY] against your own build before you quote it in a design document.

Now the failure you will actually meet. A LoadBalancer Service in a vSphere Namespace sits at pending forever, and the deployment above it looks perfectly healthy.

Nine retries over fourteen minutes and not one of them mentions the workload. Wording of that final message varies by load balancer provider and release, but the reason string SyncLoadBalancerFailed is stable and is where you should start. Trace it back to the Supervisor object that caused it, which in this case is the address range you typed into the activation wizard and have not thought about since. That habit, always walking a VKS symptom back to a Supervisor input, is the single most transferable thing in this series.

Avi disqualifiers nobody reads until change control

Broadcom publishes four conditions that must all hold before you can configure Avi on an NSX backed Supervisor: NSX at 4.1.1 or later, Avi at 22.1.4 or later with an Enterprise licence, an Avi controller already registered on NSX, and no NSX load balancer already configured on that Supervisor. Two more constraints sit alongside them and are easier to trip over because they are properties of your vCenter rather than your Kubernetes estate. You cannot deploy an Avi controller in a vCenter Enhanced Linked Mode deployment, only a single vCenter. You cannot configure Avi against a multi tier tier 0 topology, and if your NSX is built that way you may use only one tier 0 gateway.

Cold start is the other Avi behaviour that catches people, and it is documented rather than a bug: a Service Engine is only created after the first virtual service is configured, and every subsequent virtual service reuses it. I timed this on the reference estate, three runs each, wall clock from kubectl apply to an external IP appearing in the Service.

That 372 second figure is where popular study advice gets it wrong. Forums will tell you Avi is slow to provision services and to prefer NSX-LB for latency sensitive platforms. Steady state says otherwise: 41 seconds against 34 is inside the noise of my measurement, and the gap only exists on the very first virtual service in a Service Engine group. Choosing NSX-LB to avoid a one time six minute cost, and giving up WAF and analytics permanently to do it, is a bad trade made with a real number attached to the wrong end of it.

Exam focus for objective 2.2

Objective checkpoint

Load balancer pick for the reference estate

My verdict for a greenfield VCF 9.0 estate that already owns NSX: go NSX VPC with Avi Enterprise, and budget the licence at design time rather than discovering it at activation. VPC is where the tenancy model is heading, Avi is the platform load balancer Broadcom names there, and paying for it up front avoids the rebuild I described above. Avoid activating on NSX segments with the NSX Edge load balancer purely because it is already sitting in the estate, which is the default a lot of teams drift into. It is the cheapest path to a Supervisor and the most expensive path to a second opinion six weeks later.

On VDS with no NSX in the picture, Foundation Load Balancer is the right default and it is included with both VVF and VCF entitlements, so the only reason to add Avi on VDS is a genuine platform level Layer 7, WAF or GSLB requirement that application teams cannot satisfy inside their own clusters. Product mechanics for any of these components live in the VKS Series, and the full objective by objective map for this exam sits on the VCAP-VKS guide. If you arrived here from a TKGI estate, the migration path is a separate story told in the TKGI to VKS Series.

Tonight, in your own lab: run the namespace discovery above, write down which of the three stacks you are actually on, then create one LoadBalancer Service in an empty namespace and time it. If it returns in under a minute, your Service Engine was already warm and you have just learned something about your estate that no screenshot would have told you. Next Part takes the same Supervisor and turns to storage policies and persistent volumes across zones.

References

Supervisor Networking, Broadcom TechDocs, VCF 9.0
Load Balancing in vSphere 9.0+ and VMware Cloud Foundation 9.0+, VCF Blog, July 2026
VMware Cloud Foundation VKS Administrator Exam Guide, 3V0-24.25

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