Lab: Scale VVF Cluster — Add and Remove ESXi Host with vSAN Data Migration

VCF 9.0Intermediatevcp-foundation⏱ 75 min

Covers Obj 5.3 (VVF Clusters — scaling). Demonstrates host add/remove with vSAN data migration awareness.

Objectives

Add an ESXi host to an existing VVF cluster
Verify vSAN disk group auto-claim on new host
Remove an ESXi host with proper vSAN data evacuation
Understand cluster scaling impact on vSAN fault domains and storage policies
Import existing vSphere environment as VVF cluster (conceptual)

Prerequisites

VVF lab with vCenter and vSAN cluster operational. At least one unconfigured ESXi host available for addition.

Prior labs: vvf-support-01

Required skills:

vCenter cluster management
vSAN basics
Networking concepts

Lab Environment

Holodeck VVF pod with 3-node vSAN cluster + 1 standalone ESXi host (esxi-04) for scale-out exercise.

Credentials

System	Username	Password
vCenter	`administrator@vsphere.local`	Holodeck default
ESXi Host 4	`root`	Holodeck default

Tasks

Task 1 Add ESXi Host to VVF Cluster

availability

Host addition is a common scale-out operation. Understanding networking, vSAN, and DRS implications is essential for support troubleshooting.

Step 1

Pre-check: Verify standalone host (esxi-04) has: same ESXi version as cluster, vSAN-compatible disks, VMkernel adapters configured for vSAN and vMotion traffic.

Host version matches cluster. vSAN VMkernel (vmk1) and vMotion VMkernel (vmk2) configured.

Step 2

vCenter UI → Navigate to target cluster → Right-click → Add Hosts. Enter esxi-04 FQDN/IP and root credentials.

Host discovery succeeds. Summary shows host hardware and current configuration.

Step 3

Review host summary: CPU sockets, memory, disk groups. Accept and add host to cluster.

Host added to cluster. DRS admission control recalculates.

Step 4

Verify vSAN: Cluster → Monitor → vSAN → Disk Management. Check that esxi-04 disk groups are claimed (auto-claim if configured, or manual claim).

New host shows disk group(s) with cache + capacity tiers. vSAN cluster shows 4 hosts.

Step 5

Verify networking: Check that new host has correct vDS uplink assignments. Monitor → vSAN → Health → Network → vSAN: vMotion redundancy check.

vDS port groups assigned. vSAN network health check passes.

Step 6

Check vSAN rebalance: Monitor → vSAN → Resyncing Components. vSAN may automatically rebalance objects to include the new host.

Proactive rebalance distributes data across all hosts for optimal fault tolerance. In production, schedule rebalance during off-peak hours.

Validation Gate

Check: 4th host added to cluster, vSAN healthy, DRS operational

Expected: Cluster shows 4 hosts. vSAN health all green. DRS rebalances VMs.

Common Errors

Host add fails — 'Cannot contact the specified host'

Cause: DNS resolution failure or firewall blocking port 443

Fix: Verify DNS forward/reverse lookup for esxi-04. Check firewall rules for port 443, 902, 2377.

vSAN disk group not claimed on new host

Cause: Disks have existing partitions or aren't vSAN-compatible

Fix: SSH to host → esxcli vsan storage list. Check for existing partitions. Wipe disks if needed: esxcli vsan storage remove -d <device>.

Task 2 Remove ESXi Host from VVF Cluster with vSAN Data Evacuation

recoverability

Host removal requires careful vSAN data evacuation. Incorrect removal causes data loss. This is a critical support scenario.

Step 1

Pre-check: Verify cluster can sustain host removal — check vSAN capacity after removal. Cluster → Monitor → vSAN → Capacity. Ensure remaining hosts have sufficient capacity.

Capacity analysis shows cluster can sustain removal with >20% free space remaining.

Step 2

Place target host in maintenance mode: Right-click esxi-04 → Maintenance Mode → Enter. Select vSAN data migration: 'Full data migration' (moves ALL vSAN objects off this host).

CRITICAL: Always use 'Full data migration' when permanently removing a host. 'Ensure accessibility' only maintains minimum copies and risks data loss if another host fails.

Step 3

Monitor vSAN data migration: Cluster → Monitor → vSAN → Resyncing Components. Wait for all components to reach 'Completed' state.

Data migration progress shows objects evacuating. May take 30-60 minutes depending on data volume.

Step 4

After migration completes, verify: esxi-04 shows 0 vSAN components. Cluster → Monitor → vSAN → Health → all green.

Host has no vSAN objects. Cluster health is green with 3 remaining hosts.

Step 5

Remove host: Right-click esxi-04 (in maintenance mode) → Remove from Inventory. Confirm removal.

Host removed from cluster inventory. Cluster shows 3 hosts.

Step 6

Post-removal verification: Check storage policies still satisfied. Cluster → Configure → vSAN → Storage Policies → verify FTT=1 can still be met with 3 hosts.

All storage policies compliant. No policy violations.

Validation Gate

Check: Host removed cleanly, vSAN healthy with 3 hosts, no policy violations

Expected: Cluster back to 3 hosts. vSAN health green. All VM storage policies compliant.

Common Errors

Maintenance mode hangs — 'Data migration in progress' for hours

Cause: Large amount of data to evacuate or insufficient capacity on remaining hosts

Fix: Check vSAN Resyncing Components for stuck objects. Verify remaining hosts have enough capacity. May need to reduce FTT or delete unnecessary VMs first.

Storage policy violation after host removal

Cause: FTT=2 requires 5 hosts minimum; removing a host drops below threshold

Fix: Reduce storage policy FTT to 1 before removing host, or add another host first to maintain N+1.

Task 3 Import Existing vSphere Environment as VVF Cluster (Conceptual)

manageability

Obj 5.3 includes importing existing vSphere environments. This task covers the process conceptually since Holodeck has limited standalone vSphere environments.

Step 1

Review VVF import requirements: Target vSphere environment must be at compatible ESXi version (8.x or 9.0), have vCenter managing it, and have VVF-compatible licensing.

Step 2

Document the import process: (1) Register existing vCenter with VVF management plane, (2) Validate ESXi host compatibility, (3) Apply VVF license to imported assets, (4) Enable vSAN on cluster if not already configured.

Import is non-destructive — existing VMs continue running. The process adds VVF management capabilities on top of existing infrastructure.

Step 3

List pre-import checklist items: DNS/NTP configured, ESXi version compatible, vDS preferred over VSS, vSAN disk groups identifiable, network MTU consistent (9000 for vSAN).

Step 4

Document post-import tasks: Assign VVF licenses, configure vSAN storage policies, enable DRS/HA if not configured, integrate with VCF Operations for monitoring.

Step 5

Note limitations: VSS-based clusters should be migrated to vDS before import. Mixed-version clusters (ESXi 7.x + 8.x) must be homogenized first.

Validation Gate

Check: Import process documented with pre-checks and post-tasks

Expected: Written checklist covering requirements, process, and post-import configuration.

Common Errors

Import fails — incompatible ESXi version

Cause: Target hosts running ESXi 7.x which isn't supported for direct VVF 9.0 import

Fix: Upgrade all hosts to ESXi 8.x minimum before attempting import.

Final Validation

Cluster scaling (add/remove host) completed with vSAN data integrity maintained; import process documented

✓ Host successfully added and integrated with vSAN → 4-node cluster operational with vSAN healthy

✓ Host removed with full data evacuation → 3-node cluster, all storage policies compliant

✓ Import process documented → Checklist covers pre-reqs, process, post-tasks

Cleanup / Restore

• Re-add esxi-04 if removed for subsequent labs

• Revert to 3-node snapshot if needed

Design Reflection (VCDX)

Cluster scaling decisions directly impact availability and performance. Architects must plan for N+1+1 capacity (maintenance + failure) and vSAN fault domain awareness during scaling operations.

Requirements

Scale cluster without VM downtime
Maintain vSAN data availability during all operations

Constraints

Holodeck nested environment limits to 4 hosts maximum
vSAN requires minimum 3 hosts for FTT=1

Assumptions

New host has compatible hardware and ESXi version
Sufficient network bandwidth for vSAN data migration

Risks

Simultaneous host failure during data evacuation causes data loss
vSAN rebalance during business hours impacts VM performance

Self-Assessment Discussion Prompts

When is 'Ensure accessibility' appropriate vs 'Full data migration' for maintenance mode?
How does adding a 4th host change vSAN fault domain calculations for FTT=1?
What happens if you remove a host without entering maintenance mode first?

Extensions

Scale cluster to 4 hosts, then back to 3 — measure vSAN rebalance time

Test host removal with 'No data migration' option — observe policy violations

Create a stretched cluster scenario (conceptual) with 2 fault domains + witness

⚠ Known Pitfalls (from Community KB)

Never remove a vSAN host without full data migration — 'No data migration' causes immediate policy violations and potential data loss

Host addition requires matching ESXi version — mixed versions cause vSAN health warnings

vDS uplink assignment is manual for newly added hosts — verify port group connectivity before enabling vSAN traffic

References

vSphere Cluster ManagementTier 1 — Official
vSAN Host MaintenanceTier 1 — Official
VVF Cluster Import GuideTier 1 — Official

Mark complete