VMware Cloud Foundation (VCF) on Dell VxRail is a jointly engineered solution by Dell Technologies and VMware by Broadcom. It provides features that simplify, streamline, and automate the operations of your entire software-defined data center (SDDC), from Day 0 through Day 2.

The platform delivers a set of software-defined services, including:

• Compute (with VMware vSphere and VMware vCenter)
• Storage (with VMware vSAN)
• Networking (with VMware NSX)
• Security
• Cloud management (with VMware Aria Suite)

These services support both private and public environments, making the platform the operational hub for your hybrid cloud.

VCF on VxRail provides the simplest path to the hybrid cloud through a fully integrated hybrid cloud platform. This platform uses native VxRail hardware and software capabilities, along with other unique integrations (such as vCenter plug-ins and Dell networking).

These components work together to deliver a turnkey hybrid cloud experience with full-stack integration. Full-stack integration means that both HCI infrastructure layer and cloud software stack are delivered as a single, fully automated lifecycle solution.

This guide outlines the VCF on VxRail architecture, its key components, and the planning and preparation required for a successful deployment. It is designed to complement the Broadcom design and architecture documentation. Refer to those resources for a complete and authoritative perspective.

This document:

• Describes the solution architecture
• Supports decision-making to align configurations with your business requirements
• Highlights the activities and processes involved from initial planning and design through deployment

This guide supports:

• VMware Cloud Foundation version 9.1
• VxRail version 9.1.

The specific software stack versions supported for VMware Cloud Foundation on VxRail are listed in the release notes.

This guide is intended for executives, managers, cloud architects, network architects, and technical sales engineers involved in the planning, design, and deployment of SDDC or hybrid cloud solutions using VCF on VxRail. Readers should have a working knowledge of:

• VMware vSphere
• VMware NSX
• VMware vSAN
• VMware Aria suite
• Fundamental networking concepts

Dell Technologies and the authors of this document welcome your feedback on this document. Contact the Dell Technologies team by email.

Author

Lucy Guichard

By deploying VMware Cloud Foundation (VCF) on Dell VxRail, organizations can virtualize their entire infrastructure and rapidly deliver a fully integrated software-defined data center (SDDC) with automated lifecycle management. This jointly engineered solution includes NSX for advanced networking and security, vSAN for software-defined storage, SDDC Manager for full-stack lifecycle management (LCM), and VCF Operations for intelligent operations, delivering real-time performance visibility, predictive analytics, workload optimization, and licensing and cost insights.

VxRail serves as the resilient hyperconverged foundation, pooling compute, storage, and networking resources into a single scalable platform tightly integrated with VMware software. Together with SDDC Manager and VxRail Manager, this solution eliminates the need for manual, multi-tool operations by providing streamlined and automated lifecycle management across both hardware and software layers.

With VCF 9.1 on VxRail, the platform evolves into a modular, lifecycle-driven private cloud architecture. It introduces a clear separation of responsibilities across deployment, operations, and infrastructure management layers. Deployment and initial bring-up are handled by the VCF Installer, while ongoing lifecycle operations are managed through VCF Operations. VxRail continues to deliver hardware lifecycle management, validation, and integration. This decoupled model improves consistency, scalability, and operational efficiency across the full stack.

At the infrastructure level, VCF 9.1 introduces a staged resource lifecycle model that fundamentally changes how compute resources are onboarded and consumed. Hosts are first prepared using the Node Image Management (NIM) framework, ensuring consistent baseline configuration and firmware compliance. The Node Commission process then introduces hosts into a centralized SDDC host free pool, where they are validated, configured, and prepared for workload consumption. This staged onboarding approach ensures consistency and eliminates dependencies on monolithic provisioning workflows.

To support modern, distributed deployments, the architecture incorporates a federated discovery and onboarding model. Infrastructure components can be discovered and prepared across multiple network segments. The proxy server capability enables node discovery and configuration in isolated or Layer‑3-separated environments, allowing geographically or logically distributed resources to be onboarded through a unified workflow.

At the same time, cluster creation is decoupled from platform management. Workload domains and clusters are created natively using SDDC Manager, independent of VxRail automation. To restore full lifecycle capabilities, the Manage New Cluster workflow deploys a secondary VxRail Manager per cluster, establishing a distributed control plane architecture. In this model, a primary VxRail Manager provides centralized coordination, while secondary managers deliver localized lifecycle management, hardware visibility, and serviceability for each cluster.

These architectural enhancements establish a resource-centric, policy-driven private cloud model. Infrastructure progresses through defined lifecycle stages—imaging, commissioning, consumption, and lifecycle management. The result is a scalable and flexible platform that supports distributed environments, delivers consistent operations, and allows seamless expansion without tightly coupled deployment workflows.

Deployment of VCF on VxRail is orchestrated through the VxRail Manager using a structured, three-module workflow. Each module represents a distinct deployment phase, progressing from infrastructure initialization to full-cluster readiness.

Module 1: Infrastructure Initialization

This phase prepares the underlying physical and management infrastructure:

• Configure ESX hosts
• Initialize the VxRail Manager
• Deploy the VCF Installer appliance

Module 2: VCF Bring-Up

This phase performs the automated deployment of the VCF management domain:

• Launch the VCF Installer
• Execute the VCF bring-up process, which deploys core components (such as vCenter, NSX, SDDC Manager, VCF OPs)

Module 3: Cluster Finalization

This phase completes the configuration of the environment:

• Finalize cluster and management domain setup
• Validate system readiness for workload onboarding
• Perform cluster compliance remediation

This modular workflow provides a structured and repeatable approach to deploying a fully integrated VCF on VxRail solution, ensuring consistency, automation, and alignment with VMware best practices.

VxRail Manager manages vSAN-powered clusters and handles lifecycle management (LCM) for ESX, vSAN, and hardware firmware. It also monitors hardware health and enables remote service support. This deep integration delivers a turnkey hybrid cloud experience unmatched by other infrastructure solutions. VxRail Manager acts as the integration layer between HCI hardware and software, managing both throughout the product lifecycle. By automating updates, monitoring, and maintenance, it reduces the need for extensive operational staffing.

SDDC Manager remains the foundational orchestration and lifecycle engine in VCF 9.1 on VxRail. It manages deployment, configuration, and LCM of the core infrastructure stack, including vCenter Server, NSX, and supporting platform components running on vSphere and vSAN.

It works in conjunction with VCF Operations and VCF Automation to provide advanced monitoring, analytics, policy-based governance, and automated service delivery. Together, these components deliver a comprehensive management framework that combines lifecycle control with operational visibility and infrastructure automation.

Within the VCF architecture, SDDC Manager organizes infrastructure resources into workload domains (WLDs), each backed by one or more VxRail clusters. It provides the automation required to consistently deploy new workload domains, expand existing domains, and perform patching and upgrade operations across the software-defined data center stack. SDDC Manager ensures that all components remain in a supported and validated state, aligning with Broadcom-defined lifecycle bundles and compatibility matrices.

In VCF 9.1, SDDC Manager primarily focuses on day 1 and day 2 operations , including workload domain creation, expansion, and lifecycle execution, such as patching and upgrades. While it continues to act as the authoritative system for infrastructure changes, it operates alongside VCF Operations, which provides enhanced visibility and operational control at scale. Together, this separation of responsibilities supports a more modular and scalable management architecture.

VCF Operations is the centralized operations and fleet management platform in VMware Cloud Foundation 9.1, providing a unified control plane for day-2 operations across the private cloud environment. Fully integrated into the VCF platform, it delivers comprehensive visibility, analytics, and management capabilities across all workload domains and VCF instances.

Unlike earlier releases, where operations tooling was optional or loosely integrated, VCF 9.1 positions VCF Operations as a core platform component. It aggregates telemetry, health data, and configuration insights from across the environment, enabling administrators to monitor performance, troubleshoot issues, and optimize resource utilization from a single interface. It also introduces the concept of fleet-level management, allowing multiple workload domains—and potentially multiple VCF instances—to be managed cohesively.

VCF Operations complements SDDC Manager by providing enhanced observability, capacity planning, and operational intelligence, while also serving as a central interface for interacting with various platform services, including identity and access management. Although it does not replace SDDC Manager’s lifecycle execution role, it provides the operational context and visibility required to plan, validate, and monitor those lifecycle activities.

In VCF 9.1, SDDC Manager and VCF Operations together establish a layered management and control plane that separates execution from observability. SDDC Manager focuses on infrastructure provisioning and lifecycle management, enabling the build and ongoing maintenance of the platform. In contrast, VCF Operations provides monitoring, analytics, and fleet-level operational capabilities, supporting visibility and optimization across environments. This architectural separation marks a shift from earlier VCF versions, delivering improved scalability, clearer operational responsibilities, and an experience more aligned with modern cloud operating models.

VMware NSX Data Center is a software-defined networking and security platform that virtualizes the entire network, enabling a consistent cloud network across data centers, clouds, and edge locations. It delivers core network services—switching, routing, firewalling, and load balancing—closer to applications, improving agility, scalability, and security. NSX allows rapid creation of flexible network topologies and supports advanced capabilities such as microsegmentation and third-party integrations.

Within VCF on VxRail, VMware Avi Load Balancer provides centrally managed, highly available load balancing, deployed automatically through SDDC Manager. NSX also enables efficient routing within and across workload domains, as well as connectivity to external networks.

During the deployment of VCF on VxRail, the VPC Gateway Connectivity option determines how traffic flows between VPCs and external networks.

The Centralized connectivity option directs VPC traffic through a dedicated NSX Edge cluster using a transit gateway, enabling consistent policy enforcement, advanced networking services (such as NAT, load balancing, and firewalling), and simplified integration with shared services or external networks. While centralized connectivity introduces a dependency on edge infrastructure, it is typically preferred for production and enterprise deployments due to its scalability, control, and alignment with hub-and-spoke networking.

The Distributed connectivity option leverages the NSX distributed routing capabilities built into the ESX hosts, allowing east-west and north-south traffic to be handled locally for optimal performance and reduced latency, making it suitable for smaller or less complex environments.

In VCF 9.1 on VxRail, Single Sign-On (SSO) remains a core platform capability, but its implementation has been modernized. VCF 9.1 introduces VCF Single Sign-On, which is delivered through the Identity Broker (vIDB) and provides centralized authentication and authorization across all VCF components. This approach replaces legacy identity models and establishes a unified control plane for identity services spanning vCenter, NSX, VCF Operations, and other management components.

As part of this architectural shift, several legacy constructs have been deprecated. vSphere Enhanced Linked Mode (ELM), which was previously used to provide a shared SSO domain across multiple vCenter instances, is no longer used in VCF 9.x and later versions. Similarly, VMware Identity Manager has been replaced by the Identity Broker service, which is now the standard mechanism for delivering SSO capabilities within the VCF platform. These changes align VCF with modern identity federation practices and reduce operational complexity.

From a design perspective, Identity Broker is deployed within the management workload domain and should be treated as a critical platform service, similar to SDDC Manager.

A workload domain (WLD) consists of one or more Dell VxRail clusters managed by a single vCenter Server instance. WLDs are connected to a network core that distributes data between them. WLDs can include different combinations of VxRail clusters and network equipment, which can be configured with varying levels of hardware redundancy.

From VxRail clusters, capacity can be grouped into WLDs with specific CPU, memory, and storage for different workloads. When SDDC Manager adds physical capacity, it becomes available for WLDs. Two types of WLDs can be deployed:

• A Management WLD (Mgmt WLD), only one per VCF instance
• A Virtual Infrastructure (VI) WLD, also known as a tenant WLD, can be created multiple times within a single VCF instance

The VCF Management WLD VxRail cluster requires a minimum of four hosts to run the infrastructure components that manage the private cloud. This domain is created during the initial system installation (bring-up) using the VCF Installer tool.

In the Management WLD VxRail cluster, VMware vSphere runs with a dedicated vCenter server backed by vSAN storage. It hosts the SDDC Manager, VCF Operations manager, VxRail Manager VMs, and NSX Managers. VMware Aria Automation is optional and must be deployed in accordance with VMware Validated Solutions (VVS) guidance.

The management VxRail cluster must have a minimum of four hosts to provide vSAN FTT=1 during maintenance operations. While the deployment and configuration of the management VxRail cluster are fully automated, once it is running, it is managed like any other VxRail cluster.

The VI WLD can include one or more VxRail clusters, which serve as its foundational building blocks. Each cluster can start with three hosts, though four are recommended to maintain FTT=1 during maintenance operations.

The vCenter and NSX Managers for each VI WLD are deployed into the Management WLD. When the first VxRail cluster is added to the initial VI WLD, a cluster of three NSX Managers is deployed in the Management WLD.

For subsequent NSX-based VI WLDs, you can either reuse the existing NSX instance or deploy a new one with its own set of three NSX Managers. The first VxRail cluster in a VI WLD typically serves as a compute-and-edge cluster, hosting both NSX components and application workloads. NSX Edge nodes are deployed in this cluster. Any additional VxRail clusters in the same VI WLD are considered compute-only.

A VxRail cluster can be dedicated solely to Edge node components if dedicated compute or bandwidth is required. Bare-metal NSX Edge nodes are not supported.

The resources of individual VI workload domains can be expanded by adding nodes into a VxRail cluster or by adding a new VxRail cluster to the workload domain. The physical resources are automatically added to the VI workload domain pool upon completion.

In VCF 9.1, the concept of a formally selectable “consolidated architecture” is no longer presented as a distinct deployment model. Instead, architectural outcomes are determined by deployment choices made during implementation.

Depending on scale, capacity, and design decisions, environments may operate in a consolidated manner, where management and tenant workloads coexist within the same workload domain, even though this is not explicitly defined as a separate architecture type.

In a typical deployment, the management WLD hosts infrastructure and platform services, including components for lifecycle management, cloud operations, automation, business continuity, and security. Additional VI WLDs are then created using SDDC Manager to host tenant or application workloads, enabling separation of concerns and greater operational flexibility.

However, in smaller or resource-constrained environments, customers may choose not to deploy additional VI WLDs. In such cases, tenant workloads may be placed in the management WLD, resulting in a functionally consolidated design. While valid, this is an architectural outcome rather than an explicit design pattern and comes with important trade-offs.

When operating in a consolidated manner, the following limitations and considerations apply:

• Limited separation of concerns: Management and tenant workloads share the same resources, reducing isolation and flexibility compared to designs with dedicated VI workload domains.
• Reduced flexibility for specialized use cases: Workloads that require tailored configurations (such as VDI, Kubernetes/TKG, or performance-sensitive applications) are better suited to dedicated VI WLDs. The management WLD cannot be easily optimized for both platform services and specialized workloads.
• Lifecycle management impact: In standard architectures, lifecycle operations can be applied independently to each VI workload domain. In consolidated configurations, all workloads share the same lifecycle schedule, which may not align with application requirements.
• Scalability constraints: Expansion is tied to the underlying VxRail cluster(s) supporting the management WLD. This limits the ability to scale different workload types independently.
• Network architecture limitations: If the initial deployment uses a constrained network design (for example, two-NIC configurations combining system and NSX traffic), future expansion inherits those limitations. With separate VI WLDs, different network designs can be introduced as needed.
• Migration complexity: Transitioning from a consolidated setup to a segmented architecture requires deploying new VI WLDs and migrating workloads (commonly using HCX or similar tools). This is not an in-place conversion.

A WLD represents a logical boundary of functionality, managed by a single vCenter server instance. Although a WLD usually spans one rack, multiple WLDs can be aggregated in a single rack in smaller deployments. In larger configurations, WLDs can span multiple racks.

A single WLD can stretch across multiple adjacent racks. For example, a tenant WLD that has more VxRail nodes than a single rack can support, or one that requires redundancy, may need to span multiple adjacent racks.

VCF 9.1 on VxRail supports 14G (Cascade Lake CPUs), 15G Intel and AMD, 16G Intel and AMD, and 17G Intel (ESA only) platforms. Refer to the support matrix for detailed information.

Depending on the workload and application requirements, the appropriate VxRail hardware platform must be selected. Work with your Dell account representative for guidance on sizing SDDC components across different VxRail hardware platforms.

The primary building block for compute resources is the server node. VxRail leverages Dell PowerEdge servers as the foundation for a cluster. A VxRail cluster can scale to a maximum of 64 nodes.

VxRail supports a wide range of server configurations, including flexibility in CPU model, CPU quantity and speed, RAM capacity, physical storage capacity, and network port quantity and speed.

The mixing of different server models in a single cluster is supported because VxRail treats each server node as a static pool of compute resources. However, the selected server models should have consistent characteristics for compatibility:

• PowerEdge servers must be of the same generation
• Network ports must be of the same type and speed across all nodes

There are many factors to consider when determining use cases for Cloud Foundation on the VxRail platform. Because of its adaptive architecture, business and operational requirements vary from one situation to another. This section covers key design decisions that must be made before deployment, along with guidance on workload domain planning.

A multi-available architecture offers additional protection beyond a standard or consolidated architecture. Each availability zone is isolated from others to protect against a data center or site failure and to prevent failure propagation across zones.

The VxRail cluster nodes are installed and cabled in racks across two isolated zones. The network between the two zones must provide low latency (less than 5 milliseconds) and sufficient bandwidth (minimum 10 Gbps). This approach helps protect against large-scale outages in a metro area, or more simply, two safety or fire sectors in the same large-scale data center.

A multi-region architecture provides disaster recovery across different Cloud Foundation on VxRail instances. Each region has a similar physical layer and virtual infrastructure designs but maintains independent management domains.

To ensure application availability across disparate Cloud Foundation on VxRail instances, Replication technologies are used to replicate between sites, provided adequate bandwidth is available and latency between regions is less than 150 milliseconds. Compared to a multi-availability architecture, the distance between sites in a multi-region architecture can be significantly greater. However, depending on replication settings and the applications being protected, a multi-region solution may not meet the same RPO and RTO requirements as a multi-availability solution.

Cloud Foundation on VxRail supports VI workload domains at remote locations. With remote clusters, a VI WLD can be deployed with its vSphere cluster located remotely. All the VCF operational management can be administered from a central or regional data center, which is important because:

• It eliminates the need for technical or administrative support personnel at remote locations, resulting in better efficiency and significantly lower operating costs.

• Edge computing allows customers to comply with data locality requirements driven by local government regulations.
• VCF remote VxRail clusters provide a standardized approach to operations and centralize administration and software updates to all remote locations.

Remote VxRail clusters must meet the following requirements:

• Minimum 10 Mbps bandwidth
• Maximum 100 ms RTT latency
• Support for three to 16 nodes per remote site per VI WLD
• A VI WLD can include a local cluster or a remote cluster, but not both
• Primary and secondary active WAN links (not required, but highly recommended)
• DNS and NTP servers are available locally or reachable from central site to Edge site
• A DHCP server must be available for the NSX host overlay (Host TEP) VLAN
• Both private and public WAN connections are supported (subject to compatibility requirements)
• SD-WAN should be considered for deployments spanning across multiple remote sites

Additional considerations:

• Remote sites need NSX Edge nodes for north-south connectivity.
• Central site must stay connected to remote sites for management components (vCenter, SDDC Manager, NSX Manager).
• If DNS and NTP services run centrally, they must be reachable from Edge sites.

Assess and classify the availability requirements to determine the most appropriate architecture and design.

• Determine the operational recovery and disaster recovery objectives for the application sets.
• Place certain application sets in VI WLDs that align with these objectives.

Consolidated architecture is preferred when:

• Planned workload can share resources with the management domain
• Minimal growth is expected
• No specialized applications are required

Multi-availability architecture is preferred when:

• Applications cannot tolerate service or data loss if a site failure occurs
• Network latency and bandwidth requirements between the sites can be met
• All applications can run on a single site if an outage occurs

Multi-region architecture is suitable when:

• Longer distance between sites is desired compared to what is supported with a multi-availability architecture
• Higher RPO and RTO values are acceptable
• Integration with single-site or multi-site instances is needed to offer extended protection

A remote VI WLD is applicable when:

• Remote sites lack administrative capacity
• Workloads fit within the capacity of four VxRail nodes
• Network latency and bandwidth requirements between the central site and remote sites are met

When deploying a new VI WLD, you can either provision a dedicated set of three NSX Manager appliances or reuse an existing NSX management cluster. The appropriate approach depends on specific workload and operational requirements.

Typical scenarios influencing this decision include:

• Non-production environments (such as test, development, or pre-production) that are isolated from the production network
• Application compatibility requirements, such as dependencies on a specific NSX version
• Enhanced isolation and security needs for sensitive or regulated workloads
• Multi-tenant Cloud Foundation deployments, where tenant separation is required
• Introduction of new networking constructs, such as a VLAN-backed transport zone

When deploying a new set of NSX Manager appliances (for example, within the management workload domain), consider:

• NSX Manager appliances are affected by vSphere HA admission control, which impacts cluster capacity planning
• NSX Manager appliances can be CPU-intensive under heavy workloads, so ensure they are properly sized

If a VI WLD requires VMware Aria components, deploy them in the management WLD to enable centralized operations and streamlined lifecycle management. Incorporating Aria into the environment introduces additional configuration considerations, such as:

• Integration with Active Directory for authentication and role-based access control
• Configuration of identity sources and access policies to ensure secure access to Aria services

Address these prerequisites during the design phase to support a smooth deployment and effective ongoing use of the Aria platform.

Prior to conducting a comprehensive sizing exercise for VMware Cloud Foundation on VxRail, define the guiding principles and criteria for creating VI WLDs. Establishing these criteria ensures that workload domains are aligned with business, operational, and technical requirements.

Key considerations:

• Logical grouping of applications to optimize interconnectivity, reduce latency, and simplify communication patterns
• Resource ownership and allocation, enabling clear assignment and governance of compute, storage, and network resources across internal teams or business units
• Operational management at scale, including the ability to manage multiple sites or environments from a centralized control plane

These considerations directly affect infrastructure sizing, capacity planning, and design for each WLD. Defining WLD use cases is critical to ensuring an efficient, scalable, and maintainable Cloud Foundation deployment.

For multi-location deployments, choose between:

• Single-site deployment with local management at each location
• Centralized site managing workloads at both local and remote locations

Key considerations for adopting a centralized management model include:

• Cluster scale constraints: Remote WLD clusters are limited to a maximum of 16 nodes
• Network bandwidth: A minimum of 10 Mbps sustained bandwidth between sites is required
• Network latency: Inter-site latency must not exceed 100 ms round-trip time (RTT)
• Link resiliency: Redundant WAN connectivity is strongly recommended to maintain availability and management continuity
• Management connectivity: Management components in the central domain must maintain reliable network connectivity to all remote WLDs

When planning a VCF 9.1 deployment on VxRail, determine whether the environment will remain in a single region or evolve into a multi-region architecture leveraging NSX Federation.

A phased approach is commonly adopted, starting with a single-region deployment and expanding to a multi-region architecture as business and availability requirements grow.

For multi-region designs using NSX Federation, consider the following:

• Inter-region latency
  • NSX Federation supports higher latency thresholds for control-plane communication, but lower latency is recommended for optimal performance
  • Data-path and cross-site networking scenarios may impose stricter latency requirements depending on workloads
• Network bandwidth and resiliency
  • Provide sufficient bandwidth for synchronization, policy distribution, and inter-site communication
  • Use redundant WAN connectivity to ensure resilience and operational continuity
• MTU configuration
  • A minimum MTU of 1600 bytes is required for NSX overlay traffic
  • Higher MTU values (jumbo frames) are recommended where supported (to improve throughput and efficiency)

These considerations directly affect performance, scalability, and resiliency of a multi-region VCF deployment.

During the initial deployment of VCF 9.1 on VxRail, core management components are deployed in the management WLD. These components, deployed through the VCF Installer and lifecycle-managed through SDDC Manager and VCF Operations, establish the baseline infrastructure required to operate and expand the private cloud environment.

This initial footprint defines the minimum resource requirements needed to support platform services and enables creation and lifecycle management of VI WLDs.

Two architectural models must be considered:

• Consolidated architecture
  • Management components and tenant workloads share the same WLD resources
• Standard architecture
  • Management components run in a dedicated management domain
  • Tenant workloads run in separate VI WLDs

As additional VI workload domains are deployed, management resource requirements increase. Each domain introduces its own set of management components (such as vCenter Server and NSX instances), increasing the overall resource consumption of the platform.

For this reason, it is essential to:

• Define VI WLD use cases early in the design phase
• Perform a comprehensive resource assessment that includes:
  • Management WLD requirements
  • All planned VI WLDs
• Use this consolidated assessment to determine the appropriate sizing of the underlying VxRail infrastructure, including compute, memory, storage, and network capacity

Proper planning ensures that sufficient capacity is available to support both initial deployment and future scaling, while maintaining performance and operational efficiency across the VCF environment.

In VCF 9.1 on VxRail deployment, at least one VI WLD is required to host tenant (guest) virtual machines in a standard architecture. Each WLD is backed by dedicated VxRail clusters, which serve as the resource foundation for that domain.

These clusters are exclusively dedicated to the domain, and their compute, storage, and network resources are not shared across other domains. This isolation is fundamental to workload separation, lifecycle management, and resource governance.

When a VI WLD is created:

• A vCenter Server instance is deployed to manage the resources within the WLD
• NSX networking is provided either by reusing an existing NSX instance or by deploying a new one

In a standard architecture:

• A minimum of two NSX instances typically exist:
  • One for the management WLD
  • One for VI WLD (shared or dedicated)

Given these considerations, resource planning for VI WLDs should include:

• Compute and storage capacity of the dedicated VxRail clusters
• Overhead of management components (vCenter and optional NSX instances)
• Networking and security requirements that influence NSX design

A clear understanding of WLD use cases and NSX architecture is essential to accurately size the platform and ensure scalable, efficient operation across the VCF environment.

The best practice for resource sizing is to establish an initial baseline for management resources based on use cases, and then calculate the additional resources required for guest virtual machines. Dell Technologies uses a sizing tool to estimate workload resource requirements for the Cloud Foundation domains. This sizing exercise determines the resource pools needed to meet VI WLD demands and their service level objectives at an optimal cost.

The solution uses the network virtualization built in VMware vSphere for deploying and operating VxRail clusters. VCF also relies on the underlying vSphere network to support a comprehensive virtualized network with advanced features.

VCF supports traffic isolation between management virtual machines and ESX management VMkernel interfaces. This enhancement allows administrators to configure separate subnets and VLANs for the ESX management Distributed Virtual Port Group (DvPG) and management VM DvPG.

VCF requires additional VLANs on the ToR switches connected to VxRail nodes in the management WLD VxRail cluster. Refer to the Broadcom VMware Cloud Foundation (VCF) design documentation for VLAN requirements for management and VI WLD deployments.

In VCF 9.1, there are four predefined vDS network profiles that differ mainly in how they separate traffic types across distributed switches:

• The Default (Converged) profile uses a single vDS where all traffic types (management, vMotion, vSAN, and NSX overlay) share the same switch, making it the simplest and most resource-efficient option, but with minimal isolation.
• The Storage Traffic Separation profile introduces a second vDS to isolate vSAN traffic, improving storage performance while keeping management, vMotion, and NSX traffic together.
• The NSX Traffic Separation profile also uses two vDS instances but instead isolates the NSX overlay traffic onto its own switch. This improves network and security segmentation while keeping management, vMotion, and vSAN traffic combined.
• The Storage and NSX Traffic Separation profile provides full isolation by using three vDS instances:
  • one for management and vMotion
  • one for vSAN
  • one for NSX overlay traffic

    This offers the highest level of performance and fault isolation but requires more physical NICs and design complexity.

The Custom vDS profile in VCF 9.1 allows full control over host networking layout instead of using predefined profiles. With this option, you can:

• Create any number of distributed switches (within supported limits)
• Assign uplinks (pNICs) to each vDS
• Map traffic types (such as management, vMotion, vSAN, and NSX overlay) to specific switches and uplinks.

It essentially gives you complete control over traffic separation, NIC utilization, load‑balancing policies, and failover behavior. You can also start from a predefined profile and modify it rather than building from scratch. This flexibility is typically used in advanced designs where standard profiles do not fit, such as environments with uneven NIC layouts, strict isolation or compliance requirements, or performance-optimized designs. However, it adds design and operational complexity.

Refer to Broadcom VCF design documentation for vDS predefined and custom profile considerations.

In this architecture, vSAN is the only supported principal storage platform for both Management and VI WLDs in VCF on VxRail.

With VCF 9.1, only vLCM (vSphere Lifecycle Manager)-based clusters are supported, ensuring consistent lifecycle management and full alignment with VxRail automation.

Key requirements

• Management WLD VxRail cluster requires vSAN as its principal storage
• All VI WLD VxRail clusters must use vSAN as principal storage
• External storage platforms (such as Fibre Channel / VMFS) are not supported as principal storage in this design
• Stretched cluster configurations are not supported for Management or VI WLD clusters

Supplemental storage options are supported for both Management and VI WLDs and include:

• iSCSI
• NFS
• NVMe over TCP / FC
• PowerFlex (where applicable)

These options are strictly supplemental and cannot be used as principal storage.

vSAN is fully integrated with VxRail and is deployed, scaled, and lifecycle-managed using SDDC Manager and vLCM. This provides a consistent and automated operational model across the VCF fleet.

Supported architectures:

• vSAN Express Storage Architecture (ESA)
  • Recommended for new deployments
  • Requires NVMe-based hardware
  • Provides improved performance, scalability, and efficiency through single-tier architecture
• vSAN Original Storage Architecture (OSA)
  • Supported for compatibility with existing environments
  • Fully managed using vLCM

vSAN leverages Storage Policy-Based Management (SPBM) to define storage characteristics such as:

• Failures to tolerate (FTT)
• Data resilience and availability
• Performance characteristics

These policies can be applied and modified non-disruptively at the VM or object level, without infrastructure changes.

In a consolidated architecture:

• Additional clusters in the management WLD follow the same model as VI WLD clusters
• vSAN remains the mandatory principal storage platform
• Supplemental storage follows the same constraints as the primary management cluster
• Stretched configurations are not supported