Adding a Mismatched Node to a Healthy Four-Node Cluster
A 4-node VxRail 7.0.240 cluster with E560F nodes is running production. Each node has two disk groups and 3.84 TB capacity disks. The customer buys a fifth E560F node from a different batch; it has one disk group and 1.92 TB capacity disks. They want to add it during a maintenance window. The VxRail Manager shows the cluster is healthy; vSAN is OSA. The new node has the same VxRail version but a newer BIOS and iDRAC firmware. The network team will connect it to the same VLANs. The customer asks whether they can add the node as-is and what checks must pass before clicking Expand.
1. What compatibility checks must pass before expanding the cluster?
Read the worked answer
Check model and software compatibility first: the node must be a supported VxRail expansion for the existing E560F cluster and must match the VxRail software version or be brought to the cluster baseline. A newer BIOS and iDRAC firmware are not automatically acceptable; compare against the cluster's validated firmware baseline and update or downgrade as VxRail requires before expansion. Confirm the network adapters, VLANs, MTU, and iDRAC connectivity match the existing hosts.
Check vSAN and EVC: the new node must join the same vSAN cluster and be compatible with the existing EVC baseline. Confirm disk group configuration, cache/capacity device support, and that the node's disks are on the VxRail compatibility list. Also confirm there is no active rebuild and that the cluster has capacity headroom for resync during expansion.
2. Is the one-disk-group, 1.92 TB node acceptable as-is?
Read the worked answer
It may pass some compatibility checks, but it is not a good production expansion as-is. vSAN can tolerate heterogeneous disk groups, but VxRail clusters are designed for homogeneous node configuration. A node with one disk group instead of two, and smaller capacity disks, creates an immediate capacity and performance imbalance. vSAN will place components according to policy and free space, not evenly across hosts, so the new node may fill faster or contribute less cache and capacity than expected. Rebuild and resync behavior also becomes harder to predict.
Before expansion, decide whether the customer accepts that imbalance. Better options: order a node that matches two disk groups and 3.84 TB capacity disks, or explicitly document the reduced capacity/performance and confirm VxRail support for the mixed configuration. Do not treat 'the wizard let me click Expand' as proof that the design is balanced.
3. What post-expansion validation should be performed?
Read the worked answer
After expansion, confirm the new host is in vCenter, in the VxRail cluster, and in the vSAN cluster with the expected disk groups. Check vSAN health for cluster partition, disk group health, and resync/rebalance status. Confirm the new node's VMkernel adapters are reachable with vmkping at the correct MTU, and that vMotion works to and from the new host. Verify EVC and CPU compatibility, and check that no host is in maintenance mode or disconnected.
Monitor capacity and resync until the cluster returns to a healthy state. Because the new node has different disk groups and capacity, review vSAN free space and policy compliance after rebalancing, and document the asymmetry for future expansions. If alarms appear, do not add another node until the current imbalance is understood.