D-VXR-DY-01: VxRail Deploy V2Demo

VxRail iDRAC management requires 1 GbE connectivity, but it can use open ports on the same ToR switches used for VxRail network traffic instead of a dedicated out-of-band management switch. LACP-based link aggregation can optimize demanding networks when selected, but it is not universally required before deployment.

Day 1 VxRail API operations cover initial cluster deployment: discovering the available hosts, configuring and initializing a new cluster, and checking the initialization request’s status. Cluster expansion and software upgrades are post-deployment lifecycle operations. Dell’s VxRail API documentation identifies initialization-host discovery and the system initialization API, while its release documentation treats lifecycle-management upgrades and cluster expansion as separate operations.

The -b option creates a VxRail Manager backup, and the -l option lists the backup copies. VxRail Manager logs are included only with --keeplog; listing existing services uses -d.

For a customer-managed VMware VDS using LAG, the LACP policy must be configured on the VDS in the customer-managed vCenter Server instance, and the appropriate port groups must have the required teaming and failover policy. Thus, the LAG uplink configuration must already exist in vCenter before implementation.

VMware vSAN ESA on VxRail requires at least 10 GbE networking. Higher speeds such as 25 GbE and 100 GbE are supported, but 10 GbE is the minimum.

VxRail node discovery relies on the VMware Loudmouth service and the internal management VLAN. Changing the VLAN assigned to the private discovery port groups requires restarting Loudmouth so the service resumes discovery using the updated network configuration. The same VLAN can be assigned to both the Private Management Network and Private VM Network, and the default discovery VLAN is not mandatory.

The iDRAC management interface must use the dedicated NIC, and IPMI over LAN must be enabled so that deployment can access and manage the nodes through iDRAC. The IPMI channel privilege requirement is Administrator, not Operator.

Supported Dell VxRail configurations include GPUs, Fibre Channel HBAs for external Fibre Channel connectivity, and DPUs/SmartNICs on applicable node models. Auxiliary power units and InfiniBand adapters are not listed VxRail node options.

A VxRail-managed VMware vCenter Server is deployed and lifecycle-managed as part of the VxRail environment, so it is included in future VxRail Manager updates. External DNS and NTP servers remain outside VxRail lifecycle management.

vCenter Server Essentials is limited to three hosts and vCenter Server Foundation to four hosts. A five-node VxRail cluster therefore requires vCenter Server Standard, the edition that supports clusters beyond the Foundation limit.

When Spanning Tree Protocol is enabled, physical switch ports connected to VxRail nodes must be configured as edge ports (PortFast) so they enter forwarding immediately and do not disrupt VxRail traffic during STP state transitions.

For the predefined two-uplink VxRail network configuration, the VMware vSAN port group uses one active uplink and one standby uplink. This provides failover redundancy while operating as an Active/Standby team.

A VxRail-managed vCenter is limited to managing VxRail clusters and cannot manage other ESXi hosts or a non-VxRail vSAN cluster. A customer-managed vCenter is required when the same vCenter must manage that existing non-VxRail vSAN cluster.

A customer-managed vCenter Server deployment requires an external, customer-managed DNS service for the VxRail management components; VxRail internal DNS is intended for deployments with a VxRail-managed vCenter Server. Consequently, the DNS Server setting is locked to External.

A standard VxRail cluster with VMware vSAN has a minimum configuration of three nodes and can scale to a maximum of 64 nodes.