VMware Cloud Foundation 9: End-to-End Setup -- VCF Installer, VCF Operations, Workload Domains, and Day 2

Standalone Infrastructure | Component: VMware Cloud Foundation 9.0 | Audience: Enterprise Architects, Cloud Infrastructure Admins

VMware Cloud Foundation 9 is a significant departure from what came before it. The VCF Installer appliance is new. VCF Operations is now mandatory and has absorbed most of SDDC Manager's administrative functions. The SDDC Manager UI is deprecated, its removal coming in a future major release. The fleet construct is new. Workload domain deployment, host commissioning, and cluster expansion have all moved to different consoles than where they lived in VCF 5.x. If you're coming from VCF 5.2 or building from scratch, the mental model for where to perform which operation has changed substantially.

This article covers VCF 9 end to end as a standalone infrastructure piece: hardware and pre-install requirements, the VCF Installer and bring-up process, VCF Operations and what it does, workload domain deployment, NSX networking, vSAN in the VCF context, lifecycle management with vLCM, and Day 2 operations. The existing article in this series covers Veeam v13 backup protection on VCF 9 specifically. This one is the infrastructure layer underneath that.

1. Architecture Overview: What Changed in VCF 9

Understanding the VCF 9 architecture before touching anything saves significant confusion during deployment. Three concepts are new or substantially changed from VCF 5.x.

The Fleet and the Instance

VCF 9 introduces the concept of a fleet: one or more VCF instances managed centrally by VCF Operations. A VCF Instance is the deployable unit that contains a management domain, workload domains, vCenter, NSX, SDDC Manager, and the underlying vSAN cluster. The fleet sits above it: VCF Operations and VCF Automation are fleet level services that manage across multiple instances. For a single-site deployment with one set of infrastructure, you have one fleet with one instance. Multi-site environments have one fleet managing multiple instances.

VCF Operations is Mandatory

VCF Operations replaces the SDDC Manager UI as the primary management console for VCF administrative tasks. It's not optional in VCF 9: the deployment process installs it automatically. SDDC Manager is still installed as a component of the VCF instance and still runs backend workflows, but its UI is deprecated. You won't find licensing, certificates, password management, or backup configuration in the SDDC Manager UI anymore. Those functions moved to VCF Operations.

Where Things Live Now

2. Hardware and Pre-Install Requirements

VCF 9 imposes stricter hardware requirements than standalone vSphere. The management domain alone requires four ESXi hosts for the recommended consolidated design, or three if you're using vSAN with external storage. All hosts must be on the VMware Compatibility Guide. VCF does not support uncertified hardware, and the bring-up prechecks will fail explicitly on hardware that doesn't pass validation.

Minimum Host Counts

• Management domain, consolidated design: Four hosts recommended, three minimum with vSAN. The management domain hosts the VCF Operations appliances, SDDC Manager, vCenter, and NSX Manager cluster alongside management workloads.
• VI workload domain: Three hosts minimum for vSAN FTT=1. Four recommended.
• Simple Model deployment (minimum appliances): Seven appliances: one vCenter, one SDDC Manager, one NSX Manager, plus VCF Operations Manager, a Fleet Management appliance, a VCF Operations collector, and one VCF Automation appliance.
• High Availability Model (production): Thirteen appliances: the above plus three NSX Manager nodes and three VCF Operations nodes instead of single instances. High Availability Model is required for production deployments.

Pre-Install Checklist

• DNS: Forward and reverse DNS entries for all appliances, all ESXi hosts, all NSX components, and the VCF Installer appliance itself. VCF bring-up performs DNS validation and will fail if any entries are missing or incorrect.
• NTP: All hosts and the management network must be synchronized. Time drift exceeding a few seconds will fail vSAN and NSX bring-up operations.
• vSphere Lifecycle Manager: All ESXi clusters must be managed by vLCM image management, not baselines. Baselines are not supported in VCF 9. If you're upgrading from VCF 5.2, all clusters must be converted to vLCM image management before upgrading.
• Network topology: Management, vMotion, vSAN, and uplink networks fully configured on all physical switches before running the installer. VCF bring-up doesn't configure physical switches. It validates that the expected networks exist and are reachable.
• Download token: A Broadcom download token is required to pull binaries during bring-up. Obtain this from the Broadcom Customer Connect portal before starting. Offline depot is supported as an alternative for air-gapped environments.

3. The VCF Installer and Bring-Up Process

The VCF Installer is a new appliance introduced in VCF 9. It replaces the manual process of staging the cloud builder VM that was used in earlier VCF versions. The Installer is an OVA you deploy to an existing ESXi host or workstation. It runs a browser based wizard that walks through the entire initial deployment, validates prerequisites, downloads binaries, and deploys all components in sequence.

Deployment Pathways

VCF 9 offers three pathways depending on your starting point:

• New deployment: Deploy the VCF Installer OVA, run the bring-up wizard, deploy from scratch on bare metal ESXi hosts. This is the greenfield path covered in detail below.
• Converge existing vSphere: The VCF Installer can convert an existing standalone vCenter deployment into a VCF management domain. Existing VMs stay running during the conversion. The existing vCenter becomes the management domain vCenter.
• Upgrade from VCF 5.x: The primary upgrade path is from VCF 5.2. Earlier versions require a multi-step journey. The upgrade sequence is: VCF Operations components first, then SDDC Manager, then NSX, then vCenter, then ESXi hosts.

Bring-Up Sequence for New Deployments

1. Deploy the VCF Installer OVA onto a temporary ESXi host or workstation with network access to the management network. Power it on and access the web interface on port 8443.
2. Configure the depot connection. Choose online depot (requires download token and internet access) or offline depot. The Installer downloads all required binaries: ESXi, vCenter, NSX, SDDC Manager, VCF Operations components. This download can take an hour or more depending on bandwidth.
3. Prepare the deployment specification. The Installer generates a JSON specification file based on your input through the wizard. This file defines every component: hostnames, IPs, passwords, network topology, vSAN configuration, and NSX sizing. You can also prepare this JSON manually and import it. The JSON spec is the source of truth for the deployment. Save a copy after bring-up.
4. Run prechecks. The Installer validates DNS, NTP, network reachability, and hardware compatibility against the VCG for all target hosts before making any changes. Fix all precheck failures before proceeding. There's no safe rollback once bring-up starts deploying components.
5. Execute bring-up. The Installer deploys vCenter, configures vSAN, deploys NSX, deploys SDDC Manager, then deploys VCF Operations. Each step validates the previous one before proceeding. Total time for a new four node management domain is typically two to four hours depending on hardware performance.
6. Launch VCF Operations. After successful bring-up, the Installer provides a direct link to VCF Operations. This is now your primary management console for all VCF administrative tasks.

{
  "sddcId": "m01",
  "vcfInstanceName": "vcf-prod",
  "workflowType": "VCF",
  "version": "9.0.0.0",
  "ceipEnabled": false,
  "dnsSpec": {
    "nameservers": [ "10.0.100.10" ],
    "subdomain": "vcf.yourdomain.local"
  },
  "ntpServers": [ "10.0.100.10" ],
  "vcenterSpec": {
    "vcenterHostname": "vcf-m01-vc01.vcf.yourdomain.local",
    "rootVcenterPassword": "YourVcenterPassword!",
    "vmSize": "small",
    "adminUserSsoPassword": "YourSSOPassword!",
    "ssoDomain": "vsphere.local",
    "useExistingDeployment": false
  },
  "clusterSpec": {
    "clusterName": "m01-cl01",
    "datacenterName": "m01-dc01"
  },
  "datastoreSpec": {
    "vsanSpec": {
      "esaConfig": { "enabled": true },
      "datastoreName": "m01-cl01-ds-vsan01"
    }
  },
  "nsxtSpec": {
    "nsxtManagerSize": "medium",
    "nsxtManagers": [
      { "hostname": "vcf-m01-nsx01.vcf.yourdomain.local" },
      { "hostname": "vcf-m01-nsx02.vcf.yourdomain.local" },
      { "hostname": "vcf-m01-nsx03.vcf.yourdomain.local" }
    ],
    "vipFqdn": "vcf-m01-nsx.vcf.yourdomain.local",
    "useExistingDeployment": false,
    "nsxtAdminPassword": "YourNSXPassword!"
  }
}

4. VCF Operations: The New Primary Console

VCF Operations is the convergence of what was previously SDDC Manager, Aria Operations, Aria Operations for Logs, and Aria Operations for Networks into a single platform. It's not just a UI wrapper. The platform has its own database, its own appliances, and its own lifecycle separate from the VCF instance it manages.

The VCF Operations interface has two primary navigation areas:

• Fleet Management: Manages the fleet level concerns: lifecycle updates for VCF Operations itself, certificates, passwords, SFTP backup settings, and identity and access management across the fleet.
• Inventory, VCF Instance: Manages instance level concerns: workload domain deployment, VCF instance settings (DNS, NTP, backup), and the operational view of the instance's components.

VCF Operations is decoupled from the VCF core upgrade cycle. Broadcom can release VCF Operations updates independently of ESXi, vCenter, and NSX upgrades. This means you can apply VCF Operations fixes without touching the rest of the stack. It also means you need to track two update streams: the VCF core stack and VCF Operations separately.

5. Workload Domain Deployment

A workload domain is a separate vCenter instance with its own cluster, vSAN datastore, and NSX instance, providing dedicated resources for a specific set of workloads or a specific team. The management domain always exists. VI workload domains are created on demand to expand the platform.

Host Commissioning

Before a host can be added to a workload domain, it must be commissioned. In VCF 9, commissioning happens in vCenter. Navigate to Global Inventory List, then Hosts, then Unassigned Hosts. Hosts that have been prepared with ESXi and are reachable on the management network appear here after VCF validates them. Commissioning assigns the host to VCF management and makes it available for workload domain assignment.

Deploying a VI Workload Domain

1. In VCF Operations, go to Inventory and select your VCF Instance.
2. Click Actions and select Add Workload Domain. Choose VI (vSphere with NSX) or vSphere Foundation based on your licensing.
3. Select the commissioned hosts to assign. A minimum of three is required for vSAN FTT=1.
4. Configure the vCenter spec: hostname, size, SSO domain. The workload domain vCenter will join the same SSO domain as the management domain vCenter via Enhanced Linked Mode.
5. Configure the NSX spec. You can deploy a new NSX instance for this workload domain or share the management domain NSX instance. Sharing NSX simplifies management but creates a dependency between domains. Separate NSX instances provide blast radius isolation.
6. Configure vSAN for the new cluster or select external storage if the workload domain will use SAN or NFS.
7. Review the deployment spec and click Deploy. VCF Operations orchestrates the deployment: vCenter deploys first, then NSX, then vSAN configuration.

6. NSX Networking in VCF 9

NSX in VCF 9 is deployed automatically by the bring-up process for the management domain. For workload domains you choose whether to deploy a dedicated NSX instance or share the management domain's NSX. Understanding the NSX topology is important before deploying workload domains because changes to NSX after deployment are operationally significant.

NSX Manager Cluster

The NSX Manager cluster is three NSX Manager nodes behind a virtual IP (vIP). All management traffic goes to the vIP. The three nodes provide HA: the cluster stays operational with two of three nodes available. NSX Manager runs as VMs in the management domain. The bring-up spec defines the size of each NSX Manager node: small (16 GB RAM), medium (24 GB RAM), or large (48 GB RAM). Medium is appropriate for most production environments. Large is required for environments with over 400 hosts or 6,000 VMs.

NSX Edge Cluster

The NSX Edge cluster handles North South traffic: routing between the NSX overlay network and the physical network. In VCF 9, NSX Edge cluster deployment is initiated through vCenter rather than SDDC Manager. Navigate to the network object in vCenter, then select Network, then Network Connectivity to deploy an Edge cluster.

Edge nodes run as VMs on dedicated hosts or on the same hosts as workload VMs. The production recommendation is dedicated Edge hosts in a separate cluster to avoid resource contention between Edge forwarding plane traffic and VM workloads. Shared Edge deployment (Edge VMs on workload hosts) is acceptable for smaller environments where the additional hosts aren't justified.

Segment Design

NSX segments are the logical switching layer: virtual networks that VMs connect to. VMs on NSX segments can communicate with each other regardless of which physical host they're on, as long as both hosts are in the same NSX transport zone. Segments connect to Tier-1 gateways for routing between segments, and Tier-1 gateways connect to a Tier-0 gateway for routing to the physical network via the Edge cluster.

7. vSAN in the VCF Context

VCF uses vSAN as its native storage layer. vSAN is not optional if you want the full SDDC stack: VCF's automation and lifecycle management are designed around vSAN as the storage provider. External storage (iSCSI, NFS, FC SAN) is supported for workload domains but not for the management domain itself, which must use vSAN.

OSA vs ESA in VCF 9

vSAN OSA (Original Storage Architecture) is not deprecated in VCF 9. Both OSA and ESA are fully supported. ESA requires NVMe only disks and delivers higher performance and simpler management (storage pools replace disk groups). OSA works with SAS and SATA SSDs alongside NVMe and is the right choice when your hardware doesn't meet ESA's NVMe requirements.

The vSAN architecture (OSA or ESA) is defined in the deployment specification before bring-up and can't be changed after the cluster is created without rebuilding. This is the same constraint as in standalone vSAN. Decide before you run bring-up.

Storage Policies in VCF

VCF creates default vSAN storage policies during bring-up: vSAN Default Storage Policy (FTT=1, RAID-1) and VCF Management Storage Policy (used for management VMs). You can create additional policies through vCenter's storage policies interface. The VCF bring-up documentation recommends keeping management domain VMs on FTT=1 at minimum, with critical management VMs on FTT=2 (requires five hosts minimum) for environments that can afford the additional host count.

Stretched Clusters

VCF 9 adds official documentation and support for stretched cluster topologies including multi-site, multi-rack, and stretched cluster configurations. A stretched vSAN cluster in VCF spans two sites (or two racks), with a witness host or appliance at a third site providing the tiebreaker vote. VMs survive the loss of an entire site with automatic restart at the surviving site. Stretched clusters require the vSAN Enterprise license tier, low latency connectivity between sites (under 5ms RTT for synchronous mirroring), and a routed path to the witness.

8. Lifecycle Management with vLCM in VCF

VCF 9 requires vLCM image management for all ESXi clusters. Baselines are not supported. Every cluster must have a vLCM image defined that specifies the ESXi version, firmware versions, and driver versions for every host in that cluster. VCF Operations orchestrates updates across the stack in the correct sequence.

The VCF Upgrade Sequence

VCF upgrades follow a fixed sequence that can't be reordered. The Broadcom depot publishes Bill of Materials (BOM) updates that specify which component versions are validated together. You must upgrade to the versions in the BOM, not to arbitrary combinations.

1. VCF Operations components (fleet level services first)
2. SDDC Manager
3. NSX Manager cluster
4. vCenter Server
5. ESXi hosts (via vLCM, sequential host evacuation and remediation)

VCF Operations updates are now decoupled from this sequence and can be applied independently. This lets Broadcom ship VCF Operations fixes and features without requiring a full stack upgrade cycle.

vLCM and Quickboot

With vLCM image management and Quickboot enabled, ESXi host remediation during updates takes under five minutes per host on compatible hardware. Quickboot bypasses the full BIOS POST cycle and reboots only the software stack. Traditional reboots take 15 to 20 minutes. For a 20-host cluster with 4-minute Quickboot reboots, total patching time drops from roughly six hours to under 90 minutes. Quickboot compatibility is per-host hardware and is listed in the VCG.

9. Day 2 Operations

Adding Hosts to an Existing Workload Domain

1. Prepare the host: install ESXi at the version specified in the cluster's vLCM image, configure the management IP, DNS, and NTP.
2. Commission the host: in vCenter, Global Inventory List, Hosts, Unassigned Hosts, the new host appears after VCF validates it. Select it and commission it to the VCF instance.
3. Add to cluster: in vCenter, navigate to the target cluster, right click, and select New SDDC Cluster or Add Hosts to existing cluster. VCF validates the host against the cluster's vLCM image before adding it.
4. vSAN automatically rebalances storage across the new host. NSX automatically extends the transport zone to the new host.

Expanding a Workload Domain with a New Cluster

A workload domain can contain multiple clusters under the same vCenter instance. Add a cluster in vCenter under Hosts and Clusters: right click the datacenter object and select New SDDC Cluster. The new cluster inherits the workload domain's NSX transport zone and can use its own vSAN configuration or external storage independently of other clusters in the same domain.

Backup Configuration

In VCF 9, component backup configuration is split between two locations. Fleet level backups (VCF Operations appliances, VCF Automation, VCF Identity Broker) are configured at Fleet Management, Lifecycle, Settings, SFTP Settings and Backup Settings. Instance level backups (vCenter, NSX Manager) are configured per instance at Inventory, VCF Instance, Actions, Manage VCF Instance Settings, Backup Settings. Configure both. A VCF Operations failure without a fleet backup leaves you unable to manage the platform even though the VMs and workloads are still running.