Welcome to part 9 of the VCF-9.1 home lab series. The previous post in this series discussed deploying the Avi load balancer in the workload domain. In this post, I will demonstrate deploying the supervisor in a workload domain.
If you are not following along, I encourage you to read the earlier parts of this series from the links below:
3: VCF 9.1 Pre-Deployment Planning
4: Setting up VCF 9.1 Offline Depot
5: VCF 9.1 Deploy Management Domain
6: Configure Management Domain Network Connectivity
8: Enable Avi on Workload Domain
While creating a new workload domain, you will observe that the toggle button for enabling supervisor post domain deployment is activated. You can turn off the toggle if you wish. I did the same, as I wanted to cover this topic in a separate post and discuss the networking stack on which a supervisor can be deployed. This post assumes that you have already configured networking connectivity for the workload domain.
If there is one capability that defines VMware Cloud Foundation 9.x as a modern private cloud platform, it is the vSphere Supervisor. Enabling the Supervisor in a workload domain is the moment your VCF environment transforms from a sophisticated virtualization stack into a full-stack application platform—one that can serve both traditional VM workloads and cloud-native, containerized applications through a unified, declarative API surface.
The supervisor is not a separate product. It is the consumption layer of VCF, the fabric on which VCF Automation builds its “All Apps” organizations.
Supervisor Architecture: Single-Zone vs. Multi-Zone
Single-Zone Supervisor
A single-zone supervisor uses a single vSphere cluster to host both workloads and supervisor control plane components. It is the most common starting point and can be enabled either during workload domain creation or post-creation via the Supervisor Management wizard in vCenter. After initial enablement, additional vSphere Zones can be added. However, those additional zones are used exclusively for workload placement—the control plane components (the three control plane VMs) remain pinned to the original cluster.
A single-zone supervisor is best suited for environments with a single availability zone, lab deployments, and proof-of-concept environments.
A Supervisor deployed in a single-zone configuration cannot be converted to a multi-zone deployment after enablement. Plan your topology before you begin.
Multi-Zone Supervisor
A multi-zone supervisor uses three vSphere clusters, each placed into its own vSphere zone. Both workloads and the supervisor control plane components are distributed across all three zones, providing true high availability. Each zone becomes an independent, consumable availability zone visible to tenants in VCF Automation.
A multi-zone supervisor is best suited for environments with strict HA requirements across availability zones and environments targeting enterprise-grade fault tolerance.
A multi-zone supervisor enablement currently requires the vSphere API—the VCF Operations UI only supports single-zone deployments. You must pre-create vSphere zones in vCenter, then invoke the Supervisor enablement API to deploy across three zones.
This blog demonstrates a single-zone supervisor deployment because of resource constraints.
Prerequisites
Infrastructure Prerequisites
| Component | Requirement |
| Workload Domain | Fully deployed with vCenter and NSX Manager. |
| ESXi Hosts | Minimum 3 hosts in the cluster; commissioned with the target principal storage type. |
| vSphere HA | Enabled with DRS in fully automated mode. |
| vSphere Lifecycle Manager | A cluster image must be available and applied. |
| Storage Policy | Must support thick provisioning for control plane VMs. |
NSX Prerequisites
| Component | Requirement |
| NSX Edge Cluster | Deployed with a large form factor Edge VMs |
| Tier-0 Gateway | Deployed in Active/Standby HA mode |
| Connectivity Profile | NSX VPC Connectivity Profile configured with external IP blocks |
Important: The Tier-0 Gateway must be Active/Standby if you intend to use VKS or VCF Automation All Apps organisations. Active/Active does not support NAT, which is automatically applied to VPC gateways. This is a hard architectural constraint.
Supervisor and NSX VPC’s
The supervisor can be enabled on VDC networking as well as on the NSX VPC networking (required for VCFA). The recommended networking model for the VCF 9.1 supervisor is the latter. This is the path required for VCF Automation All Apps organizations. The following are the prerequisites for the NSX VPC path.
- External IP Block — a routable IP range for north-south services (NAT, load balancers). This block is advertised to upstream routers via BGP.
- Private Transit Gateway IP Block — private IPs for Transit Gateway subnets (not advertised northbound).
- Five consecutive static IP addresses from the external/management IP space for the Supervisor Control Plane VMs (3 VMs + 1 floating IP + 1 reserved for updates).
Let’s see the deployment in action now.
Step 1: Create Tags & Storage Policy: If your environment uses VMFS on FC as the principal storage for the workload domain, you must tag the VMFS datastore first and create a storage policy before supervisor enablement.
Note: If your environment uses vSAN as principal storage, this step is optional, as you can use the default vSAN storage policy.
Login to the vCenter UI and open the Tags & Custom Attributes settings. Under the TAGS section, click New to create a new tag.
Assign a name for the tag and click the search icon for the category.
Select the datastore object from the list and click Create.
Apply the tag by right-clicking the VMFS datastore > Assign Tag.
Select the newly created tag from the list and click Assign.
Navigate to the VM Storage Policies page and click Create.
Specify the storage policy name and click Next.
Under datastore rules, select “enable rules for VMFS storage.”
Set the volume allocation type to “fully initialized.”
Important: Don’t use the conserve space allocation type, as it freaks out the supervisor, and the pods never come up on the supervisor VMs. I made this mistake in my lab, and it took me hours to figure this out.
Under the Tags section, click Add Tag Rule.
Select the tag category created earlier and set the usage condition to “use storage tagged with.”
Click the Browse Tags button, select the tag, and click OK.
Validate that the VMFS datastore that you tagged earlier is visible under compatible storage.
Click Finish to close the storage policy creation wizard.
Step 2: Enable Supervisor
Navigate to the Supervisor Management page and click “Get Started.”
Assign a content library for storing the K8 images.
Select the networking stack for the deployment. I selected the NSX VPC stack as I plan to deploy VCF Automation later.
Select the supervisor location. I selected cluster deployment because I only have one vSphere cluster in my lab.
Specify the supervisor name and select the vSphere cluster where the deployment takes place. Leave the vSphere zone name empty, as the supervisor auto-populates this.
Select the storage policy that you created earlier.
Select the IP assignment mode for the supervisor and fill in the networking details. I deployed the supervisor on the management network, where all other infra components were deployed.
Select the NSX project where the supervisor will be deployed. I selected the default project for this purpose. In this project, the supervisor creates a couple of VPCs for the workload networking.
Select the VPC connectivity profile and IP blocks for the external and transit gateway connectivity.
Important: In VCF 9.0, the supervisor didn’t have a hard requirement for the private transit gateway CIDR, and a /24 works just fine. This has changed in VCF 9.1. Now, you need a /16 network for this. If you attempt with a /24, the deployment never completes.
Select the size of the control plane VMs. You can export the configuration for reusability.
Click Finish to initiate the deployment.
It takes roughly 45 minutes for the deployment to complete (assuming you did not run into any issues).
Go to the services tab to see the services that are enabled on the supervisor by default. You can install new services from her.
With the supervisor running, the next operational task is creating vSphere Namespaces—the primary tenancy construct exposed to DevOps teams. This topic will be covered in a later psot where I will discuss VCFA + VKS working hand in hand.
What Happens Under the Hood
- A VPC named vmware-system-supervisor-services-vpc_<id> is created and houses the supervisor’s system services.
- A VPC named kube-system_<id> is created, and the load balancers are mapped here to serve the Kubernetes API, CSI controller, and other system services.
- SNAT Rule—provides egress for the supervisor management network with an IP address from the external IP block.
- Private Subnet — for the kube-system and supervisor-service VPCs.
And that’s it for this post. In the next post of this series, I will discuss VCF Automation deployment. Stay tuned!!!
I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing.