vSphere Elastic Provisioning in VCF 9.1 Zero Touch Provisioning and Fleet Onboarding at Scale

This is Part 29 of the series, covering vSphere Elastic Provisioning the Zero Touch Provisioning (ZTP) capability that lets new hosts onboard themselves into the VCF environment without manual configuration.

For most of enterprise virtualisation’s history, bringing a new ESXi host online has been a multi-step manual process. Rack the hardware. Configure the iLO/iDRAC/iLOM. PXE-boot or USB-install ESXi. Manually configure the management network. Manually add to vCenter. Manually configure vSAN claim, NSX transport node attachment, firewall rules, host profile attachment. Validate. Repeat. For one host: an hour or two. For a 16-host cluster: a day. For a new data centre or a fleet expansion: a week or more of skilled engineering time.

VCF 9.1’s vSphere Elastic Provisioning (ZTP) collapses this. New hosts boot, get matched to a target Workload Domain by policy, receive their configured image and identity, and onboard themselves networking, storage, identity, security policy attachment all driven by the platform. The human-out-of-the-loop pattern for host onboarding.

For MSPs running VCF for customers and for internal platform teams running VCF at fleet scale, this changes operational economics meaningfully. This article walks through what ZTP actually does, the deployment patterns it enables, the operational implications, and the design considerations for architects planning ZTP-driven fleets.

What ZTP actually does

vSphere Elastic Provisioning is the orchestration that takes a freshly-racked host from “powered on with no software” to “member of its target Workload Domain, ready for workloads.” Without manual touch.

The workflow:

• Host racks and powers on with no pre-installed OS

• Host PXE-boots from the network, reaching the VCF imaging service

• VCF identifies the host (by hardware identifier serial, MAC, BMC identity)

• Policy-driven host classification: the host matches a target Workload Domain or cluster by its identity, location, hardware profile, or other attributes

• Image deployment: the host receives the cluster image ESXi version, firmware, drivers, components appropriate for its target placement

• Network configuration: management network, vmkernel networks, NSX VTEP networks all configured per policy

• Identity configuration: host certificates, vCenter join, NSX transport node attachment, all automated

• Storage configuration: vSAN claim into the cluster, storage policies attached, vSAN cluster expansion validated

• Security policy attachment: DFW, host profile, compliance baseline all applied

• Validation: health checks pass, host enters the cluster’s active membership, workloads can target it

Time from rack-and-power to ready-for-workload: minutes to a small number of hours, depending on image size and network speed. Human touch: zero, beyond physical racking and cabling.

The architectural pieces that make it work

ZTP isn’t magic; it’s a coordinated set of platform capabilities working together.

Cluster images (replacing baselines). vSphere Lifecycle Manager cluster images define the complete software stack ESX version, firmware versions, driver versions, vSAN components as a managed unit. New hosts onboard against a specific cluster image, ensuring fleet-wide consistency.

Hardware identity registration. Hosts are pre-registered to VCF by their hardware identity (serial number, BMC credentials, MAC addresses). The platform knows what to expect when a host appears on the network. Pre-registration can be batch register a rack’s worth of hosts in one operation.

Placement policy. Hosts match to target placements via policy. Identity-based (this serial goes to this Workload Domain), location-based (hosts in this rack go to this cluster), capability-based (hosts with GPUs go to AI clusters). Policy defined once; applied automatically.

Network configuration policy. Management network range, vmkernel network configuration, NSX VTEP configuration, MTU all defined per Workload Domain. New hosts inherit the cluster’s network configuration without manual setup.

Identity automation. Host certificates generated automatically. vCenter join via service account. NSX transport node attachment automated. The credential and identity work that used to be manual disappears.

Integration with Fleet Update Service. New hosts onboard at the cluster’s current image version. As the cluster image evolves (via Fleet Update Service), new hosts onboard at the new version automatically.

Integration with VCF Operations. Onboarding progress, validation results, and any onboarding failures all surface through VCF Operations. The MSP or platform team sees the operation in their normal observability surface, not in a separate provisioning tool.

Operational impact MSPs and platform teams

The operational shift ZTP enables is significant. Consider the new-host operations work it eliminates or compresses.

New customer onboarding (for MSPs). A new customer’s dedicated cluster used to be a one-week deployment project. With ZTP, racking, cabling, and powering on a pre-registered rack of hosts is the manual step. The cluster materialises within hours.

Capacity expansion. Adding capacity to an existing cluster used to be a planned maintenance activity. With ZTP, new hosts are racked, they join the cluster automatically, and workloads can move onto them. The change-management overhead drops significantly.

Host replacement. Failed host replacement used to require manual decommission of the old host, manual provisioning of the new host, manual reattachment to cluster. With ZTP, the replacement host onboards as the old host’s replacement automatically.

New data centre or remote site deployments. Greenfield deployments where the platform team isn’t physically present (remote branches, edge locations) become tractable. Smart hands physically rack and cable. The platform team configures policy. The site comes up.

Standardisation enforcement. Hosts onboard with cluster image conformance enforced from the first moment. Drift detection (Part 21) applies from Day 1. The fleet stays standardised by construction rather than by manual remediation.

For MSPs, this enables customer onboarding velocity that previously required substantial engineering teams. For internal platform teams, this lets the team focus on what genuinely requires skilled engineering capacity planning, capability adoption, optimisation rather than commodity host provisioning.

Deployment patterns

Common patterns for ZTP-driven fleets:

MSP customer onboarding pattern. Pre-register a rack’s worth of hosts by hardware identity to a customer’s target Workload Domain. Smart hands rack and cable per a documented plan. Power on. The customer’s cluster materialises. The MSP team validates and hands over.

Capacity-on-demand pattern. Maintain a pool of pre-registered standby hosts in known rack positions. When capacity needs grow, smart hands cable and power on a standby. The host joins the appropriate cluster automatically.

Geographic expansion pattern. A regional expansion deploys hosts to a new data centre via local smart hands. Pre-registration handles identity. Network connectivity to the management plane handles the rest. The platform team operates remotely from headquarters.

Edge / branch pattern. Small branch deployments a single rack of two to eight hosts deployed via ZTP with branch staff doing only physical work. The platform team never visits.

Tier-based cluster pattern. Different clusters serve different workload tiers (production, dev, AI, DR). Hosts pre-registered to specific tiers receive tier-appropriate cluster images automatically. A host doesn’t end up in the wrong cluster because the policy doesn’t allow it.

Lifecycle refresh pattern. Hardware refresh cycles retire old hosts, deploy new become rolling operations rather than projects. Old hosts decommission as their workloads migrate; new hosts onboard automatically; the cluster maintains continuous capacity.

Design considerations

For architects planning ZTP-driven deployments:

• Pre-registration workflow how does hardware identity get into VCF before the host arrives? Vendor integration, procurement workflow, smart-hands processes need design

• Network availability PXE boot needs the management network reachable from the host’s first boot. Network configuration is upstream of ZTP it must be in place first

• Hardware HCL alignment hosts must be on the VCF 9.1 HCL for the target cluster’s image. Procurement standardisation matters

• Cluster image governance who owns the cluster image, who approves changes, how often is it refreshed. ZTP makes the cluster image the operational source of truth

• Placement policy clarity the policies that match hosts to Workload Domains must be unambiguous. Misplacement is a recoverable error but adds friction

• Smart-hands procedures the physical work (racking, cabling, power-on, recording serial numbers) needs documented procedures and competent execution. The platform automates the platform work, not the physical work

• Air-gapped environments ZTP needs network connectivity. For air-gapped or highly isolated networks, the imaging service must be reachable, with HTTP Offline Depot patterns for image distribution

• Edge environments low-bandwidth links to remote sites affect image transfer. Plan image caching strategies for remote deployments

• Identity hygiene pre-registered hosts that never deploy create stale entries. Lifecycle the registrations alongside the procurement

• Failure modes what happens when ZTP onboarding fails partway? Designed retry, partial-state cleanup, and operator alerting matter

Common failure modes

Things that go wrong in ZTP deployments, from real engagements:

• Network not in place PXE boot fails because management network isn’t reachable. The host racks and powers on, nothing happens. Usually a misconfigured switch or VLAN

• DNS misconfiguration ZTP relies on DNS resolution for the imaging service and target vCenter. Misconfigured DNS surfaces here first

• Pre-registration mismatch the host’s actual hardware identity doesn’t match the pre-registration. Either smart hands made an error, or the procurement record was wrong

• HCL mismatch the host hardware isn’t on the HCL for the target cluster’s image. Procurement standardisation slipped

• Image not current the cluster image references components that no longer exist or have been superseded. Image lifecycle governance gap

• Network configuration drift the policy-defined network configuration doesn’t match what the upstream switch actually provides. MTU mismatches are common

• Time skew the host’s BMC clock is significantly off, certificate validation fails. NTP first

Closing

vSphere Elastic Provisioning is the operational capability that turns new-host deployment from a project into a workflow. For MSPs, this is the capability that lets customer onboarding happen at the velocity customers now expect from cloud providers. For internal platform teams, this is the capability that lets the team scale infrastructure operations without scaling the team.

The capability isn’t complicated, but the supporting workflows pre-registration, smart-hands procedures, network readiness, image governance need design. Done well, ZTP is invisible operationally; new hosts just appear. Done poorly, ZTP becomes another partial-automation pattern that confuses ops teams.

In my design conversations, the ZTP questions I work through:

• What’s the procurement-to-deployment workflow, including pre-registration?

• What smart-hands procedures exist, and are they reliable?

• What’s the cluster image governance ownership, approval workflow, refresh cadence?

• What network prerequisites are in place at deployment sites?

• How do hardware procurement standards align with the VCF 9.1 HCL?

• What’s the failure-mode design retry, cleanup, alerting?

• Are air-gapped or low-bandwidth environments in scope, and how is image distribution handled?

• How does ZTP integrate with the customer’s existing change-management governance?

Get those answered and Zero Touch Provisioning delivers the operational compression it promises.

Part 30 of the series the final article in this Broadcom-slide-driven block covers the Open Ecosystem story in VCF 9.1: Unified EVPN with Arista / Cisco / SONiC, Crowdstrike EDR integration for Rapid Workload Recovery, Enhanced DirectPath I/O for AMD GPUs, VKS reference architectures with cloud-native leaders and why platform openness matters at enterprise scale.

Sources

• Broadcom Modernizing Infrastructure Economics with VMware vSphere Foundation 9.1

• Broadcom Announcing VCF 9.1: Modern Private Cloud Built for Efficiency and Resilience

• Broadcom VCF 9.1: The Secure, Cost-Effective Private Cloud Platform for Production AI

• Broadcom Scale, Simplify, and Secure Your Private Cloud Operations with VCF 9.1

• Broadcom VCF 9.1 is Available: Explore the New Features in Hands-on Labs

• Broadcom Press Release Broadcom Announces VMware Cloud Foundation 9.1