This part walks you through deploying the VCF Installer appliance for VMware Cloud Foundation 9.1. This appliance is the component that runs every readiness check and then builds the management domain, so it comes before any other product in the deployment. You deploy it once as a single OVA, give it a static identity on your management network, and log in to its browser interface. Later parts use this same appliance to run the bring-up.

Before you start, confirm the prerequisites from the earlier parts are in place: your management network exists, DNS forward and reverse records resolve, and an NTP source answers on the management subnet. Have the Broadcom Support Portal credentials ready, because the OVA download is entitlement gated. Plan for roughly 30 to 45 minutes end to end, most of which is the OVA transfer and first boot.

Prerequisites

Gather these values and confirm each service before you open the deploy wizard. A missing reverse DNS record or an unreachable NTP server is the most common reason a later precheck stops the bring-up.

Step 1 prepare DNS and NTP records

Create the DNS records first. Add an A record that maps the appliance FQDN, for example vcf-installer.lab.local, to the static IP you reserved, and add the matching PTR record so the reverse lookup returns that same FQDN. Test both directions from a workstation on the management network before you go further. A forward record without a reverse record passes the OVA deploy but fails the installer precheck later.

Confirm your NTP server answers on the management subnet. Point the appliance at the same NTP source your ESX hosts use, because a time gap between the installer and the hosts causes certificate and join failures during bring-up. Note the NTP server address and the DNS server addresses now, since you enter them in the wizard.

Step 2 confirm network reachability and services

Decide where the appliance will live. If you deploy it outside the management infrastructure, on any host with connectivity to the management network, you can reuse it to deploy more than one VCF or vSphere Foundation instance. If you deploy it onto one of the ESX hosts that will form the management domain, that appliance can build only a single VCF instance. For most production builds, place it outside the future management cluster on a separate host or an existing vSphere environment.

From that host, check that the chosen network can reach the ESX hosts, the VM management network, DNS, and NTP. Blocked routes here surface as confusing precheck errors much later, so it pays to test them up front with a simple ping or a port check.

Step 3 download the VCF Installer OVA

Sign in to the Broadcom Support Portal with an account entitled to VMware Cloud Foundation 9.1. Open the VCF 9.1 product downloads, locate the VCF Installer OVA for the 9.1 release, and download it. Record the build number shown next to the file so you can confirm it matches the release notes for the version you intend to run. Keep the OVA on a machine that can reach the target host or vCenter you will deploy from.

Validate the download before you use it. Compare the file size and, where a checksum is published, the hash against the values on the download page, since a truncated OVA fails partway through deployment and wastes time. Read the 9.1 release notes for the build you pulled and confirm it is the version you intend to run across the rest of the deployment, because mixing an installer build with mismatched component binaries leads to avoidable bring-up errors.

Step 4 start the OVF deployment wizard

Deploy the OVA the same way you would any appliance. In the vSphere Client, right click the target host or cluster and choose Deploy OVF Template, or on a standalone ESX host open the host UI and click Create/Register VM, then Deploy a virtual machine from an OVF or OVA file. Work through the wizard as follows.

1. Select the OVA file you downloaded, then click Next.
2. Enter a virtual machine name, for example vcf-installer, and pick the compute location.
3. On the storage page, select a datastore with at least 914 GB free. Thin provisioning is fine for a lab, but plan for thick provisioning on production storage.
4. Read and accept the license agreement.
5. On the network page, map the source network to the port group that reaches your management network, DNS, and NTP.

Deploying from vCenter gives you cluster placement and a progress bar for the upload, while a standalone ESX host works when you have no vCenter yet, which is common on a first build. Either path lands the same appliance. Watch the upload complete before moving on, since a dropped transfer can leave a half registered virtual machine that you then delete and redeploy.

Do not click Finish yet. Values on the next page apply the appliance identity and passwords, which matter more than any other input in this deployment.

Step 5 set passwords and network properties

On the Customize template page, fill in the OVF properties. Enter the passwords for the root and admin@local accounts, then the network identity. Every field here is baked into the appliance at first boot, so a typo means redeploying rather than editing. Use the FQDN, not a short name, for the hostname field.

Note. Passwords must be 15 characters or longer. Allowed special characters are limited to ! @ # $ % ^ & and *. Other symbols are rejected and force a redeploy.

Review the summary page, confirm the datastore and network are correct, then click Finish. The appliance now deploys and powers on. It reads the values you entered and configures itself on first boot.

Step 6 power on and let the appliance configure

Once deployment finishes, power on the virtual machine if it did not start automatically. First boot applies the hostname, IP, DNS, and NTP settings and starts the installer services. Give it a few minutes. You can watch progress from the VM console, which shows the appliance settling into a login prompt with its configured hostname.

If the console shows the default DHCP address or a blank hostname after several minutes, the OVF properties did not apply. Confirm you filled in the customize page rather than skipping it, then redeploy. A correctly configured appliance shows its FQDN and static IP at the console login.

Verify the deployment

Run two quick checks to confirm the appliance is healthy before you move on to the management domain.

First, open a browser and go to https://vcf-installer.lab.local, using your own FQDN. Sign in with admin@local and the password you set. A working login on the installer administration interface is the clearest sign the appliance deployed and configured correctly.

Second, connect over SSH with the vcf account and the password you set. From that shell, resolve the appliance FQDN in both directions and query your NTP source. Forward and reverse lookups that return the right values, plus an NTP server that responds, tell you the network settings took effect. If either check fails, fix DNS or NTP before starting bring-up, because the installer runs these same checks and will stop if they fail.

As a last check, confirm the installer services are running. From the admin interface you should reach the landing view without errors, and an SSH session should return a clean status for the core services. A healthy appliance here means you can move straight into deploying the management domain in the next part.

flowchart TD
    A[Create DNS forward and reverse] --> B[Confirm NTP reachable]
    B --> C[Download VCF Installer OVA]
    C --> D[Run OVF deploy wizard]
    D --> E[Set passwords and network]
    E --> F[Power on and auto configure]
    F --> G[Log in as admin at local]
    G --> H[Verify DNS and NTP over SSH]
    H --> I[Ready for management domain bring up]

Common errors and fixes

Four failures account for most stuck deployments. Each one has a direct fix.

For a lab or proof of concept without vSAN ESA certified hardware or 10 GbE NICs, you can relax two validation checks on the installer before bring-up. Set the vSAN ESA managed disk claim property and disable the physical NIC speed validation in the domain manager properties, then restart the installer services. Apply these only in non production labs, since they turn off checks that protect a supported build.

Common questions

Is the VCF Installer the same as Cloud Builder
It is the successor. In VCF 5.x you deployed Cloud Builder to run bring-up. In VCF 9.x that role belongs to the VCF Installer appliance, with a refreshed interface and the same job of validating and building the environment.

Can one installer build more than one environment
Yes, when you deploy it outside the management infrastructure. An installer placed on a separate host can deploy multiple VCF or vSphere Foundation instances. One deployed onto a future management host builds a single instance.

Do you keep the appliance after bring-up
Keep it if you plan to build more domains or instances from it. In a single instance build you can power it off once the management domain is up, though many teams retain it for later work.

What if a field was entered wrong
Because the values apply at first boot, redeploy the OVA with the correct entries rather than trying to edit them in place. Delete the misconfigured appliance and run the wizard again.

References

• VMware Cloud Foundation 9.1 documentation, Broadcom TechDocs
• VMware Cloud Foundation blog, Broadcom
• Minimal resources for deploying VCF in a lab, William Lam
• VCF 9.1.x Ultimate Deployment Guide, Leaha Blog

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts