8.2 End-to-End VVF Deployment Workflow

8.2 End-to-End VVF Deployment Workflow

Executing a production-grade deployment of VMware vSphere Foundation (VVF) 9.0 requires a systematic, phased methodology. Each phase transforms raw x86 computing hardware into a resilient, observable private cloud platform capable of hosting enterprise virtual machines and containerized applications.

---

Phase 1: Host Preparation, Cluster Formation, and Compute Resilience

DCUI Staging & Host Configuration

Every ESXi 9.0 host must be prepared prior to vCenter registration. An administrator accesses the physical host via the Baseboard Management Controller (BMC)—such as Dell iDRAC or HPE iLO—to interact with the Direct Console User Interface (DCUI):

1. Network Configuration: Configure a static IPv4 address, subnet mask, and default gateway on the primary physical management adapter (vmnic0). Avoid dynamic DHCP addresses for production ESXi management.
2. DNS & Hostname: Enter the assigned host FQDN (e.g., esxi-01.corp.local) and configure primary and secondary DNS servers.
3. NTP Servers: Navigate to Host Configuration or Host Client to specify enterprise NTP servers and set the NTP daemon service to start automatically with the host.
4. Management Network Test: Execute the built-in DCUI management network test to verify gateway reachability and DNS resolution; verify NTP separately before proceeding.

Creating the Cluster & Enabling HA and DRS

With hosts configured, the administrator logs into the newly deployed vCenter Server Appliance vSphere Client:

1. Datacenter Creation: Right-click the vCenter inventory root and select New Datacenter.
2. Cluster Creation: Right-click the Datacenter and select New Cluster.
3. Enabling vSphere DRS: In the cluster creation wizard, enable vSphere DRS (Distributed Resource Scheduler). Set the Automation Level to Fully Automated with a Migration Threshold of Level 3 (Neutral). Fully Automated DRS is a mandatory prerequisite for enabling the vSphere Supervisor.
4. Enabling vSphere HA: Enable vSphere High Availability (HA). Under HA settings:
   • Host Monitoring: Enable host monitoring to track physical heartbeat signals.
   • Admission Control: Enable admission control and select the Percentage of Cluster Resources Reserved policy (e.g., reserving 25% CPU and Memory in a 4-host cluster as a simplified N+1 capacity example for equal-sized hosts; verify actual host sizes and workload requirements).
   • Datastore Heartbeating: Where supported non-vSAN heartbeat datastores are available, select appropriate shared datastores (normally two) to help distinguish host failure from network isolation. A vSAN-only deployment does not manufacture a second heartbeat datastore; follow its documented HA networking requirements.
5. Host Addition: Add the prepared ESXi hosts to the cluster by specifying their FQDNs and root credentials, verifying host SSL thumbprints during registration.

---

Phase 2: Initial Storage Configuration (vSAN Cluster Initialization)

vSAN provides the shared software-defined storage layer underpinning VVF 9.0. During cluster setup or via Cluster -> Configure -> vSAN -> Services, administrators configure the storage layer:

Choosing Storage Architecture: ESA vs. OSA

• vSAN Express Storage Architecture (ESA): The modern, high-performance architecture introduced for servers equipped with certified NVMe storage devices. ESA eliminates the concept of two-tier disk groups. All qualifying NVMe drives on each host are claimed into a single, unified Storage Pool. Drives participate concurrently in both write-caching and persistent capacity storage, unlocking native snapshot performance, reduced write amplification, and RAID-5/6 erasure coding at RAID-1 mirroring speeds.
• vSAN Original Storage Architecture (OSA): The traditional two-tier architecture requiring drives to be partitioned into Disk Groups. Each disk group mandates exactly one dedicated SSD for write caching/read buffering and between 1 and 7 SSDs or HDDs for persistent capacity.

Claiming Storage Drives

In the vSAN configuration wizard:

1. For vSAN ESA, the wizard displays all detected NVMe drives. Verify drive compatibility against the vSAN ESA ReadyNode hardware specification and claim the drives for the host Storage Pools.
2. Once drives are claimed across cluster hosts, vSAN automatically instantiates the distributed vsanDatastore.
3. Verify that the effective default storage policy, which can differ between OSA and ESA with Auto-Policy Management is applied across the cluster.

---

Phase 3: vSphere Distributed Switch (vDS) Deployment & Management Migration

By default, ESXi hosts utilize a standard virtual switch (vSwitch0) created during installation. Standard switches require manual, per-host port group management and cannot support the vSphere Supervisor. Administrators must deploy a vSphere Distributed Switch (vDS) and execute a non-disruptive migration.

Migration Workflow (vSS to vDS):
1. Deploy vDS at Datacenter Level
2. Create Distributed Port Groups (Management, vMotion, vSAN, VM Data)
3. Staged Uplink Migration: Assign vmnic0 to vDS Uplink 1 (vmnic1 stays on vSS)
4. Migrate VMkernel Adapters: Move vmk0 (Management), vmk1, vmk2 to vDS
5. Migrate VM Network Adapters to Distributed Port Groups
6. Move vmnic1 to vDS Uplink 2 and Decommission Legacy vSS

Step-by-Step Non-Disruptive Network Migration

1. Create Distributed Switch: In the vSphere Client Networking inventory, right-click the Datacenter and select Distributed Switch -> New Distributed Switch. Specify the latest version (vSphere 9.0) and configure two physical uplinks (Uplink 1, Uplink 2).
2. Create Distributed Port Groups: Construct dedicated distributed port groups for each network service with appropriate VLAN IDs:
   • dpg-management (VLAN 10)
   • dpg-vmotion (VLAN 20)
   • dpg-vsan (VLAN 30)
   • dpg-workload (VLAN 40)
3. Add and Manage Hosts Wizard: Right-click the newly created vDS and select Add and Manage Hosts. Select Manage Host Networking and add all cluster hosts.
4. Staged Physical Adapter Migration: Assign vmnic0 on each host to Uplink 1 on the vDS. Leave vmnic1 assigned to vSwitch0. This preserves a potential recovery path while the original management interface and its reachable uplink remain on the standard switch. Verify physical connectivity and each migration step; retaining a NIC alone does not guarantee reachability.
5. Migrate VMkernel Adapters: Map the existing VMkernel interfaces to their new distributed port groups (vmk0 to dpg-management, vmk1 to dpg-vmotion, and vmk2 to dpg-vsan). vCenter initiates connection tests; if communication is severed, vCenter's automatic rollback mechanism reverts the VMkernel adapter to the standard switch.
6. Migrate VM Network Interfaces: Point any running virtual machines to the appropriate distributed port groups.
7. Finalize Uplink Redundancy: Reassign the remaining physical adapter (vmnic1) to Uplink 2 on the vDS. With all networking migrated, safely remove the legacy standard switch (vSwitch0).

---

Phase 4: Deploying VCF Operations & VCF Operations for Logs

With compute, storage, and networking operational, administrators deploy the management and observability virtual appliances.

VCF Operations and Logs Deployment

Obtain the correct 9.0 media and deployment method, then use Broadcom's 9.0 sizing guidance for objects, metrics, retention and HA/CA overhead. Do not use a legacy table that equates VM count directly to small appliance memory values.

Initialize the Operations primary and any additional nodes using the supported installation workflow. Configure the vCenter integration, select an appropriate collector, validate credentials and certificate trust, and confirm inventory discovery and recent metric timestamps. Register Operations and apply subscription license capacity to the vCenter instance through the Business Services workflow.

Deploy and integrate Operations for Logs under the supported 9.0 procedure, using the correct standalone or clustered size. Clustered logging requires at least three nodes; the 9.0 documented maximum is 18 total, including the primary. Configure ingestion and verify actual events. Secure syslog commonly uses TCP 6514, while CFAPI HTTPS uses 9543; check the selected endpoint and port matrix rather than confusing them with port 1514.

The full VVF lifecycle includes vCenter, Operations, Logs, Supervisor/VKS, ESX, compatible hardware/firmware and guest components. A vLCM host image manages the host software layer; it does not update every appliance. Check interoperability and product upgrade instructions before planning changes. The version-9 log-management transition requires a fresh installation and supported migration, not an assumed in-place rename of an 8.x appliance.

Phase 5: Comprehensive Post-Deployment Health Validation

Before certifying the VVF 9.0 environment for production workloads, administrators must execute four essential verification gates:

1. vCenter Alarm Audit: Inspect the vCenter Monitor tab for active alarms. Clear transient configuration alarms and verify that all ESXi hardware sensors report "Normal" status.
2. vSAN Skyline Health Verification: Navigate to Cluster -> Monitor -> vSAN -> Skyline Health. Execute a full health check and ensure green health across all categories: Physical Disk Health, Network Latency (< 1 ms between nodes), Hardware Compatibility (HCL compliance for drives and NVMe controllers), and vSAN Cluster Quorum.
3. NTP Drift Validation: Verify time synchronization across all cluster nodes. SSH into each ESXi host and execute esxcli system time get and the supported NTP status query for the host release to confirm synchronization relative to vCenter and the VCF appliances.
4. Telemetry Ingestion Audit: Open VCF Operations to verify metric collection across all ESXi hosts and datastores. Open VCF Operations for Logs and navigate to Interactive Analytics to confirm that live syslog streams from all ESXi hosts and vCenter are being actively ingested and indexed.

Review Takeaways

• Build each component only after its own dependencies are validated.
• vSAN OSA disk groups and ESA storage pools have different claim workflows.
• Use current 9.0 sizing and registered Operations for subscription licensing.
• Verify host/storage/network health and real metric/log arrival before declaring the environment usable.