Lab: vSAN Witness Configuration (2-Node)

VCF 9.0Intermediatevcp-foundation⏱ 75 min

Objectives

Lab: vSAN Witness Configuration (2-Node)

Prerequisites

VCF lab environment deployed and operational

Lab Environment

Standard VCF lab environment for vSphere Foundation 9.0 Administrator

Tasks

Task 1 Lab: vSAN Witness Configuration (2-Node)

2-node vSAN with witness is designed for edge/ROBO sites where cost constrains host count. Understanding witness placement, quorum behavior, and failure scenarios is critical for edge architecture.

Step 1

Build 2x ESXi hosts (Site-A/Site-B) + 1x witness VM (Site-C or dedicated NFS)

Step 2

vCenter UI → Cluster settings → vSAN witness node configuration → Add witness VM

Step 3

Witness deployed as VM with 1 vCPU, 16GB disk (thin-provisioned), 128MB RAM

Step 4

Test quorum loss: Power down one ESXi host → Remaining host + witness maintain quorum

Step 5

Verify: vSAN health dashboard → Witness health = green

Validation Gate

Check: After configuring 2-node vSAN with witness: verify witness connectivity to both hosts, confirm preferred fault domain assignment, and simulate a host failure to validate HA behavior

Expected: Witness shows connected to both data hosts. Preferred host is set. During simulated failure of non-preferred host: VMs restart on preferred host, vSAN objects degrade to single copy but remain accessible.

Common Errors

Placing the witness host on the same failure domain as one of the data hosts

Fix: The witness must be in a separate failure domain (different rack, site, or at minimum a different ESXi host). If the witness is on the same rack as Host-1 and that rack loses power, vSAN loses quorum (1 surviving host out of 3 vote components) and goes offline.

Sizing the witness host too small

Fix: The witness stores metadata only (not data), but it still needs: 2 vCPU, 8GB RAM minimum, and network connectivity to both data hosts. For larger deployments (100+ objects), witness disk usage can grow. Use the vSAN witness sizing tool to validate.

Not configuring preferred fault domain

Fix: In 2-node vSAN, one host is designated as 'preferred' fault domain. During a network partition (hosts can't see each other but both see witness), the preferred host keeps serving I/O. Without this setting, behavior during partition is unpredictable. Configure via SDDC Manager or vCenter → vSAN → Fault Domains.

Forgetting that 2-node vSAN only supports RAID-1 (FTT=1)

Fix: 2-node vSAN with witness can only mirror data between the 2 hosts (RAID-1, FTT=1). RAID-5 requires 4+ hosts. If one host fails, all data is served from the surviving host with no redundancy until the failed host returns. This is a key risk to communicate to the customer.

Final Validation

Lab completed successfully

✓ All steps completed → No errors observed

Cleanup / Restore

• Revert to snapshot if needed

Design Reflection (VCDX)

2-node vSAN is relevant for edge/ROBO architectures in VCDX defense. Panelists test whether you understand the limitations (RAID-1 only, single host failure tolerance) and when to recommend 2-node vs 4-node clusters.

Requirements

Deploy 2-node vSAN with witness for edge/ROBO site
Configure preferred fault domain for predictable partition behavior
Understand single-host-failure tolerance limitations

Constraints

2-node vSAN only supports RAID-1 (FTT=1)
Witness must be in separate failure domain
Network partition behavior depends on preferred fault domain config

Assumptions

WAN connectivity to witness site is reliable
Edge workloads can tolerate single-copy risk during host failure

Risks

Both hosts failing simultaneously — total data loss
Witness network failure causing quorum loss and vSAN offline

⚠ Known Pitfalls (from Community KB)

Deploying 2-node vSAN without communicating the single-host-failure risk to the customer — during a host failure, data has zero redundancy.

Assuming 2-node vSAN can run RAID-5 — it cannot. If the customer needs erasure coding, minimum 4 hosts are required.

Mark complete