OPTIONAL COMPONENT

VCF Automation is optional in a VCF 9.1 deployment. You deploy it only when you want self service provisioning and a catalog on top of your fleet.

What it does: it adds the self service, policy governed infrastructure as a service layer that lets tenants request virtual machines, Kubernetes clusters, and other resources from a catalog.

What it depends on: a running management domain, a healthy VCF Operations instance, the VCF Automation binary in the software depot, and, for real consumption, at least one vSphere Supervisor with NSX networking.

TL;DR

• VCF Automation is deployed as a containerized service inside the VCF Services Runtime cluster, driven from VCF Operations, not as a standalone appliance.
• Reserve a free /29 CIDR on the management network, which gives you the 5 static IP addresses the service runtime needs.
• Prepare two lowercase FQDNs with forward and reverse DNS records: one for the VCF Services Runtime and one for VCF Automation.
• A simple single node deployment uses 24 vCPUs and 96 GB RAM. A medium, highly available three node deployment uses 72 vCPUs and 288 GB RAM.
• Download the VCF Automation binary into the software depot, then run the VCF Automation wizard under Build, Lifecycle, VCF Management, Components.
• Deployment runs for roughly three hours. Verify by signing in to the provider console at the VCF Automation FQDN.

This part shows you how to deploy VCF Automation on an existing VCF 9.1 fleet. You will confirm prerequisites, reserve a network block, place the installation binary in the software depot, run the deployment wizard from VCF Operations, and verify that the provider console comes up and connects to your infrastructure. Because VCF Automation is optional, skip this part if your fleet only needs infrastructure lifecycle and monitoring.

Before you start, make sure the management domain is healthy, VCF Operations is deployed and reachable, and the software depot is online. Have your DNS, NTP, and IP allocation ready. A single VCF Automation instance can manage more than one VCF instance, so decide your tenancy layout before you deploy. If you want to plan tenants and projects first, review the multi tenancy design patterns for VCF Automation.

One thing to understand up front is where VCF Automation actually runs. In VCF 9.x it is not a separate appliance cluster that you power on and manage on its own. It runs as a set of containerized services inside the VCF Services Runtime, and you drive its deployment and lifecycle from VCF Operations. That is why the wizard asks for a network block and two names rather than a single appliance IP, and why the work in this part happens inside the VCF Operations console rather than in a standalone installer.

Confirm every row below before you open the wizard. A missing DNS record or a busy IP address is the most common reason the deployment stops early.

Note. Every FQDN must be lowercase. A capital letter anywhere in a name can cause the deployment to fail, so check the DNS records before you continue.

Pick a size before you start, because it sets how much compute the wizard will claim from the management domain. A single node deployment is fine for a lab or a small footprint. A three node cluster gives you high availability for production. You can convert a single node to a three node cluster later by resizing the nodes to medium or large.

Reserve the /29 block and create the DNS records first, so the wizard passes its checks in one run.

1. Pick a free /29 CIDR on the management VLAN, for example 10.0.0.128/29, and confirm that 5 host addresses inside it are unused.
2. Create a forward DNS record for the service runtime FQDN, for example vcfa-runtime.vcf.lab.
3. Create a forward DNS record for the VCF Automation FQDN, for example vcfa.vcf.lab.
4. Create matching reverse PTR records for both FQDNs.
5. Verify each name with nslookup for forward and reverse, and confirm every FQDN is lowercase.
6. Confirm the management domain has free capacity for your chosen size from the sizing table.

The wizard installs from the software depot, so the binary has to be present and validated before you begin. If the binary is missing, the version dropdown in the wizard will be empty and you cannot proceed. On an online depot you download it directly. On an offline depot you upload the bundle first, then let the depot validate it.

1. Sign in to VCF Operations as an administrator.
2. Go to Fleet Management and open Lifecycle, then Software Depot.
3. Locate the VCF Automation binary for your target version.
4. Click Download to pull it into the depot, or upload it if you run an offline depot.
5. Wait for the status to read Available and confirm the checksum validates.

You start the deployment from the components list in VCF Operations.

1. In VCF Operations, open Build in the left navigation.
2. Click Lifecycle.
3. Select VCF Management, then click Components.
4. Find VCF Automation in the component list.
5. Click Deploy next to VCF Automation to open the wizard.

On the first wizard screen you tell the installer whether this is a fresh deployment and how large to build it.

1. For Deployment Type, select New.
2. If you run Aria Automation in the management domain and want to bring its objects across, select the import option instead of New.
3. Select the VCF Automation version that matches the binary in the depot.
4. Select the VCF Services Runtime cluster size, Simple for a single node or the medium, highly available size for a three node cluster.
5. Click Next.

This screen collects the CIDR, both FQDNs, and the admin password. Enter the values you prepared in Step 1. The fields you fill in are listed below.

1. In Services Runtime CIDR, enter your /29 block, for example 10.0.0.128/29.
2. In Services Runtime FQDN, enter the runtime name, for example vcfa-runtime.vcf.lab.
3. In VCF Automation FQDN, enter the automation name, for example vcfa.vcf.lab.
4. Set the admin password and confirm it.
5. Click Next to run the wizard validation.

Check the summary, then commit. Once you click Finish the installer claims the IP addresses and begins building the cluster.

1. Review the summary screen and confirm the size, CIDR, and both FQDNs are correct.
2. Click Finish to start the deployment.
3. Click View Details to open the task view.

Tip. If you need the service runtime on a network other than the management network, do not run it here. Use the VCF Installer appliance and pick Deploy Deferred Components, which lets you set custom network placement.

Deployment runs for roughly three hours, even on physical hosts, because it builds the runtime cluster and starts the containerized services. Do not close the browser or cancel the task if progress looks slow. A long running step is normal while the container images are pulled and the services come up. If a task turns red, open the details and read the failure before you retry, since a retry on the same underlying problem will fail again.

1. In the task view, watch the backend tasks that deploy the runtime nodes and start the services.
2. Leave the page open, or return to Build, Lifecycle, VCF Management, Components to check progress later.
3. Wait until VCF Operations shows the deployment status as complete for VCF Automation.

After VCF Operations reports the deployment complete, sign in to the provider console and confirm that VCF Automation sees your infrastructure.

1. Open a browser to https://vcfa.vcf.lab/provider, using your VCF Automation FQDN.
2. Sign in as the admin user with the password you set during deployment.
3. Go to Home, then Administration, then VCF Instances, and confirm the SDDC Manager for your fleet appears in the list.
4. Open the Connections tab and confirm the vCenter Server, NSX Manager, and Avi Load Balancer show as healthy.
5. Open the Feature Flags page and confirm the services you plan to use are available to enable.

Back in VCF Operations, the VCF Automation entry under Components should read as deployed and healthy. If both consoles agree, the instance is ready for provider configuration. A quick way to confirm the networking wiring is to check that the Connections tab lists your vCenter, NSX Manager, and Avi with a healthy state and no certificate warnings. If a connection shows as unhealthy, fix it now rather than during tenant onboarding, because the provider setup that follows depends on those connections being clean.

With the provider console reachable and the connections healthy, VCF Automation is deployed. The next stage is provider configuration, where you map regions to Supervisors, define external networks, and onboard your first organization. That work is covered in the parts that follow and in the VCF Automation series linked above.

Is VCF Automation mandatory in VCF 9.1?
No. It is optional. Deploy it only when you want self service provisioning and a catalog. Fleet lifecycle and monitoring work without it.

Why does the wizard ask for a /29 rather than a single IP?
VCF Automation runs as a cluster of containerized services in the VCF Services Runtime, and that runtime needs 5 static addresses, which a /29 provides.

Can one VCF Automation manage more than one VCF instance?
Yes. A single VCF Automation instance can manage multiple VCF instances across sites, which is why you plan tenancy before you deploy.

How long does the deployment take?
Plan for about three hours. It builds the runtime cluster and starts the services, so it runs longer than a single appliance import.

Can I start with one node and grow later?
Yes. You can convert a single node deployment to a three node cluster by resizing the nodes to medium or large.

• Broadcom TechDocs, Start a new VCF fleet or a new VCF instance deployment
• Broadcom TechDocs, Deploy VCF Operations and VCF Automation on the shared management network
• Broadcom TechDocs, VCF Automation deployment models
• Broadcom KB, VCF 9.1 deployment fails on OVA component installation task

« Previous: How to Deploy Avi Load Balancer in VCF 9.1 (Part 10)

Complete guide: VCF 9.1 Deployment Complete Guide

Next: How to Enable vSphere Supervisor and VKS in VCF 9.1 (Part 12)