Avi Load Balancer — Deployment Guide

Deploying the Avi Load Balancer controller cluster from VCF Operations. The prerequisites gate states what must exist before you start; this page covers how to deploy it, the controller’s own first-login setup, and the licensing chain that follows.

Deployed Day-N from VCF Operations (lifecycle-managed), needed when Avi is the chosen load balancer for vSphere Supervisor, optionally in front of VCF Automation, or for tenant/workload load balancing.

Controllers are central, Service Engines are local. The Avi controllers always run in the management domain — whichever domain they serve, including a Supervisor on a workload domain. That is the same pattern as a workload domain’s vCenter and NSX Managers, which also run in the management domain (04-sizing.md’s workload-domain repeater). Only the Service Engine VMs are distributed: they run per cluster, in the workload domain.

A controller set is scoped to the NSX instance, not the workload domain: workload domains that share an NSX instance share one controller set; a workload domain with its own NSX instance gets its own set. Count controller sets by NSX instance, and Service Engines by cluster.

Deploying from VCF Operations

Before you start: a content library for Service Engine images is required and VCF Operations does not create it. See Service Engine infrastructure below for the full, field-verified procedure — read it before you activate anything downstream (Supervisor or a virtual service), since this is the single most commonly missed step in the whole Avi deployment.

Where you deploy it from, and what “optional” means. VCF Operations → Build → Lifecycle → VCF Instances → your domain → Manage Components, where Avi Load Balancer appears as a card beside VCF Operations HCX. That page draws a distinction worth knowing at procurement time, verbatim: “Optional components are appliances that can be installed at domain to help in leveraging specific use cases and/or goals and are included in your entitlement. Add-ons are optional appliances that are purchased and managed in separate from the SDDC Manager.” Avi is an Optional Component — entitled and SDDC-Manager-managed, not a separate purchase.

What the deploy wizard asks for. Field-observed 2026-07-22 — four steps:

Small reserves 96 GB memory, 18 GHz CPU and 1,536 GB disk across the three-node cluster (≈32 GB / 6 GHz / 512 GB per node). Because step 2 shows this against live cluster availability, it doubles as a capacity check — but on a management cluster sized to the line, confirm the headroom in 04-sizing.md before you get there.

Controller first-login setup

The controller has its own first-login wizard — the VCF deploy is not the end. Field-observed 2026-07-22. Logging into the new controller opens WELCOME ADMIN → System Settings, “Let’s get started with some basic questions”, which asks for:

Three sections, each with its own NEXT, then SAVE:

A Setup Cloud After checkbox sits alongside SAVE throughout, deferring cloud configuration to a later step.

Three planning consequences:

• A secret to have ready that no VCF-side document mentions — and losing it costs you your backups. The Avi Passphrase protects the controller’s configuration backups, so treat it exactly like the backup encryption passphrase for the SFTP target (see 08-backup-target.md): chosen up front, stored in a password manager, with a named owner. It is required to restore, and a lost passphrase makes every controller backup useless. Nothing on the VCF side asks for it, and it is set once, in passing, on a welcome screen — which is exactly how it ends up unrecorded.
• The controller’s DNS is configured here, not during the VCF deploy — so the resolvers and search domain belong in the Step 1 plan even though nothing in the deployment wizard asked for them.
• The Multi-Tenant page is an architecture decision disguised as a setup step. Whether Service Engines are provider-shared or per-tenant, and whether the IP route domain is shared, shape how the platform can be carved up later. The defaults (shared route domain, provider-managed SEs, tenants get read access) suit a single-tenant enterprise deployment. If the fleet is heading toward genuine tenant separation — service-provider use, or strict per-tenant isolation — decide this before first login rather than accepting the defaults and discovering the model later.

Email/SMTP defaults to None — so nothing is alerting anyone. Avi raises its own events, and out of the box there is no path for them to reach a human. If the fleet has a monitoring or alerting standard, wire the controller into it deliberately; if it does not, at least record that Avi alerts live only in its own UI.

Service Engine infrastructure — Cloud, content library, and SE Group

Sourcing convention: [documented] = confirmed against TechDocs; [field-verified 2026-07-23] = confirmed against a live 9.1 lab, ported over from 10-supervisor-enablement.md §4.5, which found this while enabling Supervisor with Avi — the same Cloud/content-library/SE-Group mechanism applies regardless of what consumes the load balancer (Supervisor, VCF Automation, tenant LBaaS), since it’s all the same NSX Cloud object in Avi.

VCF Operations deploys the Controller, creates its service account, generates the certificate, and propagates trust to NSX and vCenter, and wires the base NSX Cloud connector [documented — 9.1 Avi release notes]. That leaves a short, required list of Avi-side configuration you still have to do by hand before anything can actually deploy a Service Engine — this is the gate almost everyone hits.

Verify before you build. VCF Operations does the base “cloud connector setup”, so parts of the NSX Cloud may already exist. Open Infrastructure → Clouds and Templates → IPAM/DNS Profiles and check what’s already there before hand-creating anything.

1. The Service Engine management network — the piece people miss [documented; field-verified 2026-07-23]. SE management NICs need their own network, and VCF Operations does not create it — it leaves the NSX Cloud connector’s Management Network field blank, 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 — surfacing later as the load-balancer step stalling with “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 a data-network transport zone (the workload overlay TZ), but you do not configure data segments or IP pools under it in a VPC-networked cloud — the VPC handles the Data Network Segment itself. The data TZ does not need to match the management-network TZ, and it must be present in the transport node profile of the ESXi hosts where the Service Engines will run, or the SE data NICs cannot attach.

2. The NSX Cloud connector — 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 target cluster; VCF Operations 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, 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 that as a checkpoint: after saving, confirm the SE OVA item actually appears in the library, proving the SE image path works before you try to activate anything downstream — not something to discover mid-activation.
• Set the Template Service Engine Group on the Cloud. Infrastructure → Clouds.

3. The Service Engine Group — configure Default-Group as the template, before first use [documented]. Two statements that together make this a one-shot setting:

“<Consumer> creates one Service Engine Group for each <instance>.” / “If no template Service Engine Group is configured in the cloud, the Default-Group is used.” / “Changes made to the Default-Group configuration will not reflect in an already created Service Engine Group.”

So Default-Group must be right before the first thing consumes it — retrofitting it afterwards does nothing for whatever already cloned from it. Under Infrastructure → Cloud Resources → Service Engine Group, set:

• The vSphere storage policy — Service Engines are VMs, no policy means nowhere to deploy them.

  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 the common place people go looking for it first.

• Placement scope — compute cluster + datastore, optionally VM-group / host-group affinity.

• HA mode (N+M buffer / active-standby / active-active), 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 typically deployed per consumer.

Gotcha — SEs land on local datastores unless you pin shared storage. [field-verified] Datastore choice is an SE-Group setting, not a Cloud one, and the default is unhelpful: when Avi picks an ESXi host for an SE VM it picks that host’s local datastore. If the SE Group has neither a vSphere storage policy that resolves to shared storage nor an explicit shared datastore under Placement Scope → vCenter → “Data Store for Service Engine Virtual Machine” (use the Include checkbox to pin it), every SE clones onto host-local storage — and SE HA and host maintenance break.

It stays invisible until it doesn’t. The first visible sign is usually an ESX upgrade or host maintenance-mode task stalling on an SE VM that will not vMotion (its disk is on the host’s local datastore), or a VIP dropping when a host enters maintenance. Nothing flags the misplacement at deploy time.

Remediation is two steps — changing the config does not move existing SEs:

1. Correct every SE Group that virtual services actually run on, not just Default-Group. The consumer (AKO for Supervisor, VCFA for automation) clones one group per Supervisor / per instance from the template, and “changes to the Default-Group configuration will not reflect in an already created Service Engine Group.” Fix the in-use groups and the template.
2. Relocate the SEs already on local storage. Either Storage vMotion each SE VM onto the shared datastore, one at a time, waiting for the SE to go healthy in the Avi UI between moves (non-disruptive on an N+M or active/standby group); or delete each SE in the Avi UI one at a time and let the Controller rebuild it from the now-fixed group on shared storage (brief per-SE data-plane blip — watch virtual-service placement recover between deletes). Storage vMotion is the safer default.

Editing the SE Group directly is fine on a VCF-Operations-managed Avi — SE sizing / placement / storage is normal data-plane config. The controller certificate is the thing you must never change from the Avi or NSX UI — VCF Operations generates it and propagates trust to NSX and vCenter, and swapping it in the Avi/NSX UI breaks that trust; re-drive it through VCF Operations. And confirm a shared datastore is actually presented to every host in the SE cluster: NSX-T clouds require one for SE HA, and a cluster with none is itself the root cause.

IPAM is NOT required for VPC networking [documented] — a placeholder IPAM profile is only needed for a non-VPC cloud. On the VPC path (the model used both by Supervisor’s built-in LB integration and the VCF Automation DMZ VPC approach below), TechDocs states plainly: “IPAM profiles are: Not required for VPC networking”, because the VIP comes from the VPC’s External IP Block, not from Avi IPAM. That External IP Block is the real pre-activation dependency in that model, and it lives in the VPC connectivity profile you build in NSX, not in Avi itself.

The short version: SE management network built in NSX and selected in the Avi Cloud + a data-network transport zone (no segments needed under a VPC-networked cloud) + vCenter with a hand-built SE content library + a Service Engine Group (Default-Group, or a named template) with a storage policy set. Everything else a fuller walkthrough shows you is already done for you by VCF Operations.

Licensing

The controller must be pointed at License Hub — it does not find it. Administration → Licensing offers a two-way choice under Get Started:

Selecting the second switches the controller to the hub (“Switched to On-prem License Hub”), and its ON BOARDING INSTRUCTION button lays out the same four stages the hub itself shows, from the Avi side: Deploy & Register → Licenses → Endpoint Management → Usage Reporting and License Refresh. The operative one is Endpoint Management — “Assign licenses to AVI Controllers from On-prem License Hub”. That is the actual join between the two appliances: the hub holds the entitlement, and the controller is an endpoint it assigns licences to. Until that is done the controller reports 0 Used / 0 Available.

Extract the controller’s certificate before you go to License Hub to onboard it — the onboarding dialog needs it in hand, in full chain. Field-verified: the endpoint’s Certificate field in License Hub’s Onboard an Endpoint dialog (see 15-license-hub.md) wants the leaf certificate and the CA certificate pasted together in one action — no separate leaf/CA fields. Since this is the VCF-Operations-generated controller certificate, not one you already hold, retrieve it from the controller before starting the onboarding wizard rather than discovering the extraction step mid-dialog.

• Licences are measured in Service Units, not per-appliance — the figure to check against an entitlement at procurement time.
• Splitting, merging or upgrading licences happens in the Broadcom Support Portal → Entitlements, while assignment happens in the Avi Cloud Console — two different portals for two different jobs.
• Ordering: the controller can be switched to On-prem mode before the hub is registered, it simply has nothing to draw on yet. So the switch is safe to make early, but licences do not appear until the hub itself is registered (see 15-license-hub.md).

Once connected, the page shows an ON-PREM LICENSE HUB card — the hub URL, a Connectivity Status of Connected, a Last Refresh timestamp, a REFRESH LICENSES button and a DISCONNECT ON-PREM LICENSING action. Use that card as the verification step: Connected plus a recent refresh is the proof the join actually works.

Connected still means zero licences — verify the count, not the status. Field-observed: with connectivity Connected and a fresh refresh timestamp, the controller still reported 0 Used / 0 Available, because the licence file had not yet been loaded into the hub (step 3 of the licensing chain in 15-license-hub.md). A green connectivity indicator is not evidence of a licensed fleet. Check LICENSE USAGE, not Connectivity Status.

Upgrading to 32.1.1 starts a 90-day clock that overrides your licence validity — decide this BEFORE you upgrade. This is the single most time-critical item in this section. TechDocs, verbatim: “Starting with Avi Load Balancer version 32.1.1, 25-character serial key (legacy license) and YAML-based licenses are deprecated.” … “Newly deployed or upgraded Avi Controllers on 32.1.1 are allowed to use legacy licenses for a strict grace period of 90 days. This period commences upon the initial boot or completion of the upgrade.” … “This 90-day limit overrides any existing validity dates” — with the worked example that “an upgrade performed on May 31 will cause all legacy licenses to expire on August 28, 2026, even if they were originally valid until 2029.”

So a site with valid, paid-up legacy licences and years left on them gets 90 days after the upgrade, and then they stop. The clock starts silently at upgrade completion. Broadcom’s own instruction is unambiguous: “Plan the transition to one of Cloud Licensing or On-premise License Hub deployment models before initiating an upgrade.” If the site already runs Avi, treat entitlement migration as a pre-upgrade gate, not a follow-up.

Two dates on a fresh controller, and they mean different things. A newly deployed 32.1.1 controller shows both, roughly two months apart, which reads as a contradiction until you know the cause:

Where	What it is
The licence row’s Expiry, ~30 days out	The “built-in 30-day keyless evaluation mode upon installation”
The banner, “All legacy licenses are scheduled to expire on <date>”, ~90 days out	The 90-day legacy grace period, counted from that controller’s own initial boot

Neither is a general Broadcom cutoff — both are per-controller clocks started by your own deployment. Diary both on the day you deploy.

Licensing an Avi controller is a four-step sequence, and step 1 is not in any appliance. TechDocs, verbatim: “Upgrade Entitlement: Log in to the Broadcom Support Portal and upgrade your Avi license to the new subscription format.” → “Deploy License Hub on-premises (if applicable) and onboard/register it with the Avi Cloud Console.” → “Use the Avi Cloud Console to allocate the license ID and generate an activation code (connected) or signed license file (disconnected).” → “From the License Hub, assign the validated license file directly to your Avi Controller endpoints.” Note that the entitlement upgrade is a portal action taken before any appliance work, and that once upgraded a licence cannot be downgraded — so it is a one-way step to schedule deliberately, not to discover mid-deployment.

VCF Automation (external/customer access)

Sourcing convention: [documented] = confirmed elsewhere in this repo against TechDocs/field observation; [field-reported] = practitioner blog, not independently verified here. This whole section is one worked example, not the only way to do it — TechDocs itself only says an external LB is possible post-deploy, not how.

VCF Automation’s own built-in load balancer is L4-only — no SSL termination, and (per the built-in-LB memory already in this repo) it’s never required. Putting Avi in front adds L7 termination and can keep customer/tenant traffic off the management network entirely. The most complete field walkthrough found for this is Tom Fojta’s “Load Balancing VCF Automation with Avi” [field-reported], which uses a DMZ VPC architecture — a separate NSX VPC dedicated to external access, not a plain VDS network. Below follows his steps with notes on what a VCF-managed Avi deploy already did for you, since his article doesn’t distinguish that.

This shape is now an official Broadcom design pattern, not just a field report. Deployment Pattern 3: External-Facing Deployment of VCF Automation [documented] names the same DMZ VPC + Mgmt App VPC + Transit Gateway + Tier-0 Gateway structure Fojta’s walkthrough builds below, and adds two things his article doesn’t: a Benefits/Drawbacks list, and confirmation that either Centralized (CTGW) or Distributed (DTGW) Transit Gateway architecture works here — the diagram shows CTGW, but DTGW is equally supported. Fojta’s steps below (NSX Project + a Tier-0 GW) are the CTGW path; a DTGW build skips the Tier-0/BGP pieces per 01-network-dns-plan.md §B.2, but the DMZ-VPC/Transit-GW/Avi shape is otherwise the same. Trade-offs, from the design library: easier management of one appliance set and reduced lateral-movement risk, against needing solid perimeter security (firewalls/WAF/API security) already in place and the added routing/firewall/subnet complexity per tenant.

Licensing note [field-reported]: this approach needs VPC networking and Avi/vDefend licensing beyond base VCF — plain VCF only ships NSX Legacy L4 load balancing and a stateless gateway firewall.

What the VCF Operations deploy already did

• The NSX Cloud + vCenter/NSX linkage — already done, don’t recreate it. [documented], per the deploy wizard’s own Finish-step notice quoted in Notices and gotchas below: “Service accounts will be created with NSX Manager and vCenter Server as required.” Fojta’s guide lists creating an NSX Cloud that connects to the management domain’s NSX and vCenter as its first Avi-side step — for a VCF-managed deploy this connection already exists. Go verify it under the Cloud configuration rather than creating a new one.
• A default Service Engine Group likely already exists — configure it, don’t assume it’s ready as-is. Avi ships a default SE Group, but Fojta’s guide still calls for setting SE node sizing, placement, and HA on it. Not independently confirmed here whether the VCF-deployed default needs changes before it is production-ready for this use case — check live.
• Everything else below is genuinely manual, VCF-managed or not: the NSX networking chain (Project/Transit GW/VPC), the SE management network, and all of the virtual-service configuration are Day-2, use-case-specific work that nothing automates.

NSX-side build (the DMZ VPC)

[field-reported], in order:

1. Confirm Avi is registered in NSX to support VPCs. Not confirmed here whether this is automatic alongside the Cloud/service-account provisioning above, or a separate toggle — verify live before assuming either way.
2. External IP block for the DMZ VIP and SNAT.
3. NSX Project (“DMZ project”) with a centralized connection to a Tier-0 GW that can route to both the VCFA network and the external IP block.
4. Transit GW inside that project.
5. DMZ VPC with its own private CIDR (non-overlapping with the external block). Its Connectivity Profile uses the external IP block, N-S services, and default outbound NAT (so the service network can reach VCFA).
6. Enable Avi Load Balancing in the VPC’s Advanced Settings.

DFW gotcha [field-reported]: the default east-west (DFW) drop rule blocks LB→VCFA traffic. Temporarily open it to prove the path works, then harden back down deliberately rather than leaving it wide open.

If registered correctly, Avi auto-detects Avi-enabled VPCs and creates a matching tenant per NSX Project — no manual tenant creation needed in Avi itself.

Avi-side SE Group, content library, and management-plane network

Do this via the canonical procedure above, not from scratch. The Service Engine infrastructure section covers the SE management network build, the hand-built content library (VCF Operations does not create it — and confirming the SE OVA lands in it is your checkpoint before going further), and the Service Engine Group’s storage policy — all of it applies here unchanged, since it’s the same NSX Cloud object regardless of what consumes the load balancer. Fojta’s own write-up [field-reported] names only a Tier-1 GW + DHCP-enabled segment for this — that matches the management-network build above, just described less precisely; use the canonical section’s detail (including the exact place SEs go red if it’s wrong) over his shorthand.

If this controller cluster was freshly deployed specifically for this use case, budget the full Cloud/content-library/SE-Group setup as real work before expecting Service Engines to deploy at all — none of it is optional, and none of it is done for you beyond what VCF Operations already handles (cert, trust, service accounts, base connector).

Building the virtual service

Use the Advanced create wizard — the Basic one does not expose what you need. Field-verified: creating the virtual service per the settings below (custom Application Profile, TLS SNI on the health monitor, a specific certificate) requires Avi’s Advanced virtual-service creation flow, not the default Basic wizard. Switch to Advanced before starting, rather than building it in Basic and discovering the fields aren’t there.

[field-reported], field values from Fojta’s guide:

Empty SSL Profile on an SSL-enabled pool → 503 [field-verified]. If the pool has Enable SSL ticked but the SSL Profile dropdown is left empty, Avi connects to VCFA’s internal 443 VIP in plaintext; the backend drops it and the client gets a 503 from Avi. The Avi VS logs show the 503 as relayed from the server, not NO_AVAIL_POOL, and the pool member can even read up if the health monitor was configured with its own SSL profile (the monitor and the pool data path are configured separately). Fix: on the pool, Enable SSL and select an SSL Profile (System-Standard), with the SNI / server host name set to the VCFA FQDN.

The Avi security score on an externally-facing VS is additive, and Broadcom’s documented factors are necessary but not provably sufficient [field-verified 2026-08-27]. Per Broadcom’s Health Score Codes documentation, the VS’s SSL Score (a component of its security penalty) is driven by: an insecure cipher in the SSL/TLS profile, the certificate being expired or self-signed, and other SSL settings such as HSTS not being enabled on the HTTP profile. Expect each fix to move the score by roughly one point, not to clear it outright. In the field case behind this note: self-signed → CA-signed cert moved it -20 → -19; removing an insecure cipher from the SSL/TLS profile moved it -19 → -18; HSTS was checked next and found already enabled, with no score change — so that documented cause was ruled out, not fixed, and -18 remained unaccounted for. The GUI’s top-level security-score tile never explained the breakdown at any point in this investigation. Don’t assume the cert/cipher/HSTS list is exhaustive — if you hit the same wall, verify the new cert and cipher list are actually live on the Service Engine (not just saved in the VS config) before assuming a further, undocumented factor.

DNS cutover gotcha [field-reported] — and it’s not what you’d expect. “AFAIK there is no documented way how to change FQDN of VCFA installation which means you cannot use a new FQDN for the public VIP.” So this is not a new customer-facing name added alongside the internal one — the same VCFA FQDN’s DNS record has to move from the internal VIP to the new external VIP. Skip this and VCFA will redirect subsequent calls back to the internal VIP, breaking the flow, because the internal VIP still believes it owns that name.

Known gotcha: HTTP/2 breaks Supervisor image pulls

[field-reported], and worth reading before enabling HTTP/2 on this virtual service at all: VKS Cluster Management traffic (Supervisor and VKS clusters talking to the VCFA endpoint) needs HTTP/2, because the cluster agent extensions use gRPC over HTTP/2. But on Avi 32.1.1, enabling HTTP/2 broke Supervisor’s ability to pull images from the VCFA endpoint (ErrImagePull on pods like auto-attach) — Avi was rewriting the backend’s HEAD-request Content-Length to 0 under HTTP/2, and downstream image resolution failed on that malformed response. Workaround: a second VCFA pool with HTTP/2 disabled, with an Avi request policy that context-switches HTTP HEAD requests to that pool instead. If this fleet uses Supervisor/VKS against the same VCFA endpoint, budget for hitting this and plan the second pool up front rather than discovering it mid-incident.

Notices and gotchas

The wizard states the per-NSX-instance rule itself. At Finish, verbatim: “This Avi Load Balancer will automatically be deployed and linked to other workload domains sharing the same NSX manager associated with <workload domain>.” This is the rule from the callout above, in the product’s own words — deploying “an Avi for this workload domain” silently serves every workload domain on that NSX Manager. Also noted there: “Service accounts will be created with NSX Manager and vCenter Server as required” — the deploy provisions its own service accounts, so expect new principals in both.

Not the same thing as the external load balancer for VCF Operations (see prerequisites.md’s Network table and 05-day2-deployments.md B.1) — that one is never served by VCF.

References

TechDocs: Requirements for Deploying Avi Load Balancer · Deploy Avi Load Balancer from VCF Operations. The P&P workbook has no Avi input fields — only sizing rows — so capture these values in the Step 1 plan / intake instead.