5.2 VCF Installer Bring-Up & Management Domain Deployment

5.2 VCF Installer Bring-Up & Management Domain Deployment

Executive Overview: Bringing up a VMware Cloud Foundation Management Domain turns a rack of prepared hardware into an operational private cloud control plane. In VCF 9.0 the tool that performs this is the VCF Installer — a dedicated virtual appliance that plans, configures, and deploys every required VCF and VMware vSphere Foundation (VVF) component. The VCF Installer replaces the Cloud Builder appliance, which Broadcom removed in VCF 9.0. For the VCP-VCF (2V0-17.25) exam, which is explicitly scoped to VCF 9.0, candidates must reason about the installer's dual-mode behaviour, its three supported deployment workflows, its JSON-driven input model, and the ordered pipeline it drives.

---

What Replaced What: The VCF 9.0 Deployment Changes

A large share of community study material still describes the VCF 5.x bring-up path. That path is no longer valid, and the exam is built on 9.0 content. Commit the following removals and replacements to memory.

[!WARNING] The single most common stale-material trap: if an answer option describes deploying a Cloud Builder OVA and completing a Deployment Parameter Workbook, it is describing VCF 5.x. On a 9.0-scoped exam that option is wrong regardless of how familiar it looks.

---

The VCF Installer Appliance

The VCF Installer is a dedicated virtual machine that helps you plan, configure, and deploy all the required VMware Cloud Foundation and VMware vSphere Foundation components.

One OVA, Two Modes

The installer is not shipped as a separate download. It arrives bundled with SDDC Manager in the same OVA file, named VCF-SDDC-Manager-Appliance-9.x.x.ova. The appliance decides its own role based on where you deploy it:

• Installer mode — the appliance is deployed outside the infrastructure it is about to build (for example, onto an existing standalone ESX host, a jump cluster, or a separate management environment). In this mode it exposes the installer UI and API and can drive deployments.
• SDDC Manager mode — if the appliance is deployed inside the management infrastructure, meaning onto one of the hosts that will form the management domain, it switches into SDDC Manager mode and can no longer be used in installer mode.

This is a one-way transition and a favourite scenario question. An engineer who parks the installer on a host that is later commissioned into the management domain has converted their installer into an SDDC Manager and must deploy a fresh appliance to run another installation.

Binary and Depot Management

Before it can deploy anything, the installer needs the software bill of materials. The VCF Installer can manage and download the binaries needed for VCF or vSphere Foundation deployments, pulling them from the Broadcom depot in connected environments or accepting an offline bundle where the site is disconnected. The VMware Update Manager Download Service (UMDS) that some 5.x sites used for offline content is now folded into the VMware Cloud Foundation Download Tool.

---

The Three Supported Workflows

Unlike Cloud Builder, which existed solely for greenfield management-domain bring-up, the VCF Installer covers three distinct entry points into VCF 9.0.

1. Deploy a New Platform

A greenfield build onto pre-installed ESX hosts. The installer configures every component automatically from the supplied specification. Note the product naming: in VCF 9.0 the hypervisor is branded ESX, and the official exam objective wording is "deploy and configure VCF compute components (vCenter and ESX)".

2. Converge Existing Infrastructure

The installer can convert existing vSphere infrastructure into a VCF or vSphere Foundation platform. This is the supported path for an organisation that already runs vCenter and clusters and wants to adopt the VCF operating model without rebuilding. It pairs with the separate "import an existing vCenter" workflow covered later in Chapter 6.

3. Upgrade from VCF 5.x

The installer drives the upgrade of an existing VCF 5.x environment to VCF 9.0, including deployment of the VCF management services that 9.x expects.

Reusing Versus Deploying Management Components

In every workflow the installer can either deploy new VCF Operations components — primary, replica, and data nodes — and a new VCF Automation instance, or leverage existing VCF Operations and Automation instances already present in the fleet. Choosing to reuse is what allows a second VCF instance to join an existing fleet rather than becoming an isolated island with its own operations stack.

[!NOTE] Version nuance worth knowing: beginning with VCF 9.1, the installer additionally deploys a default set of VCF management services during a new deployment — the VCF services runtime, fleet lifecycle, identity broker, software depot, Salt RaaS, telemetry, and the license server. The 2V0-17.25 exam is scoped to 9.0, but recognising these component names prevents confusion when reading current documentation.

---

Supplying the Configuration: UI or JSON

Because the Excel workbook is gone, there are exactly two supported ways to describe the target environment.

1. The VCF Installer UI — a guided, validated web workflow where the administrator enters the specification screen by screen.
2. A JSON specification — the same data expressed declaratively and submitted to the installer API. This is the automation-friendly path, and it is what makes repeatable, source-controlled deployments possible.

Whichever entry method is used, the specification still has to describe the same underlying facts:

• Credentials for appliance administrative accounts and service accounts, subject to strict complexity rules.
• Infrastructure details — datacenter and cluster names, DNS servers, NTP servers, search domains, and proxy settings.
• Networking — VLAN IDs, subnets, gateways, and MTU values for the management, vSAN, vMotion, and host-overlay networks.
• Host inventory — FQDNs, management IPs, credentials, physical uplink assignments, and disk-claiming rules.
• NSX configuration — manager FQDNs and IPs, the cluster virtual IP, transport zones, and TEP address pools.
• vSAN architecture selection — Express Storage Architecture (ESA) with a single NVMe storage pool per host, or Original Storage Architecture (OSA) with discrete cache and capacity disk groups.

---

Validation Gating and the Bring-Up Pipeline

The installer enforces a two-phase gate: validation first, deployment second. Nothing is provisioned until the environment passes.

Validation

Validation is non-destructive and covers the classic failure sources:

• DNS — forward (A) and reverse (PTR) records must resolve consistently for every declared FQDN in both directions.
• NTP — every host and appliance must reach the declared time sources with acceptable clock skew. Time skew is the single most common cause of certificate and SSO failures later.
• Network reachability and MTU — gateway reachability plus jumbo-frame transit tests, because Geneve encapsulation adds at least 50 bytes and requires an underlay MTU of at least 1700 bytes end to end.
• Host readiness — CPU, memory, NIC speed, and confirmation that drives earmarked for vSAN carry no residual partitions or datastores.
• Credential authentication against every declared endpoint.

A failed critical check blocks the deployment trigger and returns a report naming the specific host, record, or interface to remediate.

Deployment Sequence

Once validation passes, the pipeline runs in a strict dependency order. The order itself is examinable, and the logic behind it is worth internalising rather than memorising:

1. Host preparation — DNS, NTP, and syslog configuration; creation of the vSphere Distributed Switch; migration of the management VMkernel adapter onto the VDS with redundant uplinks.
2. Management vCenter — the appliance is deployed, the SSO domain is established, and the datacenter and management cluster objects are created. vCenter must exist before a cluster can exist.
3. vSAN — disks are claimed and the datastore is formed, as an ESA storage pool or OSA disk groups. Storage must exist before further appliances have somewhere to live.
4. NSX Manager cluster — three manager appliances are deployed, the cluster virtual IP is bound, transport zones and uplink profiles are configured, and hosts are prepared as transport nodes with Geneve TEPs.
5. SDDC Manager — the per-instance component is deployed and registered with vCenter and SSO.
6. VCF Operations — primary, replica, and data nodes are deployed, or the instance is registered against existing fleet components.

---

After Bring-Up: Where Management Actually Lives

This is the part that most differs from 5.x, and it matters for every later chapter.

SDDC Manager still exists in VCF 9.0 as a per-instance component, but its UI is deprecated and the operational authority has moved. In a 9.0 fleet, VCF Operations is the management surface for fleet-wide lifecycle, identity configuration, licensing, and monitoring. Administrators who reflexively reach for the SDDC Manager UI are using a deprecated interface that Broadcom has stated will be removed in a future major release.

---

Exam Watch: Key Scenarios and Candidate Traps

[!IMPORTANT] The mode-flip scenario. A question describes an engineer deploying the appliance onto a host that will later join the management domain, then asking why the installer UI is unavailable for the next workload domain build. The answer is that the appliance switched into SDDC Manager mode and can no longer be used in installer mode. A new installer appliance must be deployed outside the managed infrastructure.

[!WARNING] Do not answer "Deployment Parameter Workbook." Any option offering an Excel worksheet as the 9.0 input mechanism is describing a removed artifact. The supported inputs are the installer UI and a JSON specification.

[!TIP] Reason about ordering, do not memorise it. vCenter precedes the cluster because the cluster is a vCenter object; vSAN precedes NSX because NSX Manager appliances need a datastore; SDDC Manager and VCF Operations come last because they take custody of an environment that must already exist.