Avi Load Balancer: One Controller, NSX Cloud in VPC Mode

VCF 9.1.1 lab rebuild. Part of the follow-along guide, published live as the build happens.

📘 Official documentation. This is a lab walkthrough, not a replacement for the vendor docs. For the authoritative, supported procedures, follow Broadcom’s VMware Cloud Foundation 9.1 documentation. Where this guide and the official docs differ, the official docs win.

What you end up with: an Avi controller registered with NSX, its cloud ready to place Service Engines, and a Supervisor activated afterwards getting Avi as its load balancer with nothing further to do.

It works on a distributed transit gateway with no Edge cluster. Service Engine management rides an NSX VLAN segment, Service Engine data sits on each VPC’s own Services Subnet, and the VIPs come out of the external IP block and are answered on the external VLAN by the hosts themselves.

What must already exist

The values

1. The Service Engine management network

An NSX VLAN segment cannot reach a host that has only the overlay transport zone, which is what bring-up leaves behind.

1. Create VLAN 1603 on the physical network with a gateway and a DHCP scope — here 10.134.3.1/24, handing out .50–.250 — trunked to every host uplink.
2. Give every host the VLAN transport zone:

uv run scripts/nsx_vlan_tz.py            # shows the two cluster transport node profiles and what would change
uv run scripts/nsx_vlan_tz.py --apply    # adds nsx-vlan-transportzone; waits for all eight hosts

3. In NSX, Networking › Segments › Add segment: name vcf-avi-se-mgmt-1603, transport zone nsx-vlan-transportzone, VLAN 1603, no gateway — the physical network routes it. It appears as a port group on both distributed switches.

What you should see: a VM or VMkernel interface on that port group, on any host in either cluster, takes a lease from 10.134.3.0/24 and can reach 10.128.1.90 and .91.

2. Names and the password

• Create forward and reverse DNS for avi.pgvcf1.pgnet.io → 10.128.1.90 and avi01.pgvcf1.pgnet.io → 10.128.1.91. The deployment script refuses to run without both.
• Generate the admin password into the secret store, under infrastructure/vcf/pgvcf1/avi.

3. Allow a single controller

On the SDDC Manager appliance, as root, after taking a VM snapshot:

cp -p /home/vcf/feature.properties /home/vcf/feature.properties.bak-$(date +%Y%m%d-%H%M%S)   # -p keeps owner and mode
echo 'feature.vcf.vgl-41078.alb.single.node.cluster=true' >> /home/vcf/feature.properties
echo y | /opt/vmware/vcf/operationsmanager/scripts/cli/sddcmanager_restart_services.sh        # it asks for confirmation

Restart only while no SDDC Manager task is running. The services take a few minutes to come back. Remove the snapshot once the controller is up.

🔗 Community — the feature flag is documented by William Lam. Community work for lab use, not Broadcom guidance, and not supported.

4. Deploy the controller

uv run scripts/avi_deploy.py            # checks DNS, the bundle and the password; runs SDDC Manager's own validation
uv run scripts/avi_deploy.py --apply    # POST /v1/alb-clusters; watches the task

SDDC Manager hands the work to NSX, which deploys the controller VM, sets its password, forms the one-node cluster, registers it, and creates an NSX cloud on it. About 25 minutes.

What you should see:

5. The welcome wizard

Log in as admin with the password from the store.

Leave Setup cloud after unticked, because the cloud already exists.

Those tenancy defaults suit VCF: isolation between organisations comes from NSX VPCs, and the controller keeps one VRF per VPC in its admin tenant. A single SMALL controller could not afford a Service Engine pair per tenant.

6. Finish the cloud

The cloud NSX creates is not finished. Three things are set on it afterwards, and the third is the one a Supervisor depends on.

uv run --group vsphere scripts/avi_cloud.py            # reports what is set and what is missing
uv run --group vsphere scripts/avi_cloud.py --apply    # sets it and waits for the cloud to be ready

What you should see: CLOUD_STATE_PLACEMENT_READY within a minute or two, and soon after an item in the library — the controller’s own Service Engine image.

The data network is the one to get right before activating a Supervisor. With the cloud’s data_network_config unset, the Supervisor’s Avi operator logs:

Failed to derive cloud, err: cloud not found matching transport zone

The activation finishes once the zone is set. That dependency is not stated in the documentation; it is what this build observed.

7. Enable a VPC for Avi

A VPC is eligible for Avi only when it says so: in NSX, VPCs › the VPC › Advanced settings › Enable for Avi Load Balancer, which is load_balancer_vpc_endpoint.enabled in the API. It needs no Edge cluster. The controller then discovers the VPC and keeps a VRF for it.

A Supervisor turns this on for its own VPCs. For a VPC of your own:

uv run scripts/vpc_test.py --vpc pgnet-core --apply     # a VPC with the Avi endpoint on, a public and a private subnet

Result

Measured 2026-09-20, after both Supervisors were activated against this controller.

• Controller 32.1.3, cluster up, cloud Cloud-nsx placement-ready, and the library holding the Service Engine image.
• Two Service Engines, created by the controller with the first virtual service, on pgvcf1-cl02, taking management addresses 10.134.3.93 and 10.134.3.228 by DHCP. They are shared: the second Supervisor’s services were placed on the same pair.
• Eight virtual services up, four per Supervisor — API, DNS, image proxy and registry. Their VIPs, 10.150.0.6–.9 and .12–.15, were allocated by NSX from the external IP block and are reachable from outside the VPCs.
• The Avi licence is leased on demand: two service cores in use, for the two one-vCPU Service Engines.

Lab-only conditions

References

📖 Reference — VMware Cloud Foundation 9.1 documentation, Design › Load Balancer Detailed Design › Avi Load Balancer Model, pp. 1911–1925. It states that this model needs no Edge cluster and that Service Engine management can use an NSX VLAN segment rather than an overlay segment. Requirements VCF-AVI-LB-REQD-CFG-01 to -04 are in Table 598, p. 1919: configure the NSX cloud, register Avi as an endpoint with NSX, one Avi to one NSX Manager, and “Avi Load Balancer must be integrated with NSX before Supervisor activation” — whose justification reads “If Avi Load Balancer integration is not detected, Supervisor defaults to utilizing NSX load balancer.” Recommendations VCF-AVI-LB-RCMD-CFG-04 (enable VPC mode in the NSX cloud account) and -05 (Service Engine DHCP addressing) are in Table 599, p. 1919, as is -01, which recommends three controllers.

How the load balancer is chosen: vSphere Supervisor Platform › Deploy a Supervisor with VPC Networking, p. 6861 — “If NSX does not detect the Avi Load Balancer, it uses the NSX Edge load balancer” — and p. 6853, “You can only use one load balancer”. The VNA cluster a Supervisor needs for north-south services and Auto-SNAT: VCF-WLDCON-DTGWVLAN-REQD-CFG-013 and -014, Table 575, p. 1844.

VMware Avi Load Balancer 32.1 documentation, Installation Guide › Integration with NSX Multi-Tenancy, pp. 898–927: VPC mode in the NSX cloud configuration (pp. 901–902), the per-VPC load_balancer_vpc_endpoint setting (p. 902), and a dedicated VRF for each NSX VPC (p. 904). Administration Guide › Create a Tenant, pp. 235–239, for the IP route domain and Service Engine context options.

About the references

Page numbers elsewhere in this guide are from the September 2026 build of the VMware Cloud Foundation 9.1 PDF.