vSphere Supervisor — Enablement Guide

Enabling a vSphere Supervisor on a VCF 9.1 workload domain. The prerequisites gate states what must exist and the deployment plan carries the stories; this page covers how to enable it, what to check before the wizard, and the field-notes gotchas that cost redo time.

Activation is Day-N and per workload domain — nothing here happens at bring-up. It is also not reversible in any cheap way: several inputs are fixed for the life of the Supervisor, and a decommissioned cluster cannot host a new one (see §8).

Read §1 before anything else. The word centralized means two different things in the 9.x documentation, and picking the wrong one sends you down a path that has no wizard in 9.1.

Planning template — download and fill before the deployment day

One combined, fillable CSV of every input on this page, grouped into sections that mirror this guide (pre-flight · VPC networking · load balancer · Supervisor settings · content libraries · VKS guest clusters · an ordered task list · a firewall matrix). Pick the edition that matches the target build:

A filled copy holds sensitive data (IPs, DNS names, AS numbers, BGP MD5 passwords) — store it securely, never in a public or shared repository.

Credit. This template began as the Config Sheet — vSphere Supervisor created by Albin Qorri (ITQ). It has been reconciled with this guide and extended with the pre-flight, load-balancer and VKS planning inputs.

Contents

Sourcing convention on this page. Statements are marked [documented] where a Broadcom TechDocs page or KB says so, and [field-reported] where the only sources are practitioner blogs. Anything unmarked is ordinary operational advice. The distinction matters here more than usual, because several 9.1 Supervisor pages were withdrawn rather than updated — see §9.

1. Decide the shape first

1.1 The networking paths, and which one this page follows

There are three networking models for a Supervisor in 9.1, and the VPC model splits again into two Transit Gateway modes — so four practical paths:

1. VPC + Centralized Transit Gateway — UI-driven. Covered on this page. Needs a Tier-0 with outside connectivity and an Edge cluster. Load balancer: Avi, or the NSX Edge load balancer.

2. VPC + Distributed Transit Gateway — UI-driven. See §9.1. Needs a VLAN-backed network with outside connectivity and a VNA cluster, and no Edge cluster at all. Load balancer: Avi, or the built-in VPC/VNA one.

3. Classic NSX segment networking — API only in 9.1. See §9.2. Needs an Edge cluster and Tier-0, plus pod / ingress / egress CIDRs. Load balancer: Avi, or the NSX Edge load balancer.

4. vDS networking — UI-driven. Walkthrough in §9.3. No NSX; distributed port groups instead. Load balancer: the Foundation Load Balancer, or Avi. The path for VVF.

The Simplified (“Easy”) flow (§9.4) is a deployment flow, not a fifth networking path — it cuts the starting configuration down and expands afterwards.

Within VPC networking, the two Transit Gateway modes are [documented]:

• Centralized — “attaches the Transit Gateway to a Tier-0 Gateway”; “uses the Tier-0 networking capabilities and services like BGP and requires an Edge Cluster”.
• Distributed — “directly connects to the VLAN of the datacenter without requiring additional configuration on the physical environment”; requires a VNA cluster; “scales out as you add hosts”.

A Transit Gateway must be all-centralized or all-distributed, never mixed [documented].

The word “centralized” is ambiguous — resolve it before you build

Paths 1 and 3 both get called centralized in conversation, and they are not the same thing:

Centralized Transit Gateway (CTGW) is a connectivity mode of VPC networking. The Transit Gateway attaches to a Tier-0 on an Edge cluster instead of to a VNA — but it is still VPC networking, and still the VPC wizard. Fully supported and UI-driven in 9.1.

Classic NSX Segment Networking is the pre-9 model: pod / ingress / egress CIDRs, a Tier-1 per namespace, Edge LB or Avi. The wizard field reads Networking Stack: NSX. Removed from the vSphere Client UI in 9.1 — API only.

They look alike from a distance — both want an Edge cluster and a Tier-0, and both are “the one with the Edges” — but they use different wizards, different CIDR models, and in 9.1 only one of them has a wizard at all. Verbatim, from the vSphere Supervisor 9.1 release notes [documented]:

“Starting with VCF 9.1, the vSphere Client UI no longer supports deploying a Supervisor with classic NSX Segment Networking. Deployment remains fully supported through the API.”

This page documents path 1, the CTGW path. If you need classic NSX segment networking, go to §9.2 first — the plan changes materially.

1.2 Load balancer — you may not need Avi

Supervisor activation requires a load balancer, not specifically Avi. On the VPC path the prerequisite reads [documented]:

Optionally install and configure the Avi Load Balancer; the NSX Edge load balancer is used if NSX does not detect the Avi Load Balancer.

And the choice is exclusive [documented]:

“You can use either the VCF Native Load Balancer or the Avi Load Balancer.”

“You can only use one load balancer. If the Supervisor is configured with the VCF Native Load Balancer, a VPC using the Avi Load Balancer cannot be used.”

So Avi is opt-in, it is detected rather than configured in the Supervisor wizard, and it is one or the other — committing the Supervisor to the native load balancer rules Avi out for VPCs under it, which is a decision to make before activation rather than after. Choose it only when you have a reason — an existing Avi estate, L7 ingress requirements, or a VCF Automation deployment already fronted by it. Otherwise the built-in path needs no extra appliance, no extra licence and no extra failure domain.

The licensing trap. An Avi Controller that cannot have licences attached blocks activation just as hard as one that was never deployed. Avi 9.1 introduces a new subscription licence file format replacing 25-character serial keys, with a 90-day grace period on the move to 32.1.1 [documented]. If a licence migration is in flight, settle it before the deployment day or plan to use the built-in load balancer.

1.3 Zones — and what a stretched cluster gives you

Latency between clusters in a zone: 100 ms maximum [documented].

A vSphere Zone is an object you create in vCenter — before activation, not during it. The activation wizard only selects zones (§6, screen 2); it does not create them. Skip this and you reach screen 2 with an empty picker and no way forward. Create them first [documented]:

1. “In the vSphere Client, navigate to vCenter”
2. “Select vSphere Zones”
3. “Click Add New vSphere Zone”
4. “Name the zone, for example zone1 and add an optional description”
5. “Select a vSphere clusters to add to the zone and click Finish”
6. “Repeat the steps to create three vSphere Zones”

One cluster per zone. Two constraints that are easy to miss, both [documented]:

• “All clusters in a zone must be connected to the same vSphere Distributed Switch”
• vSphere HA and DRS enabled per cluster — DRS on Fully Automated for the Supervisor itself (see the pre-flight gate)

Decide single vs three zone before you activate — there is no conversion. “A Supervisor deployed in a single-zone configuration cannot be converted to a multi-zone deployment after enablement. You must determine the target deployment model before initiating the Supervisor enablement process” [documented]. You can add further zones to an already multi-zone Supervisor afterwards and assign them to vSphere Namespaces — up to three per namespace — but you cannot promote a single-zone Supervisor into one.

A stretched vSAN cluster does not give you a multi-zone Supervisor [documented]:

“The supported Supervisor deployment on a vSAN stretched cluster is a single-zone Supervisor, where the underlying vSphere cluster is a vSAN stretched cluster.”

and

“You can only use a greenfield deployment for a Supervisor running on a stretched vSAN cluster starting from the vSphere 8 Update 3 release.”

Two consequences worth stating plainly to whoever is expecting resilience: Kubernetes sees one zone, so you get vSphere-level HA across sites but not Kubernetes-level zone awareness; and there is no conversion path — you cannot stretch your way into it later.

Not documented for the stretched case: Edge cluster and Tier-0 placement across sites, Avi Controller and Service Engine placement across AZs, and Service Engine Group host-group affinity per site. Decide these deliberately and record the reasoning.

Sources: Supervisor architecture with VPC networking · Supervisor 9.1 release notes · Supervisor on a vSAN stretched cluster · Create vSphere Zones for a multi-zone deployment with VPC

2. Pre-flight gate

Verify — do not accept assurances. Each of these has failed a real activation. The planning template (9.1 · 9.0) carries every row below plus the build inputs from §3–§5 as one fillable sheet — fill it with the owning teams (Architect, Network, Platform, PKI, Depot) well before the day.

Platform

• Workload domain healthy in SDDC Manager, no in-flight LCM tasks
• vSphere Zones created in vCenter — one cluster per zone, three zones for a multi-zone Supervisor or one compatible cluster for single-zone. They must exist before activation; the wizard selects them, it does not create them. All clusters in a zone on the same vDS. See §1.3 — and note the single- vs multi-zone choice is irreversible
• DRS enabled and in Fully Automated mode — “must be in Fully Automated mode” [documented]. The failure symptom is not documented; treat the requirement as absolute
• vSphere HA enabled on the target cluster
• Hosts per cluster — two Broadcom pages give different numbers because they’re answering different questions; both [documented]: - With vSAN, the two sources agree: minimum 3 hosts, 4 for HA. - Without vSAN the general Supervisor requirements page gives a technical minimum of 1 host (3 recommended); the vSphere Zones creation page instead gives production guidance of 2 hosts for NFS/FC storage, 4 for HA. Test/POC environments only need 1 host (2 with vSAN) per the zones page. Treat 3 without vSAN / 4 with vSAN as the safe baseline for a production build unless you have a specific reason to run leaner - 8 CPU / 64 GB RAM minimum per host, stated on the requirements page and unchanged across both sources
• Host names are lowercase — “Otherwise, the activation of the Supervisor might fail” [documented]. Cheap to check, ugly to diagnose
• Storage policy selected for control-plane VM placement, and compatible with the target datastore
• NTP configured on all ESX hosts and vCenter; DNS reachable

Addressing

• 5 consecutive static IPs free on the management network — 3 control plane VMs, 1 floating IP, 1 held for rolling upgrade. Ping them; do not trust the spreadsheet
• Management network and workload network are on different subnets [documented]
• Service CIDR chosen, overlapping nothing — other Supervisors, fleet networks, or the VPC blocks
• API server FQDN chosen, with forward and reverse DNS records in place before activation
• IPv6 is not supported — plan IPv4 [documented]

Networking (CTGW)

• Edge cluster deployed and healthy, minimum two Edge nodes, Large form factor [documented]
• Tier-0 up, BGP established, routes exchanged in both directions
• VPC External IP Blocks — routable and advertised upstream
• Private (Transit Gateway) IP Blocks — see the sizing caveat in §3.3
• MTU 1700 end to end (see §8 — the docs contradict themselves here)
• Supervisor management network reaches vCenter and the host management vmkernel (Spherelet) [documented]

Load balancer and content

• Load balancer decision made per §1.2
• If Avi: Controller cluster healthy in the management domain, licensed, registered, and Default-Group configured — see §4
• If Avi via VCF Operations: the required post-deploy config is done — an SE management network built on NSX and selected in the Avi cloud (the NSX Cloud connector goes red until it is — “management transport zone ””), vCenter registered on the cloud for SE placement, and the Service Engine Group Default-Group with a storage policy (§4.5). IPAM is not required in VPC — the VIP comes from the VPC External IP Block (§3.3)
• If Avi: the certificate is correct for your deployment model — on VCF-Ops-managed Avi, VCF Operations generated it and the NSX cloud connector is green (do not touch it by hand); on standalone Avi, you created it with CN + SAN matching the endpoint you give Supervisor (§4.4)
• Supervisor Images content library created and assigned — a hard prerequisite: since VCF 9 the Supervisor release images ship separately from vCenter (§5.1)
• VCF Software Depot configured in vCenter — this is what the libraries subscribe to, and what auto-creates the VKS library at first enablement (§5.2)
• The depot actually holds the content — a separate question from whether the depot is configured, and the usual cause of a library that syncs but is empty. Check the SUPERVISOR path first, then VKR (§5.4)
• Container image registry reachable from the workload / node networks — projects.packages.broadcom.com:443 direct, via proxy, or relocated into the VCF Software Depot OCI registry (air-gapped). A separate decision from the depot, and it is the workload networks that need the path, not just management (Container image registry connectivity; proxy / air-gapped walkthroughs in 20-supervisor-image-registry.md)

Sources: Deploy a Supervisor with NSX VPC · Requirements for Supervisor deployment with NSX (9.0) · Requirements for Supervisor deployment with NSX VPC · Supervisor architecture with VPC networking · Create vSphere Zones for a multi-zone deployment with VPC

3. Build the Centralized Transit Gateway

Skip this section if the Edge cluster and Tier-0 already exist and carry production routing — but still confirm the IP blocks in §3.3.

The guided wizard builds the Edge cluster, the gateway and the IP blocks in one flow. Field list [documented]:

3.1 Edge cluster

Per Edge node: node name, vSphere cluster, resource pool, Edge host affinity (yes/no), management IP allocation (static — port group, a unique management IP CIDR per node, default gateway), overlay networking, active/standby pNICs, TEP VLAN ID, and TEP IP allocation (DHCP, IP pool, or static list) with gateway and subnet mask.

Edge host affinity is worth a deliberate decision on a stretched cluster — it is what keeps both Edge nodes from landing on the same site.

3.2 Gateway and BGP

The HA modes are not a free choice, and the two layers differ. Verbatim [documented]: “VCF 9.1 supports a tier-0 gateway in Active/Active configuration and a Centralized Transit Gateway in Active/Standby configuration with the required stateful services such as NAT for the Supervisor.” The Transit Gateway is active/standby because it carries stateful services; the Tier-0 beneath it is active/active. If someone reports “the Tier-0 had to be rebuilt as active/standby”, that is the classic NSX segment path or a different design constraint — it is not this one.

Per Edge node uplink: gateway interface VLAN, gateway interface CIDR, BGP peer IP, BFD toggle, MTU (valid range 1600–9000), BGP peer ASN, and BGP peer password.

Get the BGP peer password and ASN from the network team in writing before the day. A silent BGP session is the single most common reason this stage stalls, and the peer side is rarely yours to inspect.

3.3 The IP blocks, and the /16 question

Two blocks are configured here [documented]:

• VPC External IP Blocks — “Advertised CIDRs that allow outside connectivity to VPC workloads”. These must be routable and advertised upstream. With Avi in VPC mode this block is also the load-balancer VIP source — Avi IPAM is not used in VPC, so the Supervisor API VIP and every LoadBalancer Service VIP come from here. Size it for the VIPs you expect, and make sure it exists and has free space before activation (see §4.5).
• Private (Transit Gateway) IP Blocks — “Private CIDRs that are available for inter-VPC communication”.

Broadcom documents no minimum prefix size for either block. The wizard pages ask for both and state no sizing. The 9.0 page that carried a VPC requirements table has been withdrawn — it now returns 404 and is delisted from both the 9.0 and 9.1 books.

The /16 claim — [field-reported], not documented. Multiple practitioner blogs report that in 9.1 the private transit gateway block must be a /16, where 9.0 accepted a /24, and that with a /24 the deployment never completes rather than failing cleanly. There is no TechDocs statement and no KB behind this. It is reported independently by more than one author, the failure mode is expensive, and a /16 of private space costs nothing — so size it /16 and treat a hang at this stage as evidence. Do not present it to a customer as a documented requirement.

3.4 Creating the External IP Block and attaching it to the profile

The External IP Block is the VIP source (§3.3), and it must both exist and be referenced by the VPC Connectivity Profile before activation, or the wizard marks the profile (incompatible) and the External IP Blocks table shows No items found. [field-verified 2026-07-23]

Create the block — two routes, same result:

• NSX Manager — Networking → IP Management → IP Address Pools → IP Address Blocks → Add IP Address Block: Name, CIDR (routable external range), Visibility = External (the tooltip: “Required for blocks to be consumed in Projects and VPCs”), leave Reserved for Specific Subnet = No.
• vSphere (VCF-integrated) — vCenter → Networking → Network connectivity; this creates the NSX block and wires it into the profile in one place, which is the cleaner route on a VCF-Ops-managed NSX.

Attach it to the VPC Connectivity Profile (the object the activation wizard reads — do this if you created the block directly in NSX): VPCs → Profiles → VPC Connectivity Profile → edit the Default VPC Connectivity Profile → add your block to External IP Blocks (max 5), confirm the Private (Transit Gateway) IP Blocks lists your Day0 Private Tgw Ip Block, and set the Edge Cluster.

The same block can also appear on the Transit Gateway’s External Connection (VPC Connectivity → External Connections → External IP Blocks). That field defaults to “All External IP blocks allowed” — adding one block there turns it into an allow-list of only the listed blocks, so make sure every external block the TGW needs is present, not just the new one.

Default Outbound NAT — a decision, not a requirement. On the profile’s VPC Service Gateway Configurations, Default Outbound NAT governs workload/pod egress SNAT only (not the Supervisor control plane, which rides the management network) [field-verified 2026-07-23]:

• On → workloads are SNAT’d outbound via an external IP; you must then set External IP Block for Default Outbound NAT. Use this when workloads have private IPs and need outbound reach.
• Off → workloads egress with their own private/transit IPs, which must be routable/advertised to whatever they need. Cleaner for a routed or air-gapped estate, and it removes the NAT-block field.

Either way the VIP still comes from the External IP Blocks field — NAT is orthogonal. If On but the NAT block is unset, that alone makes the profile (incompatible).

The wizard caches NSX state. After any of these NSX/profile changes, cancel and relaunch the activation wizard — an (incompatible) profile or an empty External IP Blocks table is very often just stale wizard state from before the change.

Sources: Configure the Centralized Gateway · Supervisor architecture with VPC networking · Add a VPC Connectivity Profile

4. Avi Load Balancer (only if used)

Skip entirely if you are using the built-in NSX Edge load balancer.

First, decide which Avi you are running — this changes everything below. There are two deployment models, and most of this section’s manual steps apply to only one of them:

• VCF-Operations-managed Avi (the 9.1 default). VCF Operations deploys the Controller cluster and owns its whole lifecycle — service-account creation, the NSX cloud connector, Supervisor registration, and certificate generation and trust propagation to NSX Manager and vCenter [documented — 9.1 Avi release notes]. On this model you do not set the VIP in NSX, do not register with NSX by hand, and do not replace the certificate in the Avi UI. The NSX tab System → Appliances → Avi Load Balancer is the NSX-native deploy path — expect it to stay empty, and do not click Set Virtual IP / Add Avi Load Balancer there or you start a second, conflicting Controller. Deploy from VCF Operations → Build → Lifecycle → VCF instances → Manage Components.
• Standalone / NSX-native Avi. You deploy the Controller yourself and wire it up by hand. §4.2–§4.5 below are written for this model. They come from the 9.0 “Supervisor with NSX and Avi” book, which is the current documentation for the manual path.

The trap that follows from mixing them: on a VCF-Ops-managed Controller, replacing the certificate manually in the Avi UI breaks the trust from NSX, and re-importing the thumbprint by hand does not reliably restore it [field-reported; consistent with the “managed by VCF Operations” banner NSX shows]. If you have already done it, the clean recovery is to revert to the original VCF-Ops-generated certificate (it presents the thumbprint NSX and vCenter already trust); if that cert object is gone, re-drive the certificate through VCF Operations, which regenerates and re-propagates the chain. Only TLS certs signed by VMCA, Microsoft CA, or OpenSSL are auto-renewable this way [documented]. Do the cert lifecycle in VCF Operations, never in the Avi or NSX UI, whenever VCF Operations deployed the Controller.

4.1 Ordering — this is a hard dependency

“If you want to use Avi Load Balancer in VCF Automation, or for vSphere Supervisor load balancing, the Avi Load Balancer Controller cluster must be deployed before you activate vSphere Supervisor in the workload domain.” [documented]

Build order: NSX (transport zones, uplink profile, transport nodes) → Tier-0 → Avi Controller → Supervisor activation.

Deployed is not the same as licensed. Activate the Supervisor only after the Avi licensing chain is finished (endpoint switched to the hub, Used count non-zero). An unlicensed controller lets the Supervisor’s load-balancer objects be created — they look healthy — but does not program the data path, and the Supervisor either stalls on the load-balancer step or comes up with a VIP that silently times out. See 14-avi-load-balancer.md.

4.2 Controller

• Placement: the management domain, always — one set per NSX instance, not one per workload domain. Service Engines are what run per cluster in the workload domain.
• Controller IPs: single node = 1 management IP; 3-node cluster = 4 IPs (one per VM plus a cluster VIP), from the management network [documented]. Three nodes is the production recommendation.
• Versions: vCenter 9.0+, NSX 9.0+, Avi Controller 31.1.1+ [documented].
• Licence: Enterprise or Enterprise with Cloud Services. The Controller starts in evaluation mode and must be moved off it [documented].
• The backup passphrase set in the first-login wizard is a restore-blocker — store it with a named owner, exactly as with the SFTP target passphrase (08-backup-target.md).

4.3 Service Engine Group — set it before activation

Two documented statements that together make this a one-shot setting [documented]:

“The AKO creates one Service Engine Group for each vSphere Supervisor cluster.”

“Changes made to the Default-Group configuration will not reflect in an already created Service Engine Group.”

So Default-Group must be right before you activate. Retrofitting it afterwards does nothing for the Supervisor that already exists. Set HA mode (N+M buffer / active-standby / active-active), the maximum Service Engine count (default 10), and virtual-service placement (Compact, the default, packs onto existing SEs; Distributed spreads across new ones). At least two Service Engine VMs are deployed per Supervisor.

4.4 The Controller certificate — CN and SAN

Standalone Avi only. On a VCF-Operations-managed Controller, VCF Operations already generated this certificate and propagated its trust to NSX and vCenter — do not create or replace it here; doing so breaks NSX trust (see the callout at the top of §4). The steps below are for the standalone path, where you supply the cert yourself.

You must give the Controller a custom certificate before you activate the Supervisor — and the fields on that screen are easy to fill in wrong, because the one that matters is not the obvious one. Verbatim [documented]:

“You must provide a custom certificate to enable Supervisor. You cannot use the default certificate.”

“If you use a private Certificate Authority (CA) signed certificate, the Supervisor deployment might not complete and the Avi Load Balancer configuration might not be applied.”

So a self-signed Controller certificate is the low-risk path for enablement; a private-CA-signed one can make the deployment hang with the Avi side silently unapplied. Create it in the Controller dashboard under Templates → Security → SSL/TLS Certificates → Create → Controller Certificate.

Common Name — the fully-qualified name clients use to reach the Controller, not the Supervisor and not a wildcard. The doc: “this entry must match the hostname that the client entered in the browser” [documented].

• Single-node Controller → the Controller VM’s management FQDN (e.g. avi01.sfo.example.io).
• 3-node cluster → the cluster VIP FQDN, never an individual node.

Subject Alternate Name (SAN) — this is the field that actually gates activation. It must contain the address you later type into the Supervisor wizard as the Avi Controller endpoint. Verbatim [documented]: “Enter the cluster IP address or FQDN, or both, of the Avi Load Balancer Controller … it must match the IP address or FQDN that you specify during deployment.”

The rule that keeps you out of trouble: whatever value you give Supervisor as the Controller endpoint must appear in the certificate’s SAN. The docs explicitly allow “or both”, so put both the FQDN and the IP in the SAN and you cannot mismatch it — for a single node use its FQDN + IP, for a cluster use the VIP FQDN + VIP IP.

Algorithm EC is recommended (2048-bit if RSA); add the SAN entries, enter the cluster IP/FQDN, Validate, then Save. You reference this certificate again when you configure the Supervisor to enable Supervisor Management — it is not a throwaway.

Source is the 9.0 Avi book (the 9.1 Supervisor book points at it by design); the certificate flow is unchanged in 9.1.

4.5 Post-deploy configuration (VCF-Ops path) — what is left to do

VCF Operations deploys the Controller, creates the service account, generates the certificate and propagates its trust, and wires the base cloud connector and Supervisor registration [documented — 9.1 Avi release notes]. That leaves a short, required list of Avi-side configuration you still do by hand before activation — and a longer set of steps that are optional and often mistaken for mandatory because a popular field walkthrough includes them.

Verify before you build. VCF Operations does “cloud connector setup”, so parts of the NSX cloud may already exist. Open Infrastructure → Clouds and Templates → IPAM/DNS Profiles and check what is already there before hand-creating anything — verify-then-fill, do not blind-rebuild.

Required — the gate for a working Supervisor load balancer:

1. Prepare a management network on NSX for the Service Engines — this is the piece people miss [documented; field-verified 2026-07-23]. The SE management NICs need their own network, and VCF Operations does not create it — it leaves the NSX Cloud connector’s Management Network blank for you to fill, because it cannot guess which segment your SEs should sit on. Two parts:

   • On NSX, build the segment first. A management transport zone plus an overlay segment behind a Tier-1 (or a VLAN-backed segment), with an IP pool / allocation for the SE management NICs. This does not exist until you make it.
   • In Avi, select it on the cloud. Infrastructure → Clouds → the NSX cloud → Management Network → pick that transport zone + segment + IP allocation. Until this is set the cloud sits red with the tell-tale “Configured management transport zone ” of type ”” (empty quotes = never set), and no Service Engines can deploy — which surfaces at activation as the load-balancer step stalling (“Unable to acquire IP address for network”, KB 442187). The empty-quotes state is a missing-config error, not a trust/cert error — a cert problem shows as a connection/auth failure instead.
   • The data network still needs a transport zone — but no segments. The cloud config requires you to select a data-network transport zone (pick your workload overlay TZ), but you do not configure data segments or IP pools under it: “Because the VPC handles the Data Network Segment, you do not need to configure it” [documented]. So: data TZ yes, data segments no. The data TZ “does not need to match the zone used for the management network” [documented], and it must be present in the transport node profile of the ESXi hosts where the SEs run (the workload cluster) or the SE data NICs cannot attach.

2. The NSX Cloud connector, in VPC mode — vCenter, a hand-built SE content library, and the template SE group [documented; field-verified 2026-07-23]. Beyond the management network above:

   • Verify the cloud has a vCenter registered for SE placement (where the SE VMs land — the workload cluster; VCF Ops usually sets this, but confirm it).
   • Create the Service Engine content library by hand — VCF Operations does not create this one. Make an (empty) content library on the vCenter and point the cloud’s vCenter config at it; Avi uploads the Service Engine OVA into it and clones SEs from it. No library means no SE deployment. The push is immediate, not lazy [field-verified 2026-07-23] — as soon as you save the vCenter/content-library config on the cloud, Avi pushes the SE OVA into the library. Use it as a checkpoint: after saving, confirm the SE OVA item appears in the library and the SE image path is proven before activation, not discovered mid-activation.
   • Set the Template Service Engine Group on the cloud. Infrastructure → Clouds.

   This SE-image content library is a third library, unrelated to §5. The two in §5 (Supervisor Images, VKS) feed Supervisor/Kubernetes; this one holds the Avi Service Engine OVA and lives on the vCenter/compute side of the NSX Cloud config. Unlike the certificate and the base cloud connector, VCF Operations does not pre-create it — it is a manual step you do before the cloud can deploy SEs.

3. The Service Engine Group — configure the Default-Group as the template [documented]. “vSphere Supervisor uses the Default-Group as a template to configure a Service Engine Group per Supervisor … If no template Service Engine Group is configured in the cloud, the Default-Group is used.” Under Infrastructure → Cloud Resources → Service Engine Group, set the vSphere storage policy (SEs are VMs — no policy, nowhere to deploy), placement scope (compute cluster + datastore; optional VM-group/host-group affinity), HA mode and scaling before activation — AKO clones it per Supervisor and will not retro-apply later changes (see §4.3).

   The storage policy lives on the Service Engine Group, not on the Cloud object [field-verified 2026-07-23] — there is no storage-policy field on the NSX Cloud itself, which is a common place to go looking for it.

   If it is not pinned to shared storage, SEs deploy onto host-local datastores and SE HA / host maintenance break. Fixing it after activation means correcting every per-Supervisor SE Group (AKO does not retro-apply template changes) and relocating the SEs already placed — see 14-avi-load-balancer.md → SEs land on local datastores.

IPAM is NOT required for VPC networking [documented] — an earlier draft of this guide listed a placeholder IPAM profile as mandatory; that is wrong for the VPC path. The VPC-specific docs state plainly “IPAM profiles are: Not required for VPC networking”, because the VIP comes from the VPC External IP Block, not from Avi IPAM. That External IP Block is therefore a real pre-activation dependency — it is the VIP source — and it lives in the VPC connectivity profile you build in §3.3, not in the activation wizard (the wizard only selects it; an empty VPC Connectivity Profile dropdown means it was never built). The generic Getting Started page’s “placeholder IPAM” line applies to non-VPC clouds.

Optional — skip for a basic Supervisor:

• DNS profile + an Avi DNS listener virtual service + external DNS delegation to the Avi VIP — only if you want Avi as a DNS provider or you need GSLB. A Supervisor VIP is reached by IP, so none of this is required to activate.
• The VCF Operations Avi Management Pack — monitoring/observability integration; useful, not a Supervisor prerequisite.
• The single-node feature flag (SSH to SDDC Manager) — only if you are deliberately deploying a single-node Controller instead of a cluster.

The short version: SE management network on NSX (built there, selected in the Avi cloud) + a data-network transport zone + vCenter with a hand-built SE content library + Service Engine Group Default-Group with a storage policy. VIPs come from the VPC External IP Block (§3.3), not IPAM. Everything else a fuller walkthrough shows is done for you by VCF Operations or optional.

Building the overlay SE-management network — the routing tail

Choosing overlay for the SE management network (rather than a VLAN-backed segment) has a consequence worth planning for: the segment sits behind a Tier-1, and the SEs must still reach the Avi Controller — and vCenter/NSX — on the management network. Broadcom’s docs say “identify a segment within either the overlay or VLAN-backed transport zones”; they do not prescribe the routing, because that is your network design. [field-verified 2026-07-23]

If the management network is its own VRF (common), the SE-management overlay has to be routed into that VRF. Your existing CTGW Tier-0 lives in the workload VRF and peers with the workload upstream, not the management VRF — so it is the wrong path. Two ways to give the SE-management network a route into the management VRF:

• A dedicated Tier-0 peering the management VRF, on the existing Edge cluster and uplinks (add management-VLAN uplink interfaces). Cleaner isolation — independent BGP and failover from the CTGW T0.
• A VRF gateway (VRF-lite) as a child of an existing T0, sharing its uplinks via VLAN sub-interfaces. Lighter, but coupled to the parent T0.

The deciding factor is purely Edge uplinks: whichever you pick needs an Edge interface onto the management VLAN. If the Edges can carry it, both work; a dedicated T0 is the tidier choice for a management peering that should be independent.

Three settings that bite on the dedicated-T0 route:

1. Make it Active/Active. Unlike the CTGW Transit Gateway (Active/Standby, because it carries stateful NAT), this T0 does pure routing — no stateful services — so A/A gives both Edges forwarding. Only use A/S if you have a specific stateful reason here (you usually do not).
2. Route re-distribution is OFF by default on a hand-built T0 — turn it on, or BGP advertises nothing [field-verified 2026-07-23]. The guided CTGW wizard sets redistribution for you; a T0 you create by hand does not, so the BGP session comes up Established and advertises an empty route set. Two gates:
   • Tier-1 (SE-mgmt T1) → Route Advertisement → enable All Connected Segments & Service Ports.
   • Tier-0 (new T0) → Route Re-distribution → add a rule for BGP that includes Tier-1 Connected / Connected Interfaces & Segments. Verify with get bgp neighbor <peer-ip> advertised-routes on the Edge — your SE-management subnet must appear there. Established with an empty advertised-set is exactly this gap.
3. Advertise in both directions — the usual miss. Advertise the SE-management subnet outbound to the management VRF, and accept the Controller / vCenter / NSX management prefixes inbound. One-way advertisement looks like a mystery timeout: SEs reach the Controller but replies have no route back (or vice-versa). Confirm the far side with the network team — the mgmt VRF must learn your SE subnet.

Build order: management-VLAN uplink segments → new T0 (A/A) with per-Edge uplink interfaces → BGP to the management-VRF gateway (peer IP + remote ASN + MD5, from the network team in writing, same discipline as §3.2) with bidirectional advertisement → enable route re-distribution on the T0 (BGP, Tier-1 Connected) — it is OFF by default → Tier-1 for SE management, connected to the new T0, advertising All Connected Segments → overlay segment for SE management on that T1 → select it in the Avi cloud’s Management Network with an IP pool.

Test reachability before you touch Avi. From an Edge or a node on the SE-management subnet, confirm you can reach the Controller’s management IP across the new peering. If it works, the Avi side is just selecting the segment; if it does not, it is a routing/advertisement gap at the fabric, not an Avi problem — far cheaper to catch there.

The no-T0 alternative: a VLAN-backed SE-management segment placed directly on the management VLAN puts the SEs in the management network with no T1/T0/peering at all. If the overlay route turns into a fabric project, this sidesteps it — at the cost of consuming a management VLAN on the hosts/Edges.

Post-deploy config sources: Configure the NSX Cloud connector (Avi 9.1) · Getting Started with Avi (9.1) · Amaya Citta — VKS 9.1 with Avi and NSX VPC (the fuller manual walkthrough, incl. the optional DNS/GSLB steps)

4.6 Documented limitations that bite

• “You cannot deploy the Avi Load Balancer Controller in a vCenter Enhanced Linked Mode deployment. You can only deploy the Avi Load Balancer Controller in a single vCenter deployment.” [documented] — check this against your vCenter topology before committing to Avi. In a linked-mode VCF estate this is decisive.
• “Traffic fails for load balancer services with endpoints in a different Namespaces” [documented] — SNAT is used when the SE crosses Tier-1 gateways; DFW rules are needed for cross-namespace communication.
• An Ingress gets no external IP when no host name is specified, when defaultBackend is used instead of a host name, or when the same host name is reused in another namespace [documented].
• Avi provides L4 for Services in both Supervisor and VKS clusters, but L7 for Ingresses in Supervisor clusters only [documented].

Sources: Avi for VCF 9.1 — licence management · Avi for VCF 9.1 — deploy from VCF Operations · Avi for VCF 9.1 — release notes · Install and configure NSX and Avi (9.0) · Configure the Service Engine Group · Limitations of using Avi · Amaya Citta — VKS 9.1 with Avi and NSX VPC

5. Content libraries for Supervisor and VKS images

Two supply chains, don’t conflate them. The content libraries below (§5.1–§5.5) carry the Supervisor OVA / spherelet and the VKS Kubernetes-release artifacts, fed by the VCF Software Depot and synced by vCenter. Separately, the Supervisor and every VKS node also pull runtime container images (Antrea, CoreDNS, metrics-server, the cluster-agent extensions, add-on packages, pause) from Broadcom’s container image registry — a different endpoint, reached from the workload / node networks, with its own online / proxy / air-gapped decision in Container image registry connectivity.

There are two content libraries, not one, and only one of them is a prerequisite to enablement. Conflating them is easy and expensive, so keep them apart:

5.1 The Supervisor Images library — the one you need first

This is the answer to “what do I need before I can deploy a Supervisor at all”. Verbatim [documented]:

“You can use a subscribed content library for Supervisor enablement and upgrade. Starting from VCF 9, the Supervisor releases can be delivered separately from vCenter.”

That last clause is the change worth internalising: in VCF 9 the Supervisor release images no longer ship inside vCenter. They come from a content library you point at the Software Depot.

Get the subscription URL — Developer Center → API Explorer → GET lcm/depot/services, then assemble [documented]:

https://{VcenterLcmDepotServicesAddress}{base_url}/PROD/COMP/SUPERVISOR/lib.json

Note the path component: SUPERVISOR, not VKR. That single word is the difference between the two libraries.

Create it — Content Libraries → Create → Subscribed Content Library → subscription URL → sync mode (Immediately or When needed) → accept the SSL thumbprint → datastore → Finish.

Assign it — Supervisor Management → Content Distribution → Supervisor Images Library → Assign, then select the library [documented]. This is a different screen from where the VKS library is attached (§5.2).

Do not delete or edit a library while it is assigned. Verbatim: “Do not attempt to delete or edit the content library that is assigned with the Supervisor release images. You must unassign the Supervisor release images before you attempt to delete or edit the content library.” [documented]

5.2 The VKS library — for guest clusters, afterwards

This is the one the 9.1 release notes describe, and it is not a prerequisite to enablement [documented]:

“Starting with VCF 9.1, the public CDN (wp-content.vmware.com or wp-content.broadcom.com) is no longer used to create the default VKS content library. Only on vCenter instances where VCF Software Depot is configured in a VCF or VVF deployment, the default VKS content library is automatically created based on the VCF Software Depot endpoint upon the first Supervisor enablement in vCenter.”

So with the depot configured you do not build this one by hand — it is created automatically, from the depot endpoint, at first enablement. Building it manually is the fallback for a deployment without the Software Depot: the depot path is .../PROD/COMP/VKR/lib.json, and without a depot the documented URL is https://wp-content.broadcom.com/v2/latest/lib.json [documented].

Association: Supervisor Management → Supervisors → select the Supervisor → Configure → General → Kubernetes Service → Add (or Remove). Requires vSphere 9.0+ and VKS 3.3+ [documented]. Scope, verbatim:

“The same content library is used for all vSphere Namespaces on a Supervisor instance. For this reason, changing the content library is only allowed at the Supervisor level.”

Per-Supervisor rather than per-namespace, multiple libraries supported, and changeable after activation — unlike most choices in this guide, this one is not one-shot.

Two constraints [documented]: do not add the VKS content library to the VM Service tile; and if a library is deleted from vCenter while still linked to VKS, remove the link before other operations will succeed.

5.3 Air-gapped fallback: publish a local library, and fix the item type

Prefer the offline-depot seeding in §5.4 if you have a depot. This section is the no-offline-depot path — a pure vCenter-to-vCenter publisher. If you run a VCF offline depot (most sites do), seeding the bundle onto it (§5.4) is simpler and avoids this section’s manual item-type / DCLI fix entirely, because the depot bundle ships proper lib.json/items.json. Use §5.3 only when there is no depot to seed. [field-verified 2026-07-23]

For a full air-gapped site with no offline depot, there is a documented publisher flow — build a local, published library on a connected side, then subscribe to it from the air-gapped vCenter [documented]:

“In a full air-gapped environment, where direct internet access is restricted, you must first download the vSphere Supervisor release artifacts on a separate, internet-connected host and then manually upload and publish the artifacts in a content library in your secure environment.”

1. From a connected machine, download the full Supervisor release bundle including lib.json from https://wp-content.broadcom.com/supervisor/v1/latest/. The artifacts are spherelet folders per Kubernetes version (v1.28, v1.29, v1.30, …) containing spherelet-depot-<version>.zip, spherelet-solution-<version>.json, and the Supervisor OVA parts (.mf, .ovf, .cert, .vmdk).
2. In the secure environment: Content Libraries → Create → Local content library, enable publishing, set the OVF security policy, pick a datastore.
3. Import the items — lowest version number first — then the matching OVA files.
4. Fix the item type, or the assign will fail. Verbatim: “Manually uploaded Spherelet artifacts are marked as type file, which causes the Supervisor assign operation to fail. To fix this, the item type must be changed to type other by using the DCLI tool.” [documented]
5. On the library, open the Publication card and copy the subscription URL; subscribe to it from the vCenter(s) that need it.

Step 4 is the one that ambushes people — everything uploads cleanly, the library looks healthy, and the assign fails with nothing pointing at item type.

5.4 Offline depot: configured is not the same as populated

The most likely way to end up with a library that syncs cleanly and contains nothing. A configured Software Depot gives you the plumbing; it does not follow that the depot holds the content.

• The offline-depot documentation describes what it downloads as “VCF component binaries and ESX component data” and “installation, upgrade binaries, ESX binaries, and metadata” — with no mention of Supervisor, VKS or Kubernetes release images anywhere [documented, by absence].
• Practitioners report that in 9.1 the download tool does not retrieve the Supervisor OVA or the Kubernetes release artifacts, with a fix expected in 9.1.1 [field-reported].

So treat “does the depot actually contain the content?” as its own pre-flight question. Check before activation: fetch the depot lib.json for the SUPERVISOR path first (that is the one that blocks enablement), then the VKR path, and confirm each lists items. An empty response is your answer, and it is far cheaper to find now. If it is empty, seed the depot by hand as below (preferred), or use the no-depot publisher flow in §5.3.

Seeding the Supervisor library onto the offline depot — the recipe

Field-verified 2026-07-23, following the Amaya Citta write-up credited below. This is the preferred air-gapped path — simpler than the local-publisher flow in §5.3, and it needs no DCLI item-type fix because the bundle ships proper lib.json/items.json. Use §5.3 only when there is no depot to seed.

1. Download the bundle from the Broadcom Support Portal: My Downloads → VMware Cloud Foundation → 9.1.0.0 → Primary Downloads → VMware vSphere Supervisor → VMware-vSphere-Supervisor-9.1.0.0100-<build>.zip.
2. Extract it under the SUPERVISOR path on the depot web root — this is the path that gates enablement, not VKR:

   mkdir SUPERVISOR && unzip VMware-vSphere-Supervisor-*.zip -d SUPERVISOR
   mv SUPERVISOR /var/www/html/PROD/COMP/

   The bundle carries its own layout, so lib.json and items.json are generated from it — you do not hand-write them.
3. Fix ownership to your web server’s worker user — and read this before copying a chown from any blog. The files are set owner-read-only (0400 files, 0500 dirs), so the owner must be the account the web server runs as:
   • Apache → apache
   • nginx → nginx (RHEL/Rocky) or www-data (Debian/Ubuntu) — check grep -E '^\s*user' /etc/nginx/nginx.conf

   chown <web-worker>:<web-worker> -R /var/www/html/     # apache | nginx | www-data
   find /var/www/html -type d -exec chmod 0500 {} \;
   find /var/www/html -type f -exec chmod 0400 {} \;
   chmod 755 /var/www/ /var/www/html/

   Copying chown apache:apache onto an nginx depot is a real trap. nginx then cannot read a single file, every request returns 403, and the content library “syncs” to empty — straight back into the configured-not-populated state this section warns about. Match the owner to the worker user.

4. Prove the depot serves it before trusting the sync — expect 200, not 403 (wrong owner) or 404 (wrong path):

   curl -I https://<Fleet-LCM-FQDN>/depot-service/content-gateway/PROD/COMP/SUPERVISOR/lib.json

5. Subscribe in vCenter with the resolved URL (the concrete form of §5.1’s {VcenterLcmDepotServicesAddress}{base_url}/…):

   https://<Fleet-LCM-FQDN>/depot-service/content-gateway/PROD/COMP/SUPERVISOR/lib.json

   Create a subscribed content library, default OVF security policy, a datastore, sync — then assign it (§5.1).
6. Verify the tree lists real items: lib.json, items.json, spherelet-v1.30/…v1.32/, and supervisor-9.1.0.0100-<build>/; the vCenter library should show the OVA + spherelet artifacts after sync.

VKR is a separate ~500 GB mirror, and NOT an activation prerequisite. The VKR path holds the Kubernetes releases for VKS guest clusters (§5.2), not the Supervisor itself. Seed SUPERVISOR to activate; do VKR only when you will actually run VKS guest clusters. The reported “repeated deployment errors” without VKR are the auto-created VKS library erroring on guest-cluster work post-activation — they do not stop the Supervisor reaching Running. Do not let a half-terabyte download gate the activation.

VKR is not a support-portal zip — it is a CDN mirror. This is the one asymmetry in the offline story, and it catches people who expect a second bundle next to the Supervisor one [field-verified 2026-07-23]:

• Supervisor — a discrete zip on the support portal (the step above).
• VKR — no support-portal bundle. The Kubernetes release images live on the CDN (wp-content.broadcom.com) as a content library (lib.json / items.json); you mirror them with a script that walks those JSONs (William Lam’s PowerShell walker, or the vkr-mirror.sh from the Amaya post) and host the result under PROD/COMP/VKR/. Only the Configuration Manifests / AddonRepository YAML for VKS are on the support portal — not the release images.

Two things shrink the job:

• Scope it to shipped-version → latest. You need only from the Kubernetes release that shipped with your 9.1 build (≈ v1.34.2) forward — not the full back-catalogue. A script that grabs everything from v1.16 is where the ~500 GB comes from; scoping cuts it to a fraction.
• 9.1.1 removes the chore entirely — the download tool gains an option to fetch the VKS/Supervisor artifacts to the offline depot automatically [field-reported]. This manual mirror is a 9.1.0-only workaround.

Same operational caveats as the Supervisor path: fix ownership to the web worker user (the chown apache:apache-on-nginx 403 trap applies equally), then subscribe the VKS library at …/depot-service/content-gateway/PROD/COMP/VKR/lib.json.

Community-script caution. A vkr-mirror.sh-style walker of lib.json / items.json is fine for a lab, but on a customer engagement read it first and prefer a sanctioned flow where one exists.

Credit: the offline-depot content gap and the download-script workaround were documented by the community ahead of the vendor — see Amaya Citta on VKS and Supervisor content libraries with an offline depot and William Lam on HTTP offline depot support in 9.1.

A synced library is not a populated one. Check the item count and that a release is actually listed — not just that the sync reported success.

It also blocks teardown. “Supervisor disablement fails and remains stuck in a removing phase if an associated Content Library cannot be deleted” [documented] — delete the content-library usage association via REST.

Sources: Supervisor 9.1 release notes · Configure a subscribed content library for Supervisor images · Create a vCenter publisher for the Supervisor releases library (air-gapped) · Create a subscribed content library (VKS) · Add or update VKS content libraries on a Supervisor

5.5 VKS guest clusters — planning inputs (after enablement)

None of this is needed to activate the Supervisor — but the first VKS (vSphere Kubernetes Service) guest cluster stalls without it, so collect it with the customer while everything else is being planned. It maps to the VKS guest clusters section of the planning template.

These are guest-cluster inputs, not Supervisor inputs. The only VKS item that is a Supervisor-level decision is which content library feeds Kubernetes releases (§5.2) — and that is changeable after activation.

Container image registry connectivity

Separate from the content libraries above. The Supervisor control plane, any vSphere Pods, and every VKS guest-cluster node pull runtime container images — Antrea / CNI, CoreDNS, metrics-server, the cluster-agent extensions, add-on packages, pause — from Broadcom’s OCI container registry, projects.packages.broadcom.com (formerly projects.registry.vmware.com).

Two things make this its own decision:

• It must be reachable from the workload and VKS node networks, not just the Supervisor management network. Routing that reaches vCenter is not enough.
• It is not covered by the fleet services-runtime (G5) proxy that feeds the Software Depot (09-binary-depot.md §5).

Pick one before activation (and before the first VKS cluster):

This decision is independent of the content-library / depot decision (§5.1–§5.4) — a site can be online for one and offline for the other — but they usually match. Firewall detail: projects.packages.broadcom.com:443 from the workload / node subnets — see 07-firewall-ports.md.

Walkthroughs for B and C — the Supervisor + TkgServiceConfiguration proxy steps and the full air-gapped relocation flow (the depot OCI registry, imgpkg / oci_image_depot_migrator.py, the depot image proxy, Harbor only if you need a user registry) are in 20-supervisor-image-registry.md.

6. Activate the Supervisor

This is the linear path from a standing start to a validated Supervisor. Each step points at the section on this page that carries the detail and, where relevant, the row group in the planning template. The screen-by-screen wizard reference is §6.1; the full validation runbook is §7.1.

The full sequence, start to finish

1. Lock the shape (§1) — networking model (this guide = VPC + Centralized Transit Gateway), load balancer (Avi or the built-in NSX Edge LB — §1.2), and single- vs three-zone (§1.3). The zone choice and the native-LB-vs-Avi choice are not reversible.
2. Create the vSphere Zones in vCenter (§1.3) — one cluster per zone, all on the same vDS. The wizard only selects them.
3. Clear the pre-flight gate (§2) — DRS Fully Automated, HA, lowercase host names, host count/size, NTP + DNS, storage policies, IPv4-only. Verify; do not accept assurances.
4. Build (or confirm) the Centralized Transit Gateway (§3) — Edge cluster (Large, ≥ 2 nodes), Tier-0, BGP established both directions, MTU 1700, the VPC External IP Block and the Private (Transit Gateway) /16 (§3.3).
5. Attach the External IP Block to the Default VPC Connectivity Profile (§3.4) — profile not (incompatible), Edge Cluster set. Relaunch the wizard after any NSX change.
6. Make the load balancer ready (§4) — built-in NSX Edge LB: nothing to build. Avi: Controller cluster healthy in the management domain, licensed, certificate SAN correct (§4.4), Service Engine Group Default-Group + storage policy, and — on VCF-Ops-managed Avi — the SE management network on NSX and the hand-built SE content library (§4.5).
7. Create and assign the Supervisor Images content library (§5.1) and confirm the Software Depot actually holds the SUPERVISOR content (§5.4). The wizard never asks about this.
8. Run the activation wizard (§6.1) — six screens; set Networking Stack = VCF Networking with VPC, select the zones, enter the API Server DNS Name now (it resolves to the LB VIP, not the management network), and Export Configuration on the last screen.
9. Wait for Running — activation deploys the control-plane VMs, configures the ESX hosts as Kubernetes nodes, prepares the LB VIP, and deploys the core Supervisor Services. Status goes Configuring → Running.
10. Read the assigned API / Control-Plane VIP from the Supervisor summary, then create the DNS A (FQDN → VIP) and PTR records (§7.1 step 0).
11. Validate end to end (§7.1) — API by IP and by FQDN, vcf context create + kubectl get nodes, a test namespace + workload, and a LoadBalancer Service reachable from outside.
12. Post-enablement — replace the default Supervisor certificate if the customer requires it, associate / upgrade the VKS content library (§5.5), and set up operator tooling.

6.1 The activation wizard, screen by screen

Where: vSphere Client → home menu → Supervisor Management → Get Started. (In 9.x the menu item is Supervisor Management; the post-activation status table is still under Workload Management.) A Supervisor can alternatively be activated as an optional step of workload domain creation in VCF Operations [documented].

Screens and fields, in order [documented]:

1 — vCenter Server and Network. Select the vCenter; set Networking Stack = VCF Networking with VPC.

2 — Supervisor Location. Supervisor name, data center, HA, and either three vSphere zones or one compatible zone.

The zones must already exist. This screen selects them; it does not create them. An empty zone picker means you skipped §1.3 — go create them in vCenter → vSphere Zones → Add New vSphere Zone, one cluster per zone, then come back. The single- vs multi-zone choice made here cannot be changed later.

3 — Storage. Storage policy for control-plane VM placement.

4 — Management Network. IP assignment mode (DHCP or Static), network, the 5 consecutive IPs / floating IP, subnet mask, gateway, DNS servers (required if vCenter uses an FQDN), DNS search domains, NTP servers.

5 — Workload Network.

An empty “VPC Connectivity Profile” dropdown means the NSX instance has overlay but no north-south spine — no Edge cluster, no Tier-0, or no connectivity profile. Go back to §3. [field-reported]

6 — Advanced Settings.

Export the configuration. It is one click, it documents exactly what was deployed, and it is the input for “Deploy a Supervisor by Importing a JSON Configuration File” later. Do it every time.

The wizard never asks about content libraries — which is exactly why the Supervisor Images library catches people out. It is assigned beforehand, on a different screen (Supervisor Management → Content Distribution), so there is nothing here to remind you. See §5.1.

The API FQDN points at the load-balancer VIP, not the management network. [field-verified 2026-07-23] This is a common confusion. The Kubernetes API server is fronted by the Avi load-balancer VIP, which is allocated from your VPC External IP Block (§3.3) — not from the management network where the control-plane VMs live (that network is only control-plane↔vCenter connectivity). The API Server DNS Names field takes just the FQDN, which goes into the cert’s SubjectAltName.DNS; the wizard’s own tooltip notes the LB IP is added to the cert automatically and must not be typed here. Timing wrinkle: the VIP is assigned during activation, so you usually cannot pre-create the DNS record. The clean order is — enter the FQDN now (activation does not require it to resolve yet) → activate → read the assigned API/Control-Plane VIP from the Supervisor summary → create the DNS A (FQDN → VIP) and PTR records. FQDN login (vcf context create --endpoint <FQDN>) then works because the name is already in the SAN.

Activation then performs “deployment of control plane VMs, ESX host configuration as Kubernetes nodes, virtual IP preparation on the load balancer, and core Supervisor Services deployment” [documented]. Status moves through Configuring to Running in the Workload Management Supervisor table (config status and host config status columns).

Sources: Deploy a Supervisor with NSX VPC · NSX VPC workflow for Supervisor

7. Validate

Finished is not the same as working. Check all of these.

The CLI changed in 9.1 — it is the VCF CLI, not kubectl vsphere login, and the plugin naming (kubectl-vsphere) is gone [documented]:

vcf context create --endpoint <SUPERVISOR-ADDRESS> --username <VCENTER-SSO-USER> --ca-certificate <PATH-TO-CERTIFICATE-FILE>

The endpoint accepts either an IP or an FQDN. Supply the password by prompt or via VCF_CLI_VSPHERE_PASSWORD. Verify with vcf context list; switch with vcf context use <name>. “Using FQDN requires it to be configured during the Supervisor enablement” — the API Server DNS Names field from §6.

There is no documented enumeration of Supervisor config-status values beyond Configuring / Running / Error, and no documented post-activation validation checklist. The table above is assembled from the troubleshooting and connection pages rather than quoted from one.

7.1 Followable validation runbook

Run these in order. Each has a do and a pass. Field-verified 2026-07-23. Stop and fix if any step fails — they build on each other.

0. One-time prep

• Get the API/Control-Plane VIP: vCenter → Workload Management → Supervisors → your Supervisor → Control Plane Node Address.
• Create DNS A (supervisor-fqdn → API VIP) and matching PTR.
• Install the VCF Consumption CLI (vcf) on your test host / jumphost — it replaces kubectl vsphere in 9.1, and it must be on whatever host runs steps 4–6.

  In an air-gapped / offline-depot deployment the Supervisor may not stage the CLI — its landing page (https://<API-VIP-or-FQDN>/) shows “VCF Consumption CLI is not found / requested version not available on the server.” This is the same offline-content gap as §5.4 (the offline path doesn’t populate everything in 9.1.0), not a step you missed — the Supervisor normally self-populates the CLI store, but the offline setup doesn’t. Follow the VCF CLI install guide (Installing and Using VCF CLI v9) — it splits into Internet Connected and Internet Restricted Environments subpages; use the restricted one for an air-gapped site. The vcf binary talks to the Supervisor over the API regardless of where you sourced it. Verify with vcf version. [field-verified 2026-07-23]

• Also have kubectl on the same host — it is a separate, standard tool, not part of the VCF CLI (the install guide does not mention it). The split in 9.1: vcf context create authenticates and writes the kubeconfig context, then standard kubectl uses that context for everything in steps 4–6. Get kubectl from your usual mirror or the Supervisor’s Kubernetes CLI Tools download (same landing page, same air-gapped staging caveat). [field-verified 2026-07-23]

1. Supervisor health (UI) Workload Management → Supervisors → Config Status = Running, Host Config Status clean, 3 control-plane VMs healthy.

2. API by IP

curl -k https://<API-VIP>:6443/healthz      # pass: ok  (Avi VIP → API server works)

3. API by FQDN (DNS + cert SAN)

nslookup <supervisor-fqdn>                   # resolves to the API VIP
curl -k https://<supervisor-fqdn>:6443/healthz   # pass: ok

4. CLI login (the 9.1 way)

vcf context create --endpoint <supervisor-fqdn> --username administrator@vsphere.local
vcf context list
kubectl get nodes                            # pass: control-plane + ESX nodes Ready

5. Namespace + workload schedules Create a namespace (Workload Management → Namespaces → Create; add storage + a VM class), then:

kubectl config use-context <namespace>
kubectl run testpod --image=<reachable-registry>/pause:latest --restart=Never
kubectl get pod testpod -w                   # pass: Running (or ContainerCreating)

Use an image reachable from your environment (internal/offline registry if air-gapped), not a public one.

6. LoadBalancer VIP from outside — the full Avi chain

kubectl create deployment nginx --image=<reachable-registry>/nginx
kubectl expose deployment nginx --port=80 --type=LoadBalancer
kubectl get svc nginx -w                      # pass: EXTERNAL-IP from the External IP Block
curl http://<EXTERNAL-IP>                      # pass: responds from outside the VPC

This proves the whole path: Avi allocates a VIP from the External IP Block, an SE serves it, and it is reachable north-south.

7. Avi side Avi UI → Applications → Virtual Services (API VS + nginx VS green/placed) and Infrastructure → Service Engine (both SEs healthy, VS assigned to an SE).

Cleanup

kubectl delete svc nginx; kubectl delete deployment nginx; kubectl delete pod testpod

Delete the test namespace if it was throwaway.

All seven passing means control plane, DNS/cert, CLI, scheduling, storage, image path, and the Avi load-balancer chain are all validated end to end — the point at which the enablement is genuinely done, not just Running.

Sources: Connect to the Supervisor as a vCenter SSO user · Troubleshooting the core Supervisor

8. Field notes

Failure signatures worth recognising

Each entry is what you see followed by what it is. All are [documented] in release notes or KBs except where marked otherwise.

Enablement halts at “Configured Supervisor Control plane VM’s Workload Network”. eth1 is never configured on the Supervisor nodes, and CoreDNS shows one pod in CrashLoopBackOff with two Pending. → nsx-ncp is stuck in “Restore mode” after a previous NSX Manager restore, so the workload segment is never created. Patch ncpconfig nsx-restore-status with the NSX restore_end_time and restart nsx-ncp. (KB 406786)

Cluster provisioning hangs, and a direct curl to the control-plane VM succeeds. Logs show “call timeout expired … http2: client connection lost”; Avi raises “Unable to acquire IP address for network”. → The load balancer, not the Supervisor — the successful curl is the tell. Create a new Service Engine Group and reassign the virtual service to it. (KB 442187)

Stuck on the load-balancer step with “Configured Load Balancer fronting the Kubernetes API Server — Timed out waiting for LB service update”. → A Foundation LB instance naming conflict when more than one Supervisor exists in a single vCenter. (KB 405115)

Load balancer service traffic fails when the endpoints sit outside the VPC. → A documented 9.1 issue; the workaround is to configure auto-SNAT.

vSphere Namespace creation fails against a 9.1 NSX. → NSX 9.1 introduces the cidr_list parameter on IPBlock while a 9.0 Supervisor still consumes the old cidr. A version mismatch, not a misconfiguration — stop re-checking your CIDRs.

Re-enabling a Supervisor on a previously decommissioned cluster fails. → Documented, and the workaround is to build a new cluster. Decommissioning is one-way for this purpose.

Deployment never completes at the transit-gateway stage. → Suspect the private transit-gateway block size — see §3.3. [field-reported]

A Supervisor Service is stuck ReconcileFailed — vendir / imgpkgBundle logs 502 Bad Gateway from mgmt-image-proxy / depot-image-proxy, then dial tcp <vip>:80: i/o timeout; the depot/image-proxy VIP is green in Avi with its pool up. The VCF Automation portal’s Services view then shows “Services are not available for this namespace”. → The image-proxy VIP is not actually serving. Most often an unlicensed Avi controller that created the VS but never programmed the listener — finish the licensing chain, restart AKO, retry the service (14-avi-load-balancer.md). Otherwise a port mismatch between the in-cluster proxy and the VS, or the depot OCI registry not enabled (20-supervisor-image-registry.md). [field-reported]

Traps that are requirements, not symptoms

These have documented requirements and no documented failure symptom — so they present as an unexplained stall. Check them in pre-flight rather than diagnosing them later: DRS not fully automated, storage-policy incompatibility, NTP or DNS drift, and uppercase host names.

MTU — the docs contradict each other

The core VCF page states 1500 minimum on VDS port groups and >1600 for host and Edge TEPs; the Avi requirements page states 1700 minimum on vSphere Distributed Switch port groups. Unresolved in the documentation. Use 1700 — it satisfies both.

Other things worth knowing

• Supervisor upgrade puts every host into maintenance mode, one at a time — expected behaviour, no workaround [documented]. Plan the maintenance window accordingly.
• NSX policy IDs containing ?, #, [ or ] cannot be used with the Supervisor [documented].
• Supervisor control-plane backup is an option in the vCenter file-based backup. This page used to say it is enabled by default since 9.0.2; that line could not be re-found in the current 9.1 release notes (checked 2026-10-15), so tick and verify it. See Supervisor control-plane backup and restore.
• If the API server is unresponsive, the documented diagnostic path is to SSH the control plane and run systemctl status kubelet, journalctl -u kubelet -n 100 --no-pager, journalctl -u containerd -n 100, and tail -n 200 /var/log/vmware/wcp/wcpsvc.log [documented].

Sources: Supervisor 9.1 release notes · KB 442187 · KB 406786 · Troubleshooting the core Supervisor

Break-glass access to the Supervisor control plane

The “SSH the control plane” line in §8 assumes you can get onto it. The control-plane VMs run no static password you were given at deployment — SSH is key-less password auth against a rotating root password that only vCenter holds. Get it from vCenter, not from the Supervisor. [field-reported]

This is a break-glass / support-diagnostic path — it hands you the raw cluster-admin context, which is broader than the vcf context create SSO login in §7.1. Use it to read state when something upstream (a tenant portal, VCF Automation, a vcf login) says the Supervisor is unreachable and you need to know whether the Supervisor itself is healthy. Do not drive routine namespace work from here, and do not hand-edit cluster objects.

1. Decrypt the control-plane password on vCenter

SSH to the vCenter Server Appliance as root. If it opens the appliance shell (Command>), drop to bash with shell (run shell.set --enabled true first if it is disabled). Then:

/usr/lib/vmware-wcp/decryptK8Pw.py

Output is one block per Supervisor:

Read key from file
Connected to PSQL

Cluster: domain-c1006:<uuid>
IP:      10.x.x.x            <- a control-plane VM management IP
PWD:     <long random password>   <- current root password for that Supervisor's CP VMs

2. SSH from vCenter to the control-plane VM

ssh root@10.x.x.x

Run it from the VCSA (or another host on the management network) — the CP VMs only accept SSH from there, not from a general jumphost or your laptop. All three CP VMs share the same root password; the script prints one reachable IP, the API VIP floats to whichever node is active.

3. You already have cluster-admin

kubectl is on PATH with /etc/kubernetes/admin.conf active — no login step. For the “Services are not available for this namespace” class of problem, this is where you confirm the Supervisor side in isolation:

kubectl get nodes
kubectl get pods -A | grep -Ev 'Running|Completed'
kubectl -n <namespace> get svc,supervisorservices
kubectl get svcbinding,supervisorservice -A          # the service catalog the portal reads

If those are healthy from here but the tenant portal or VCF Automation still fails, the break is on the path to the Supervisor (firewall / DFW / proxy no-proxy / cert trust / DNS — see 19-securing-vcf-automation.md), not on the Supervisor.

Caveats

• The root password auto-rotates (roughly daily) — re-run decryptK8Pw.py each session; a saved password will stop working.
• vCenter-side operation — independent of the networking model (CTGW / DTGW / classic segment / vDS).
• Nothing here persists: on a Supervisor upgrade the CP VMs are replaced.

Supervisor control-plane backup and restore

The Supervisor control plane has no backup tool of its own. It rides on the vCenter file-based backup: one extra option in the VAMI backup schedule, and a separate Restore workflow in the vSphere Client. Workloads in vSphere Namespaces are not covered by it. Same procedure in the 8.0 U3, 9.0 and 9.1 books [documented].

What is and isn’t captured

[documented] — the lowest supported Supervisor version for the control-plane backup is vSphere 8 Update 3. Below that, the Supervisor is silently not included in the vCenter backup. The backup target can be FTP, FTPS, HTTP, HTTPS, SFTP, NFS or SMB.

Turn it on

1. VAMI (https://<vcenter>:5480) → log in as root → Backup.
2. Edit the backup schedule (create one first if there is none).
3. Select Supervisors Control Plane. The state of all Supervisors on that vCenter is then included in every vCenter backup [documented].

Don’t assume it’s on: tick it and check it. A broken Supervisor backup can make the whole vCenter backup fail, so check that the last run actually succeeded with the option enabled:

• SFTP target drops the long Supervisor stream — Broken pipe in /var/log/vmware/applmgmt/backup.log, supervisors_backup_restore.py --backup failed. Raise the keep-alive / connection timeout on the SFTP server (KB 412555, KB 413151; 8.0 U3 and 9.0.x) [documented].
• 9.0.2: MANIFEST_UNKNOWN for auto-attach-service in /var/log/vmware/wcp/sv_backup_script.log after upgrading vCenter and the Supervisor to 9.0.2. The workaround resets the VKS Cluster Management service; fixed in 9.1 (KB 437859) [documented].

When to back up, and when not to

Back up only when the Supervisor is Running (freshly enabled or after a completed upgrade). Don’t back up while it is in an error state, while the Supervisor or a Supervisor Service such as VKS is being upgraded, or after a failed upgrade: the backup may be inconsistent or unusable (when to back up and restore) [documented].

Broadcom’s own caution: restore is for specific recovery scenarios, not a general fix for problems during lifecycle operations such as a Supervisor upgrade. It can orphan workloads or leave the control plane unhealthy. Avoid a restore when [documented]:

• The Supervisor Kubernetes version differs between the backup and the current environment. The mismatch blocks the restore.
• New VKS clusters were created, or VKS was upgraded, since the backup. The clusters’ VMs may be orphaned; a VKS upgrade gets downgraded and existing clusters can become unmanageable.
• New vSphere Pods were created since the backup. The restore may try to downgrade host components and hang on maintenance mode; clean up the orphaned pod VMs.
• vCenter is restored from a backup older than a Supervisor upgrade or restore. CP VMs get orphaned (to Discovered virtual machines) or duplicated. Delete those, then restore the Supervisor from a backup taken together with that vCenter backup.

Restore

Restoring vCenter and restoring the Supervisor are two separate workflows: a vCenter restore does not restore the Supervisor control plane. To get the vCenter-owned settings back as well, restore vCenter first, then the Supervisor. If only the Supervisor is restored, its configuration is overwritten to match what vCenter currently holds. A namespace deleted in the vSphere Client only comes back with a vCenter restore [documented].

1. vSphere Client → Supervisor Management → Supervisors → Restore.
2. Pick the vCenter, then the backup source: browse the backup server root folder, give a single backup file URL, or reuse the location and user name from the vCenter backup schedule. Enter the credentials.
3. Next → pick the backup file (it downloads) → pick the Supervisor → Finish.
4. The Supervisor goes back to Configuring; all CP VMs are deleted and redeployed from the backup. Watch it via View in the Config Status column.

Known restore failures [documented]:

• Stuck at 25% for up to 12 hours (NSX networking). The wcp-cluster-user-… service account gets locked when password rotation overlaps the restore. Wait for the 12-hourly sync, or unlock it with dir-cli / ldapmodify (KB 429913).
• Restore canceled and re-run within ten seconds — the destroy task of the previous CP VMs can hang on ESX Agent Manager lifecycle hooks (9.1 release notes).
• After an NSX restore, a VPC created after the NSX backup and attached to a namespace is missing and blocks the Supervisor restore; re-create the VPC (9.1 release notes).

Upgrade use. The recovery in KB 457944 (Supervisor CP VMs deleted by a vCenter 9.1.0 / 9.1.1 upgrade after an earlier vLCM database reset) is revert the vCenter upgrade, then restore the Supervisor from its backup. That only works if the pre-upgrade vCenter backup included the Supervisors Control Plane option. Take one immediately before any vCenter upgrade, with nothing changed on the Supervisor in between. Upgrade-side detail: VCFUpgradeGuide field notes.

Sources: Backup and restore the Supervisor control plane (9.1) · When to back up and restore (9.1) · Considerations (8.0) · KB 412555 · KB 413151 · KB 437859 · KB 429913 · KB 457944 · 9.1 release notes

9. The other networking paths

9.1 Distributed Transit Gateway

Same VPC wizard and the same Supervisor activation — only §3 is replaced. Everything from §4 onward (Avi, content library, activation, validation, field notes) applies unchanged.

What it is [documented]:

“The Distributed Transit Gateway does not require Edge Nodes, dynamic routing, or any specific configuration on the physical network.”

“It allows a distributed model which scales out as you add hosts since traffic directly goes from the host to the VLAN.”

What it needs instead of an Edge cluster and Tier-0 [documented]:

“A VPC with a Distributed Transit Gateway requires a VLAN available on all ESX hosts spanned by the Transit Gateway and connected VPCs.”

That VLAN requirement is the one to check early — it must be present on every host the Transit Gateway and its VPCs span, which on a stretched or multi-cluster domain means every host on both sites.

Where the VNA fits. Not everything is distributed [documented]:

“Services like DHCP or the ability to expose a workload with an external IP (1:1 NAT) are also distributed.”

“For networking services like Load Balancer or outbound SNAT, the Virtual Network Appliance (VNA) is used.”

“The VNA is multi-tenant and the same VMs can be used for multiple namespaces and multiple VCF Automation Organizations.”

So DHCP and 1:1 NAT run distributed on the hosts, while load balancing and outbound SNAT land on the VNA — which is therefore in the data path for anything egressing by SNAT or fronted by the built-in load balancer. Size and place it accordingly; being multi-tenant, one cluster serves multiple namespaces and Automation organizations.

Configuration fields — the VNA cluster is configured in the VPC connectivity profile; gateway type is Distributed Connection [documented]:

The same two IP blocks as the centralized path, so the sizing caveat in §3.3 applies here too.

Not documented: minimum VNA node count, form-factor sizing guidance, and the VLAN attachment detail for the VNA cluster itself. The configuration page states none of these. Plan for a cluster rather than a single node on anything production, and confirm the form factor against the release notes for your build.

9.2 Classic NSX segment networking (API only in 9.1)

Removed from the vSphere Client UI in 9.1 — see §1.1. Deployment “remains fully supported through the API”, and the practical route is Deploy a Supervisor by Importing a JSON Configuration File, which “automatically populates all the configuration values in the Supervisor activation wizard” [documented].

Two things to plan around if you land here. First, the 9.1 Supervisor book has no requirements page for this path — the surviving topic is one sentence pointing at the 9.0 Avi book, so the requirement numbers you work from are 9.0-vintage. Second, the CIDR model is different from VPC: Pod CIDR /23 minimum, Services CIDR /16 minimum, Ingress and Egress /27 minimum each (these two must be routable and advertised upstream, and must not overlap), namespace subnet prefix /28 default, and a Tier-0 uplink /24 — 1 IP with no Edge redundancy, 3 with static routes and redundancy, 4 with BGP and redundancy [documented, 9.0 sources].

9.3 vDS networking

No NSX: the Supervisor runs on distributed port groups, and the load balancer is the Foundation Load Balancer (FLB) or Avi. This is the path for VVF (which has no NSX) and for VCF environments that don’t want NSX networking for Kubernetes. The planning-time gate is in prerequisites.md; the content libraries (§5), image registry connectivity, validation (§7) and field notes (§8) apply unchanged. §1–§4 and the VPC parts of §6 don’t.

Status: TechDocs-sourced, not yet field-verified. Built from the 9.1 FLB pages (last updated 15 October 2026), KB 438769 and the vSphere Automation API. The minimal two-network layout in §9.3.2 is derived from those sources, not a documented topology name.

9.3.1 What the Foundation Load Balancer is

• Built in, Layer 4 only [documented]: “Foundation Load Balancer is a light-weight load balancer that is embedded in vCenter and provides layer 4 services.” Included in both VVF and VCF. For HTTP routing, run an ingress controller inside the VKS cluster behind one FLB VIP.
• Zero-touch lifecycle [documented]: vCenter deploys the FLB VMs during activation and upgrades them with vCenter and the Supervisor. They are “locked, system-managed appliances that should not be manually modified” (KB 438769).
• Placement [documented]: on a Management Zone of the Supervisor, in the same folder (Namespaces > <Supervisor name>) and resource pool as the control plane VMs, with disks on the control plane storage policy (architecture).
• Availability [documented]: one VM (DRS places it), or two VMs active-passive with a soft host anti-affinity rule in the same cluster. “The leader election and failover process is performed without vCenter involvement.”

On a stretched cluster the anti-affinity rule is host-level and soft, not site-aware, so both FLB VMs can land on the same site. A site failure then means a vSphere HA restart of the FLB on the other site, with an outage of the VIPs until it is back. (Inference from the documented rule; not tested.)

9.3.2 Network layouts

Topologies [documented] (architecture):

Hard rules [documented] (requirements):

• “The Management Network and the Workload Network must be on different subnets.”
• Workload networks need “routability between any Workload Network with the network that Foundation Load Balancer uses for virtual IP allocation”.
• The FLB management interface “must be routable to and from Supervisor Management Floating IP”.
• MTU “1600 or greater on any distributed port group”. MTU is set on the vDS, so check the switch.
• All hosts of the cluster(s) on one vDS. Host names in lower case, or activation might fail.

Layout A — fully separated (production):

Layout B — minimal, two existing port groups (proof of concept, labs):

Why it should work: the one-arm topology needs only management plus one dataplane network, and when no interfaces are customised the API attaches the FLB “to the Supervisor’s management and workload networks”. With two networks, interface 2 carries the workload and frontend personas on the workload network (VsphereFoundationConfig, vSphere Automation API 9.1). VIPs in the workload subnet then need no extra routing. Reserve one block in that subnet outside any DHCP scope and split it between VKS nodes and VIPs. Fallback if activation stalls at the load-balancer step: give the Virtual Server network its own port group (Layout A without transit).

Trade-off: VKS nodes and VIPs share a broadcast domain with the other VMs on that VLAN, and there is no separate VIP network to firewall. Fine for a test; use Layout A for production.

9.3.3 Sizing

FLB [documented] — per VM; two VMs double it:

Supervisor control plane [documented] — Tiny (2 CPU / 8 GB), Small (4 / 16), Medium (8 / 16), Large (16 / 32), 32 GB storage each. “Once you select a control plane size, you can only scale up.”

9.3.4 Firewall flows

From KB 438769 [documented]:

Add the content library and container registry egress (Container image registry connectivity).

9.3.5 Before the wizard

1. A vSphere Zone exists, even for a single-cluster Supervisor: the Cluster Deployment option asks you to “select a compatible vSphere Zone” [documented]. Create it in vCenter first.
2. Supervisor Images content library assigned (§5.1).
3. Storage policy for control plane, ephemeral disks and image cache.
4. DNS A + PTR for the Supervisor API FQDN (pointed at the API VIP once known — §7.1).
5. IP ranges reserved and excluded from DHCP; vDS MTU checked.
6. Proxy details if egress is proxied, including the proxy root CA if it intercepts TLS (docs/20 §3).

9.3.6 The activation wizard, screen by screen

From Deploy a Supervisor with Foundation Load Balancer and VDS Networking [documented]. Supervisor Management → Get Started:

1. vCenter Server and Network — select the vCenter, vSphere Distributed Switch, and Foundation Load Balancer as load balancer type. Tick Enable control plane high-availability for three control plane VMs (one VM can be scaled to three later).
2. Supervisor location — Cluster Deployment (one Management Zone, host-level HA) or vSphere Zones Deployment (three zones). Name the Supervisor, pick the data center and zone(s).
3. Storage — control plane, ephemeral disks and image cache storage policies (same or different).
4. Management Network — port group; static block of 5 IPs, subnet mask, gateway, DNS servers, search domains, NTP. With DHCP the server must support client identifiers. “Changing the IPs of control plane VMs and floating IPs is not supported.”
5. Workload Network — port group (the primary workload network), the Internal Network for Kubernetes Services CIDR, mask, gateway, DNS, NTP. Prefer static: “If you select using a DHCP server to provide the networking settings for Workload Networks, you will not be able to create any new Workload Networks once you complete the Supervisor configuration.”
6. Load Balancer — name; topology (one-arm or two-arm); size; high availability (one or two VMs). Then assign:
   • Management Network: port group, IP range, mask, gateway, DNS, NTP, optional syslog server and certificate.
   • Virtual Server Network: port group and the VIP range(s) — “Must be on the same subnet as the gateway.”
   • Transit Network (two-arm only): port group and IP range.
7. Advanced Settings — control plane size (scale-up only); API Server DNS Names — always fill in the FQDN, it goes into the generated certificate and the 9.1 VCF CLI login by FQDN depends on it (§7); Export Configuration — save the JSON, it makes a redeploy a re-import instead of a re-type.
8. Ready to complete → Finish.

Watch the FLB state on the monitor page alongside the Supervisor config status.

9.3.7 Smoke test after activation

Run §7.1 first. Then prove the load balancer end to end:

1. Namespace — Supervisor Management → Namespaces → New Namespace; add permissions (an AD group), a storage policy and at least one VM class.

2. VKS cluster — apply a Cluster manifest on the built-in ClusterClass with a vmClass and storageClass from the namespace (variables reference: VKS cluster configuration variables). Its control plane gets a VIP from the FLB range.

3. LoadBalancer service — on the VKS cluster:

   kubectl create deployment web --image=<an nginx image your nodes can pull>
   kubectl expose deployment web --port=80 --type=LoadBalancer
   kubectl get svc web          # EXTERNAL-IP from the VIP range
   curl http://<EXTERNAL-IP>/   # from a client network

   A <pending> external IP points at the FLB or the VIP range; a VIP that doesn’t answer points at routing or the NodePort flow (30000–32767).

4. Optional: ingress — install an ingress controller package (for example Contour) and route two hostnames through its single VIP.

9.3.8 Known issues

• More than one Supervisor in a vCenter: activation can stall at “Timed out waiting for LB service update” from an FLB naming conflict (KB 405115; see §8).
• DHCP on the workload network locks out new workload networks later (step 5 above).
• Control plane IPs are fixed for the life of the Supervisor (step 4).

Sources: FLB architecture · FLB requirements · Deploy a Supervisor with FLB and VDS networking · Monitor FLB · KB 438769 · VsphereFoundationConfig (API 9.1) · VKS cluster variables

9.4 Simplified (“Easy”) Supervisor

Available in 9.1 [documented]. Base configuration: a single control-plane VM, one network carrying both management and workload traffic, and VM Service only — vSphere Pods and Supervisor Services are not available initially. It expands afterwards in any order: add a load balancer (Avi or Foundation), which unlocks vSphere Pods and Supervisor Services; scale the control plane from 1 to 3 VMs for HA; add a second NIC to separate workload from management traffic. An FQDN is mandatory for Supervisor access on this path too, pointing at the floating IP when there is no load balancer, or at the VIP when there is.

Sources: Configure the Distributed Transit Gateway · Supervisor architecture with VPC networking · Deploying Supervisor with a simplified flow · Requirements for simplified deployment · Requirements for Supervisor deployment with NSX (9.0)

10. References

Each section above ends with a compact Sources line naming the exact pages behind it. This section is the consolidated list — the books to start from when you need something this page does not cover.

VCF 9.1 Supervisor — Installation and Configuration is the root. Within it: Supervisor networking with VPC (architecture, the workflow, both Transit Gateway wizards, and the activation wizard), connecting to clusters (the VCF CLI), the stretched-cluster overview, and troubleshooting. The 9.1 release notes carry the two changes that invalidate older procedures — the classic-NSX UI removal and the content-library move off the public CDN.

Avi Load Balancer — the 9.1 book for licence management and the 32.1.1 licence-format transition; the 9.0 book for the NSX + Avi procedure itself, the Service Engine Group and NSX Cloud configuration, and the documented limitations. The 9.1 Supervisor book points at the 9.0 book by design, not by oversight.

Classic NSX segment networking (9.0 sources) — requirements and the three-zone wizard walkthrough. These are the current documentation for that path even in 9.1; see §9.2.

KBs — 442187 (deployment hangs on Avi virtual-service placement), 406786 (enablement stuck at the workload-network step after an NSX restore), and KB 405115 / KB 406096 (Foundation LB naming conflict and the related upgrade timeout).

In this repo — prerequisites.md → vSphere Supervisor is the planning-time input gate, 06-deployment-plan.md carries the E9 stories and their ordering, and 09-binary-depot.md covers the Software Depot that now feeds the VKS content library.

Planning template — the download table is at the top of this page: supervisor-prep-plan-9.1.csv / -9.0.csv (source: web/public/templates/), one combined fillable CSV whose sections mirror this guide.