Dell VxRail Deploy cheat sheet

VxRail is a hyperconverged system co-engineered by Dell and VMware; each node runs ESXi with vSAN providing the distributed datastore, and VxRail Manager runs as a VM on the cluster.

Minimum viable cluster is 3 nodes; 2-node clusters require a witness appliance placed at a third site or fault domain, and stretched clusters use 2+2 nodes plus a witness.

All nodes in a VxRail cluster must be the same model and same or comparable drive configuration; mixing models within one cluster is not supported for initial build.

Sizing rule: usable vSAN capacity = raw capacity minus vSAN overhead, minus the failure tolerance (FTT=1 reserves one copy equivalent), minus ~30% free-space headroom target.

RAID-5 erasure coding in vSAN requires a minimum of 4 nodes; RAID-6 requires a minimum of 6 nodes; below those thresholds FTT is achieved with RAID-1 mirroring.

Network planning: separate VLANs for management, vMotion, vSAN, VM traffic, and VxRail Manager; 10 GbE minimum per node, 25 GbE recommended for all-flash.

VxRail Manager must resolve by FQDN from every node and from the deployment client; DNS records and PTR records for all management addresses are prerequisites.

The deployment client (browser host) must reach VxRail Manager and the ESXi management addresses; a flat L2 path or routed access with correct firewall openings is required.

NTP is mandatory: one or more reachable NTP sources must be defined so that vCenter, ESXi, and VxRail Manager stay time-synchronized; external vCenter is supported for VxRail 7.x and later.

Rack nodes front-to-back with cold aisle at the front; leave 1U of clearance above and below for airflow if the rack permits, and install rails before lifting the chassis.

Power each node from redundant PDUs on separate feeds; the PSUs are hot-swappable and each node should draw from both A and B feeds.

Connect the iDRAC (or equivalent BMC) port to the management network first; iDRAC gives remote console and virtual media access for the rest of the build.

Set iDRAC IPs statically or via DHCP reservation before power-on; each node needs a unique management IP and hostname that matches DNS.

Boot order and boot device: VxRail uses a dedicated boot device (BOSS card or M.2 RAID-1) separate from vSAN capacity and cache drives; confirm the boot device is healthy before install.

vSAN cache tier: one cache drive per disk group; all-flash nodes use write-buffer semantics, hybrid nodes use read/write cache; disk groups are created by the VxRail build process.

Cabling: use the supported SFP+/SFP28 optics and DAC cables for the model; uplinks typically go to a pair of top-of-rack switches in a redundant topology (LACP or active/standby).

Verify hardware health in iDRAC (PSU, fans, memory, drives) before starting the VxRail deployment; a failed drive or PSU will halt or degrade the build.

Firmware baseline: VxRail bundles a validated firmware/software bundle; do not upgrade individual components outside the VxRail bundle unless directed by support.

Deployment flow: power on nodes, access VxRail Manager via the initial wizard (Mystic), supply vCenter credentials, network settings, and the VxRail bundle, then let the automated build run.

VxRail Manager initial access uses a temporary bootstrap address; the permanent address and FQDN are set during the wizard and must match DNS.

The vCenter used may be the embedded VxRail vCenter (VxRail-managed) or an external customer-supplied vCenter; external vCenter requires the correct permissions and version compatibility.

VDS (vSphere Distributed Switch) is the default networking model for VxRail 7.x; standard vSwitch is used only in specific/legacy configurations.

Uplink assignment: map physical NICs to VDS uplinks, then create port groups for management, vMotion, vSAN, and VM networks with the correct VLAN IDs.

MTU: vSAN and vMotion port groups typically use jumbo frames (MTU 9000); the entire L2 path (physical switches, VDS, VMkernel) must match or frames are dropped.

IP pool planning: each VMkernel service needs its own IP per node; reserve contiguous ranges for vSAN and vMotion VMkernels before running the wizard.

Stretched and 2-node clusters require witness traffic separation: a dedicated witness VMkernel and VLAN, and the witness appliance placed at a third site.

Post-build validation: confirm cluster health in VxRail Manager, vSAN health in vCenter, all nodes in the cluster, and no configuration drift in the VxRail plugin.

VxRail Manager is the single pane for lifecycle: bundle upgrades, health checks, and log bundles; the VxRail plugin surfaces this inside vCenter.

Upgrade order for a VxRail bundle: VxRail Manager pre-checks, then vCenter (if embedded), then ESXi nodes one at a time (vSAN rebuild between nodes), then VxRail Manager itself.

Before any upgrade, run the VxRail pre-upgrade health check and confirm no degraded vSAN objects, no failed disks, and sufficient free capacity for rebuilds.

Log collection: use the VxRail Manager log bundle (or the CLI) to gather ESXi, vCenter, and VxRail Manager logs for support; the bundle is the standard first troubleshooting artifact.

vSAN health in vCenter: check cluster > monitor > vSAN > health for object health, disk balance, and network checks; a failing network check points to MTU or VLAN mismatch.

Node replacement: put the node in maintenance mode with 'ensure accessibility' or 'full data migration' depending on capacity; full migration requires enough free space to rebuild.

VxRail Manager unreachable: verify the VxRail Manager VM is powered on in vCenter, check its IP/DNS, and confirm the plugin service is running; a common cause is a DNS or certificate change.

Configuration drift: if the VxRail plugin reports drift, run the reconcile/resync operation from VxRail Manager rather than editing vCenter objects manually.

Capacity alerts: monitor vSAN capacity and the VxRail 'cluster expansion' readiness; add a node or expansion shelf before usable capacity drops below the rebuild reserve.