Part 4 of the 10-part VCF series. Now that the economics and licensing complexities are sorted, we can return to the technology. This article maps out the logical boundaries of VCF 9.x, diving into Management Domains, Workload Domains, and the unified VCF Fleet architecture.
The Core Blueprint: Physical to Logical Boundaries
In a traditional vSphere environment, your structural layout is determined by vCenter servers, datacenters, and clusters. VCF 9.x introduces a rigid, highly opinionated logical hierarchy that sits on top of your physical hardware.
Understanding how these architectural containers nest inside each other is vital before laying out server hardware or creating network subnets:
- VCF Private Cloud: The absolute peak of your organizational hierarchy. It serves as the top-level administrative container representing your entire sovereign cloud footprint.
- VCF Fleet: A massive macro-management boundary. A Fleet unifies multiple underlying VCF instances and standalone vCenter environments under a single pair of shared management utilities (VCF Operations and VCF Automation).
- VCF Instance: The real physical infrastructure realization. This represents a distinct, localized cloud boundary consisting of a single management domain and its associated workload domains.
- VCF Domain: The foundational structural block where compute, storage, and networking actually integrate to host virtual machines or containerized systems.
Management Domains vs. Workload Domains
Inside every VCF Instance, infrastructure is strictly divided into two distinct domain variants. They serve entirely separate purposes and have completely different design constraints.
The Management Domain
The Management Domain is the centralized cockpit of the platform. It is automatically provisioned during day-zero deployment by the VCF Installer appliance.
Its Single Purpose: It explicitly hosts the control plane components that keep the cloud platform running. Your infrastructure management appliances, including vCenter Server, NSX Managers, SDDC Manager, VCF Operations, VCF Automation, and the containerized VCF Management Services framework, all run here.
The Golden Architecture Rule: You do not run customer, business, or developer application workloads in the Management Domain. Mixing operational management tools with volatile customer workloads breaks the isolated management plane model.
Resource Floors: Because it hosts heavy infrastructure databases and analytics engines, a production Management Domain requires a strict physical minimum of 4 ESX hosts in a dedicated vSAN cluster.
Workload Domains (VI-WLDs)
Workload Domains are where the real day-to-day business happens. You create these on-demand via automated workflows after your platform is active.
Its Single Purpose: To provide dedicated, completely isolated compute, storage, and network resource pools for your active applications, databases, or container platforms.
Flexibility Floors: Unlike the Management Domain, a regular Workload Domain can start out on a lighter physical footprint of 3 ESX hosts using vSAN, or can even scale down to 2 hosts when utilizing specialized external Fibre Channel or NFS storage backends.
Granular Isolation: Each Workload Domain receives its own dedicated vCenter Server instance. This gives you complete isolation boundaries: an upgrade or configuration error inside one Workload Domain cannot crash the control plane or impact another isolated business unit.
The 9.x Multi-Cluster Strategy
Inside a single Workload Domain, you can deploy multiple distinct vSphere clusters to segment different types of applications. Under the VCF 9.x architecture, you have two primary choices when mapping out cluster growth:
Standard Compute Clusters
These are your bread-and-butter hardware footprints. They pool standard x86 servers to run traditional enterprise applications, mixed virtual machines, and basic Kubernetes workloads. They are designed for high-density consolidation, heavy memory overcommit, and standard high-availability policies.
GPU-Accelerated Clusters (Private AI)
VCF 9.x heavily optimizes for advanced workloads. When you provision a cluster designated for Private AI Services, the deployment engine automatically configures explicit host rules, driver baselines, and advanced resource scheduling tailored for physical NVIDIA GPU hardware. This gives your data science teams turn-key infrastructure pools to spin up deep learning models or vector databases without manually tweaking host configurations.
Network Pools: The Automated Fabric
The true magic of VCF architecture is that it completely removes the manual labor of calculating host networking. This is driven entirely by Network Pools.
Before you scale out a cluster or add a new domain, you pre-define a Network Pool inside your management configuration plane. This pool acts as an IP Address Management (IPAM) sheet containing dedicated IP address scopes for your core infrastructure vmknics:
- vMotion Traffic: For live migrations between physical hosts.
- vSAN Traffic: For synchronized storage replication across the local disk arrays.
- Geneve TEP (Tunnel Endpoints): The critical overlay transport network that lets NSX run software-defined routing and distributed firewalls across standard physical switches.
When you add a host to a domain, VCF automatically pulls free IP addresses from this pool, creates the Distributed Switches, binds the physical uplinks, and configures the vmkernel adapters. There is no manual IP mapping, zero typing mistakes, and absolute consistency across thousands of server blades.
The Bottom Line
VCF 9.x architecture replaces custom, hand-built virtualization layouts with a standardized, hyper-scaled logical hierarchy. By isolating operational infrastructure inside a 4-host Management Domain and orchestrating applications via isolated Workload Domains, the platform ensures complete operational stability. Network Pools and VCF Fleets handle the underlying integration, turning physical bare metal into a fluid private cloud.
Next up in Part 5, we turn our attention to the physical layer: Hardware Requirements and the Bill of Materials (BOM), mapping out exact CPU, memory, and storage layouts to ensure your cluster clears the production readiness bar.