Standard VxRail clusters scale from 3 to 64 nodes, expanding one node at a time without downtime. Dell’s current lineup includes E, P, V, S, and D series nodes, plus the newer VE, VP, and VS series built on the R660 and R760 PowerEdge platforms. A 2-node cluster is a separate edge configuration that does not expand incrementally. Every added node must match the cluster’s hardware generation and software version under Dell’s node addition matrix.
Most VxRail sizing conversations start with a question that has a simple answer: how big can this get. The number is 64 nodes. The harder question comes later, usually eighteen months into ownership, when a team tries to add capacity to a cluster it already runs and discovers the answer depends on more than the Dell catalog.
How Large Can a VxRail Cluster Get
A standard VxRail cluster supports 3 to 64 nodes, expanding in single-node increments. That is the number that matters for almost every production sizing conversation, and it is the ceiling and floor to plan against.
The 2-node configuration is a separate case and worth understanding on its own terms, because it does not behave like a small version of the standard cluster. It uses either direct-connect networking between the two hosts or a single top-of-rack switch, with an external witness appliance providing quorum. It does not scale one node at a time. A 2-node ROBO cluster has to be converted to a standard 3-node cluster before it can grow further, and that conversion requires VxRail 7.0.130 or later. If the cluster is on direct-connect networking specifically, it cannot be expanded at all without physically rebuilding the network topology first. Anyone planning growth into a 2-node deployment needs to know that going in, not discover it during the expansion.
Below the 3-node floor, vSAN, VMware’s storage layer, cannot satisfy the fault tolerance most enterprise workloads require. A cluster protecting against two simultaneous host failures needs at least five hosts under a mirrored policy, or six under an erasure-coded one. The maximum on paper and the minimum that actually protects your data are two different planning numbers, and both matter more than the marketing figure in between.
Stretched clusters, which split a cluster across two physical sites for site-level disaster recovery, cap lower. The supported configuration tops out at 20 nodes per site plus one witness host at a third location, for 41 hosts total. A team planning a two-site deployment around the 64-node number will size wrong. Above 32 nodes in a standard cluster, Dell has historically required an RPQ, a request for product qualification, so that ceiling is worth a call to your account team before it becomes a line item in a design document.
| Configuration | Minimum nodes | Maximum nodes | Notes |
|---|---|---|---|
| Standard vSAN cluster | 3 | 64 | Single-node increments. RPQ required above 32 nodes. |
| 2-node cluster | 2 | 2 | Direct-connect or single ToR switch, external witness. Does not scale incrementally. Must convert to a 3-node standard cluster (7.0.130+) to grow. |
| Stretched cluster | 1+1+1 | 20+20+1 | Per-site node counts plus one witness at a third location. |
| Dynamic node cluster | 2 | 64 | Compute-only. No vSAN. External Dell storage. |
| Satellite node | 1 | 1 | Single-node edge deployment managed by VxRail Manager. |
Table 1. VxRail cluster sizing reference. Confirm against the current Dell VxRail spec sheet before finalizing a design.
VxRail Node Series Explained
Dell sells VxRail nodes across five primary series, each built for a different workload profile, plus three current-generation models that carry a different naming convention worth understanding precisely, because it is easy to misread.
E Series nodes are the general-purpose starting point, a balanced 1U platform for mixed enterprise workloads. P Series nodes are 2U and built for performance, the right choice for databases and transactional systems that need more compute per node. V Series nodes are GPU-equipped 2U systems for VDI, graphics workloads, and AI and ML inference. S Series nodes are storage-dense, suited to archives, analytics platforms, and video surveillance where capacity matters more than compute. D Series nodes are ruggedized, rated for harsh and space-limited environments and used in mobile command centers and retail edge sites.
The current-generation models use a naming pattern that looks like the older V and E series but means something different. VE-660 and VP-760 are the two most common models in this line. The V does not stand for VDI here. It stands for VxRail, Dell’s naming prefix for these newer nodes. VE-660 is the 1U general-purpose node built on the PowerEdge R660 platform, the direct successor to the E Series. VP-760 is the 2U performance node built on the R760, the successor to the P Series. VS-760 is the storage-dense model in the same generation, built on the same 2U chassis as VP-760. AMD versions exist alongside the Intel models: VE-6615 and VP-7625. A cluster built entirely from current-generation nodes will show VE, VP, and VS model numbers, not a VDI-hybrid label of any kind.
Suffixes describe the drive configuration, and the convention is a substitution, not an addition. F means the model is all-flash using SAS or SATA drives. N replaces the F to mean all-NVMe. E560F is the all-flash SAS/SATA model. E560N is the all-NVMe model of the same node. There is no combined FN designation. A node is one or the other, never both.
The G Series is a legacy line at this point, limited to the G560 and G560F models. It still appears in older deployments, but it is not the starting point for a new purchase.
Dynamic Nodes and Satellite Nodes Change the Scaling Question
Not every scaling problem is solved by adding a vSAN node. Dynamic nodes are compute-only. They run no local vSAN storage and instead connect to external Dell storage such as PowerStore, PowerMax, PowerFlex, or Unity XT. That separates compute and storage scaling, which matters for organizations that need to grow one faster than the other without buying both together.
Satellite nodes are single-node edge deployments managed centrally through VxRail Manager, aimed at retail locations, clinics, and other remote sites that need local compute without local IT staff. A buyer asking whether VxRail can scale to their requirements sometimes gets a better answer from one of these than from a larger cluster.
| Series | Form factor | Built for |
|---|---|---|
| E Series | 1U | General purpose and balanced workloads. Legacy naming, still shipping. |
| VE-660 / VE-6615 | 1U | Current-generation general purpose. R660 platform. VE-6615 is the AMD model. |
| P Series | 2U | Performance-intensive workloads. Databases and transactional systems. Legacy naming. |
| VP-760 / VP-7625 | 2U | Current-generation performance. R760 platform. VP-7625 is the AMD model. |
| V Series | 2U | GPU-equipped. VDI, graphics workloads, AI and ML inference. |
| VS-760 | 2U | Current-generation storage-dense node. Same R760 chassis as VP-760. |
| S Series | 2U | Storage-dense. Archives, analytics, video surveillance. Legacy naming. |
| D Series | Ruggedized | Harsh and space-limited environments. NEBS and MIL-STD rated. |
| G Series | 2U | Legacy line. G560 and G560F only. |
Table 2. VxRail node series and workload fit. Suffix convention: F is all-flash SAS/SATA, N replaces F for all-NVMe. There is no combined FN model.
How Non-Disruptive Scale-Out Actually Works
Adding a node follows a consistent sequence. The new node is racked and cabled, VxRail Manager discovers it on the network, the node is imaged to match the software version the cluster is already running, and it joins vCenter. Its drives are then absorbed into the shared vSAN datastore. Workloads keep running through all of it.
What happens next is the part vendor material tends to skip. vSAN rebalances data across the newly enlarged datastore, moving components to spread capacity and I/O evenly across every node, including the ones that were already there. That rebalance consumes network and disk I/O on the whole cluster while it runs. Adding the node is non-disruptive. The rebalance that follows is not always invisible, and on a cluster already running close to capacity, it is a background operation you can feel.
What You Can Actually Add to an Existing Cluster
Dell publishes a Node Addition Matrix that governs which nodes are allowed to join which clusters, organized by PowerEdge server generation and the VxRail software version the cluster is running. VxRail 9.0.000 supports adding 15G and 16G Intel platforms. 17G nodes entered the matrix with 9.1.x, but only as part of new VCF 9.1 standard vSAN ESA cluster builds, not as an addition to a cluster someone is already running. 14G Skylake nodes are out of scope on 9.x; 14G Cascade Lake platforms remain supported on VCF 9.1. Clusters on VxRail 8.0 can add 14G, 15G, and 16G nodes.
VxRail 7.0.x is a separate case, and it is the one worth understanding precisely rather than treating as a smaller version of 8.0. VxRail 7.0.x reached end of life on September 30, 2025. Dell’s node addition matrix now lists the entire 7.0 section as previously supported, not current. A cluster still running 7.0.x today has no supported path to add a node at all. That is a stronger version of the point this section is making, not an exception to it. An organization on 7.0.x is not looking at a narrower set of compatible hardware. It is looking at zero, until the cluster is upgraded off an end-of-life release.
This is the constraint that actually surprises people, even on a supported version. An organization running a cluster on 8.0 or a supported 9.x build that wants to add two nodes this quarter is not shopping the current Dell catalog. It is shopping the intersection of the current catalog and whatever its running VxRail version supports. That intersection narrows every year the cluster goes without an upgrade, and for a cluster that has fallen behind onto an EOL release, the intersection is empty. Eventually the honest answer to “can we expand this” is “not until you upgrade it first,” which turns a straightforward procurement request into a lifecycle project nobody budgeted for.
The Rules That Actually Stop an Expansion
Software version and hardware generation get the attention, but several harder rules block expansions just as often and get discovered later in the process, usually after hardware has already been ordered.
- Processor family cannot mix. Intel nodes join Intel clusters. AMD nodes join AMD clusters. There is no cross-platform path.
- Storage configuration cannot mix. Hybrid nodes cannot join an all-flash or all-NVMe cluster. All-NVMe nodes cannot join a hybrid or all-flash cluster.
- The first three nodes in a cluster must match each other. This sets the baseline configuration everything added afterward has to conform to.
- Network speed is fixed at deployment. A node built for 10GbE cannot join a cluster running 25GbE.
- Clusters on VxRail 8.0.300 can only add 14G nodes that are already running 8.0.300 themselves. A new 14G node typically has to be reimaged to that version before it can join, which is a step worth budgeting time for rather than discovering on install day.
Link Aggregation Group configurations also require matching speed and duplex settings across every node in the cluster, and licensing for the new node has to be sorted with Dell or your reseller separately from the hardware order. Under VCF 9 licensing, vSAN capacity beyond the per-core entitlement is licensed per TiB, so adding drives to expand storage can carry a real licensing cost on top of the hardware, not just a capacity gain. That is a change from how VxRail expansion used to be priced, and it belongs in the budget conversation, not a surprise on the invoice.
One more constraint worth naming precisely rather than folding into the vSAN OSA versus ESA comparison covered elsewhere in this series: vSAN ESA node requirements of 16 CPU cores and 128 GB of memory per node are the floor set by VMware’s vSAN ReadyNode program, not a VxRail-specific number. VMware also renamed its ESA profile tiers in November 2025. The entry tier formerly called ESA-AF-0 is now vSAN-HCI-SM, and that smallest profile now supports 10GbE networking, which was not the case under the original profile definitions. Worth checking the current profile name against a quote rather than assuming an older document has the right label.
Where this connects to lifecycle risk
Expansion projects fail on version compatibility far more often than they fail on capacity math. If a cluster has drifted behind on firmware and software updates, or worse, is still running an end-of-life release like 7.0.x, the node you want to add this month may not be supported until the cluster is brought current first. See VxRail Lifecycle Management: Firmware Updates, Automation, and Rollback for what that update process actually involves and what happens when it does not go cleanly.
When to Scale Up Instead of Scale Out
Adding nodes is not the only lever available. Drive expansion within existing nodes adds storage capacity without adding a rack unit, a power circuit, or another set of network ports, though under VCF 9 licensing it is not necessarily license-free. vSAN capacity beyond the per-core entitlement is licensed per TiB, so added drives can still show up as a licensing cost even without a new node. Choosing denser node configurations at the next refresh cycle raises the per-node ceiling for the whole cluster going forward.
The decision rule is straightforward. Scale out when the cluster needs more compute and storage together, or when it needs more failure domains to support a stricter fault tolerance policy. Scale up when storage is the only constraint and the cluster already has enough hosts to satisfy its current protection policy. Scaling up does nothing for fault tolerance on its own. A larger node is still one node, and one more terabyte on an existing host does not survive that host’s failure any better than the terabyte it replaced.
What Cluster Growth Does to Lifecycle Management
Every node added to a cluster lengthens its maintenance window. Lifecycle updates run node by node, so a 20-node cluster takes meaningfully longer to update than a 6-node cluster, and that gap grows with every expansion. Larger clusters also tend to accumulate more hardware generation variety over a few years of incremental growth, which is exactly where firmware drift starts.
The consequence is not just inconvenience. A longer update window is a longer window during which the cluster runs in a mixed-version state, with some nodes updated and others not yet touched. A cluster in that state is harder to diagnose when something goes wrong, because a fault can be specific to one node generation rather than to the platform as a whole, and figuring out which requires someone who knows the difference.
Maven has handled that exact scenario directly. Our case study on restoring stability after a failed VxRail lifecycle upgrade covers a cluster that hit exactly this problem: growth over several years left it in a state where a routine update did not complete cleanly, and the fix required engineering judgment, not another ticket in a queue. If your cluster has grown past its original design and you are not confident about what a firmware update will do to it, that is worth a conversation before the next expansion, not after it goes wrong.
Maven supports VxRail environments through exactly this kind of complexity: version compatibility across mixed clusters, firmware alignment during expansion, and recovery when a growth plan runs into a lifecycle wall. Learn more on our Hyperconverged Infrastructure (HCI) Recovery and Support page, or contact us to talk through a specific expansion plan.
FAQ: VxRail Scalability and Node Limits
What is the maximum number of nodes in a VxRail cluster?
A standard VxRail cluster supports up to 64 nodes, and Dell has historically required an RPQ for clusters above 32 nodes. Stretched clusters have a lower ceiling of 20 nodes per site plus one witness node at a third location, for 41 hosts in total.
What is the minimum VxRail cluster size?
Three nodes is the minimum for a standard production cluster. VxRail also supports a separate 2-node configuration for edge and remote sites, using either direct-connect networking or a single top-of-rack switch with an external witness, but a 2-node cluster does not expand incrementally like a standard cluster does. Policies requiring tolerance for two simultaneous failures need at least five hosts under a mirrored policy or six under an erasure-coded one.
Can you mix different VxRail node types in the same cluster?
Within limits. VxRail 9.0.000 supports adding 15G and 16G Intel nodes. 17G nodes are only available as part of new VCF 9.1 cluster builds, not as an addition to an existing cluster. VxRail 8.0 supports 14G, 15G, and 16G. VxRail 7.0.x has no supported node addition path at all, since it reached end of life on September 30, 2025. Beyond software version, Intel and AMD nodes cannot mix, hybrid and all-flash or all-NVMe nodes cannot mix, and the first three nodes in a cluster set the baseline every later addition must match.
Does adding a node to a VxRail cluster require downtime?
No, for a standard 3-to-64-node cluster. A new node joins a running cluster and is absorbed into the vSAN datastore without interrupting workloads, and vSAN then rebalances data across the enlarged datastore in the background. A 2-node cluster is different: it does not grow one node at a time, and expanding it means converting to a standard 3-node cluster first.
What is a VxRail dynamic node?
A dynamic node is a compute-only VxRail node that runs no local vSAN storage. It uses external Dell storage, such as PowerStore, PowerMax, PowerFlex, or Unity XT, as primary storage, letting compute and storage scale independently while retaining VxRail lifecycle management. A dynamic node cluster requires a minimum of two nodes.
How long does a VxRail cluster expansion take?
Racking, discovery, imaging, and joining the cluster typically take a matter of hours once hardware is on site. The vSAN rebalance that follows runs longer, from hours to days depending on cluster size and how much data needs to move.
Planning a VxRail expansion?
Maven’s engineers work directly with organizations sizing node additions, validating version compatibility, and recovering clusters that hit a lifecycle wall mid-expansion. Contact Maven IT Solutions to talk through your cluster’s specific growth plan.
