Skip to content
Documentation

VMWare VCF Automated deployment

MetalSoft provides an application extension for deploying VMware Cloud Foundation (VCF) automatically. The currently supported version is VCF 9.0.1, via the vmware-cloud-foundation9 extension. The extension’s README documents every input and the full deployment flow — this page covers the MetalSoft-side setup.

The older extension for VCF 5.2.1 is still available at vmware-cloud-foundation.

What changed vs. VCF 5.2.x

Section titled “What changed vs. VCF 5.2.x”
  • Cloud Builder is gone — it is replaced by the VCF Installer appliance (the same OVA as SDDC Manager). Per the Broadcom 9.0.1 BOM, the VCF Installer 9.0.2.0 OVA is used to deploy the 9.0.1 components — this is intentional, not a version mismatch.
  • The installer embeds no product binaries — everything (vCenter, NSX, SDDC Manager, VCF Operations, …) is pulled from an offline depot mirror over HTTPS with basic auth.
  • No license keys at bring-up — the deployment runs in 90-day evaluation mode; licensing is applied post-deploy in VCF Operations.
  • Larger management footprint — a minimum of 7 management VMs are deployed (vCenter, 3× NSX Manager + VIP, SDDC Manager, VCF Operations, Operations fleet management, Operations collector); VCF Automation is optional.

Requirements

Section titled “Requirements”
  1. Hosts: minimum 3 (4 recommended and default) vSAN-capable hosts for the management domain, each with at least two NICs at 10 Gbps or faster. Identical hardware (vendor, model, CPU, memory, disks, NICs) is strongly recommended. Check the VMware compatibility guides for supported hardware.
  2. ESXi template: the hosts must be pre-installed with exactly ESX 9.0.1.0-24957456 — OS template esxi-9.0-24957456-cluster-node (see below).
  3. Offline depot: an offline depot mirror reachable from the installer, serving /PROD (the product version catalog and component binaries, including the ESX 9.0.1 ISO) over HTTPS with basic auth.
  4. DNS: a routable DNS zone for all management FQDNs (do not use a .local domain), and a DNS provisioning workflow extension (e.g. PowerDNS) installed and enabled at the site so that the records the platform allocates actually resolve. VCF validation requires the full forward and reverse (PTR) round-trip to succeed.
  5. Ansible Runner: enabled on the site controller — see Enabling the Ansible Runner Capability.

Registering the ESXi 9 template

Section titled “Registering the ESXi 9 template”

1a. Create the MetalSoft ESXi template (with internet access):

metalcloud-cli os-template list-repo
metalcloud-cli os-template create-from-repo ESXi/9.0/esxi-9.0-24957456-cluster-node

1b. Create the MetalSoft ESXI template (airgapped) In an air-gapped environment, on a machine with internet access clone the github repository

git clone https://github.com/metalsoft-io/os-templates

Copy the os-templates directory to the machine where the CLI can be executed that has access to the Global Controller. The os-templates directory should contain the .git files.

metalcloud-cli os-template list-repo --repo-url /path/to/os-templates
metalcloud-cli os-template create-from-repo ESXi/9.0/esxi-9.0-24957456-cluster-node --repo-url /path/to/os-templates
  1. Update the template’s ISO URL asset to point at the ESX 9.0.1 installer ISO hosted on your repository. The template must install exactly build 9.0.1.0-24957456 — the extension’s preparation role verifies the ESXi version and that the host certificate CN matches the host FQDN.

Registering the VCF 9 extension

Section titled “Registering the VCF 9 extension”
  1. Clone the repository:
Terminal window
git clone https://github.com/metalsoft-io/metalsoft-extensions
cd metalsoft-extensions/vmware-cloud-foundation9
  1. Build and upload the Ansible bundle (playbooks at the archive root — see Structuring Ansible bundles):
Terminal window
(cd ansible && zip -r ../vmware-cloud-foundation9-v2.1.0.zip . -x '*.DS_Store' -x '*.zip' -x 'README.md')

Upload the zip to a repository reachable by the Global Controller and set its URL as the vcf-ansible-bundle asset’s url in extension.json.

  1. Build and publish the execution environment image — the container image in which the Site Controller runs the extension’s Ansible tasks; every dependency the playbooks use must be baked into it. Build it from the bundled execution-environment.yml (it pulls in the VMware SDKs, Galaxy collections and CLI tools the playbooks need):
Terminal window
ansible-builder build --file execution-environment.yml \
    --tag <registry>/<namespace>/vcf9-ee:9.0.1 \
    --container-runtime docker \
    --extra-build-cli-args "--platform=linux/amd64"

The image must be linux/amd64 (site controllers run x86_64 and the EE compiles native wheels). Push it to a registry reachable by the Site Controller, and update the ee-vcf9-9-0-1 asset’s registry fields (and, for air-gapped sites, host a docker save | gzip tarball at the asset’s url).

  1. Adapt extension.json to your environment before registering — at minimum:

    • change every *_password input default — the committed values are placeholders; new values must satisfy the inputs’ validationRegEx (^[A-Za-z0-9!@#$%^&*+]{12,20}$ — the charset all VCF components accept);
    • the infrastructure.logicalNetworks[].profileLabel values must match logical network profiles that exist at the target site (see below);
    • both asset URLs from steps 2 and 3;
    • optionally, adjust the configVars defaults (depot location, appliance sizing, etc. — see step 6) so operators don’t have to override them at every site.

  2. Register, publish and (optionally) make the extension public:

Terminal window
metalcloud-cli extension create "VMware Cloud Foundation 9 (VCF)" application "VMware Cloud Foundation (VCF)" --definition-source extension.json
metalcloud-cli extension publish <id-of-created-extension>
metalcloud-cli extension make-public <id-of-created-extension>

  1. Activate the extension on the site level and configure its configVars. After publishing, the extension must also be activated per site, on the site level configuration page, and its site configuration saved before the first deploy. All the admin/site-level settings live in configVars and are set once per site (not per deployment); config vars without a default — currently depot_password — are mandatory at that point. The most important ones:

    • DNSResolvers — set it to your site’s internal resolvers (comma-separated). These resolvers are configured on all hosts and appliances and must be able to resolve the management DNS records; handing VCF a public resolver breaks bring-up.
    • depot_hostname / depot_port / depot_username / depot_password — point at your offline depot mirror.
    • ova_name / ova_url / vcf_version — leave as-is for the 9.0.1 BOM (the 9.0.2.0 installer OVA is intentional).
    • nsx_manager_size / vcenter_vm_size / vcf_ops_appliance_size — appliance sizing (NSX small no longer exists in 9.x).
    • deploy_vcf_automation / vcf_automation_internal_cluster_cidr — enable VCF Automation and adjust its internal CIDR if it would overlap existing networks.
    • deploy_without_license_keys — must stay true on VCF 9 (bring-up runs in evaluation mode).

    See the extension README for the full config var table.

At instance-create time the operator only fills in the deployment-specific inputs: server type, node count, OS template, the appliance passwords and, optionally, vcf_instance_name (when unset the playbooks derive <extension_instance_id>-vcf).

Preparing logical networks

Section titled “Preparing logical networks”

The extension declares 4 logical networks; a logical network profile with the matching label must exist at every site where VCF will be deployed:

Go to Admin > Fabrics > fabric > Logical networks and create the following (the labels need to match the extension definition’s profileLabel values):

  • vcf-mgmt — tagged: true, Active-Active redundancy. Provides the default route and carries all the management appliance IP allocations and DNS records. Ensure this network has access to the Site Controller, in-band (set the correct VLAN id and/or IP ranges).
  • vcf-vsan — tagged: true, Active-Active redundancy. Carries an IP pool handed to VCF for vSAN vmkernel addressing.
  • vcf-vmotion — tagged: true, Active-Active redundancy. Carries an IP pool for vMotion vmkernel addressing.
  • vcf-nsx — tagged: true, Active-Active redundancy. Carries an IP pool for NSX TEP addressing.

Set the IPv4 allocation strategy to Auto with sufficiently large subnets — the extension requests 8 addresses for vSAN, 8 for vMotion and 20 for NSX, plus the management allocations (installer, SDDC Manager, vCenter, 3× NSX Manager + VIP, the VCF Operations appliances and, optionally, VCF Automation) on vcf-mgmt.

Scaling the management domain

Section titled “Scaling the management domain”

Scaling is driven by editing the mgmt_domain_instance_count input on the deployed instance (default 4, min 3, max 16). On save, the platform adjusts the servers and runs the onEdit lifecycle: outgoing hosts are removed from the cluster and decommissioned in SDDC Manager at preDeploy (while still reachable), and new hosts are prepared, commissioned and added to the cluster at postDeploy. Scaling requires a successfully completed initial deployment, and the new hosts must meet the same hardware/ESX build requirements as the initial ones.

Deploy a test VCF cluster

Section titled “Deploy a test VCF cluster”

From the Infrastructure Designer add a new VCF cluster from the list, fill in the form and deploy. The initial bring-up takes several hours (depot binary downloads plus ~3 hours for the management domain bring-up on physical hosts).