Welcome to part 2 of the VCF-9.1 home lab series. The previous post in this series discussed the platform capabilities. In this post, I will talk about the VCF 9.1 architecture.

Understanding the architectural building blocks before you provision anything is the difference between a learning environment and a misconfigured platform you’ll rebuild three times.

The Fleet Model

VCF 9.x introduces the concept of a Fleet as the top-level organizational construct. A Fleet is managed by a common instance of VCF Operations and VCF Automation. Within a fleet, you can have one or more VCF instances, each containing one management domain and zero or more workload domains.

For a home lab, your fleet is a single-region, single-instance deployment. But architecting it with fleet semantics in mind—proper naming conventions, network segmentation, and IP allocation strategies—prepares you for realistic multi-instance designs. To learn more about the deployment topologies in VCF 9, see my previous blog here.

Management Domain vs. Workload Domain

This distinction is foundational and still the source of the most common architectural mistakes in VCF deployments.

The management domain is created first, via the VCF installer. It hosts:

• SDDC Manager (transitioning to VCF Operations in future releases).
• vCenter Server for the management cluster.
• NSX cluster (mandatory — NSX is the platform fabric, not optional).
• VCF Operations and VCF Automation components.
• Optionally: NSX edge clusters for north-south management traffic.

Critical design constraint: The management domain exists to host the platform’s control plane. Production workloads do not run here. In home lab contexts, architects often collapse everything into the management domain to save resources, which is understandable, but it means you’re not practicing the isolation patterns you’d apply in production.

Workload Domains are the deployable units of capacity for actual application workloads. Each workload domain gets:

• It’s own vCenter Server instance.
• Its own NSX Manager instance (or shared with other workload domains).
• One or more vSphere clusters with ESX hosts.
• Its own storage configuration.

The domain boundary is the isolation boundary. Separating workload domains for different business units, compliance zones, or application tiers is the production pattern.

Standard Architecture vs. Consolidated Architecture

VCF supports two deployment topologies that are particularly relevant for the home lab context:

• Standard architecture deploys management and workload domains as separate entities. The management cluster is dedicated to infrastructure components; workload clusters are dedicated to business workloads. This requires more physical hosts but provides true isolation.
• Consolidated architecture collapses the management domain and the workload domain into a single cluster, using vSphere resource pools for isolation between infrastructure and business workloads. This is the right starting point for resource-constrained lab environments and for customers who want to start small and scale out. The VCF installer supports this deployment path natively.

Home lab recommendation: Start with a consolidated architecture to validate your understanding of the platform end-to-end. Then, if hardware allows, deploy a second physical cluster as a dedicated workload domain. This teaches you the workload domain commissioning workflow—one of the most architecturally significant operational procedures in VCF.

Networking Design

NSX is mandatory in VCF 9.x. Even if you have no intention of using overlay networking on day one, NSX underpins VCF’s management plane connectivity, vSphere Kubernetes Service, VPC networking, and Identity Broker integration. The management domain deploys with NSX as part of the bring-up process.

For the home lab, the minimum NSX design is:

• NSX Manager cluster (3 nodes for HA or a single node for lab).
• Host TEP (Tunnel Endpoint) VLANs for the overlay transport zone.
• An Edge cluster for north-south routing if you’re enabling VKS or VPC networking.

The new Virtual Private Cloud (VPC) model in VCF 9.x is worth familiarizing yourself with in the lab. VPCs integrate into vCenter, meaning vSphere administrators can create isolated networks without directly interacting with NSX. For architects, this is a meaningful shift in the operator model — your NSX design needs to anticipate self-service VPC provisioning patterns.

Storage: vSAN ESA vs. OSA

For new VCF 9.1 deployments, vSAN Express Storage Architecture (ESA) is the recommended path. ESA replaces the legacy OSA (Original Storage Architecture) with a redesigned storage stack that removes the disk group construct, delivers better performance on NVMe hardware, and enables features like NVMe memory tiering, global deduplication, and NVMe dispersed namespaces for stretch clustering.

vSAN ESA requires NVMe disks — not SATA SSDs. If your lab only has SATA/SAS SSDs, you’ll deploy vSAN OSA. This is a material difference to call out: if you’re building a home lab to practice designs you’ll recommend to customers adopting 9.1 on modern hardware, prioritize NVMe.

The minimum vSAN ESA configuration is 4 NVMe devices per host (1 for boot + 3 for vSAN). Capacity disks can also serve as caching in ESA—there’s no separate cache tier disk group as in OSA.

Physical vs. Nested Deployment

Home lab VCF deployments fall into two physical configurations:

• Nested (single physical host): Deploy VCF Installer, ESX, vCenter, NSX, and SDDC Manager as VMs on a single physical ESXi host. The total resource requirement is approximately 48 vCPUs, 194 GB RAM, and 3.2 TB storage. The critical hardware constraint is VCF Automation (VCFA), which requires a 24 vCPU VM—meaning your physical host needs at least 12 cores / 24 threads. Nested is excellent for understanding the software architecture and deployment workflows, but NVMe tiering and vSAN ESA behave differently (or not at all) in nested configurations.
• Physical: A minimum of 4 physical hosts running ESX. This is where hardware-level features like NVMe Memory Tiering, Live Patching, QAT offload, and realistic vSAN performance can be tested. The Minisforum MS-A2 has emerged as a popular community choice for physical VCF home labs—it ships with enough RAM and NVMe slots to support a realistic configuration at a manageable price point.

For this blog series, I am using 4 physical nodes for the management domain and 4 for the workload domain. I will cover the hardware specs in a later post.

Best Practices for VCF 9.1 Home Lab Deployments

These practices reflect production architectural patterns adapted for the lab context. They’re worth applying even when corners could be cut—because the point of the lab is to build the muscle memory of doing things right.

1. Plan Your IP Space and DNS Before Day Zero

The VCF Installer is unforgiving about DNS. Every component—SDDC Manager, vCenter, NSX Managers, etc.—requires forward and reverse DNS resolution before bring-up. Build your DNS zone structure first. Use a dedicated DNS/NTP server (a lightweight Linux VM or a mini-PC running dnsmasq works well) that is independent of the VCF management domain.

IP allocation recommendation for the lab: use a /24 per functional zone (management, vMotion, vSAN/storage, and workload). Document your IPAM before you touch the installer.

2. Use Separate VLANs Even in a Flat Lab Network

Even if your lab switch is a consumer-grade managed switch, configure separate VLANs for management, vMotion, vSAN, and NSX TEP traffic. This mirrors the physical network segmentation you’d design for production, and it teaches you the VDS port group configuration patterns that VCF’s bring-up wizard expects. For nested labs, VYOS is a great software that provides VLANs, BGP, DHCP, etc.

3. Choose Your Architecture Before You Click Deploy

Decide between standard and consolidated architecture before starting the VCF Installer. The installer will commit you to a topology, and retrofitting it later is painful. For most architects starting, consolidated architecture with a plan to add a workload domain is the right call—it gives you a complete, functional platform with minimal host count, and adding the first workload domain is one of the most valuable learning exercises in the platform.

4. Size the Management Domain to Run Automation

If you intend to deploy VCF Automation (VCFA), size your management cluster hosts to support it from day one. VCFA requires a 24 vCPU VM. For nested deployments, your physical host must have at least 12 cores / 24 threads. For physical deployments, your management cluster hosts need sufficient headroom. Deploying VCFA is optional for initial bring-up, but the platform’s self-service IaaS and namespace automation capabilities are not meaningfully accessible without it.

5. Enable vSAN ESA if your hardware supports it.

If you have NVMe disks in your lab hosts, deploy vSAN ESA. The experience of working with ESA—its disk claim workflow, its performance characteristics, its deduplication model, and its integration with NVMe tiering—is substantively different from OSA, and ESA is the forward direction of the platform. Do not default to OSA for familiarity if your hardware supports ESA.

6. Deploy NSX with the End State in Mind

Even if you don’t plan to use overlay networking on day one, the installer configures NSX transport zones and host TEPs during bring-up. The edge cluster is deployed as a day-1 activity. Pre-create your Tier-0 router in the lab—even if it’s not connected to anything meaningful—so you practice the topology that VKS and VPC networking will assume is present.

7. Practice Lifecycle Management, Not Just Deployment

The VCF Installer is one workflow. The lifecycle management workflow—upgrading SDDC Manager, vCenter, ESX, NSX, and VCF components in the correct sequence—is a separate skill and one that matters more in production. Once your lab is stable, use it to practice the upgrade workflow. Understanding the dependency chain (SDDC Manager first, then vCenter, then ESX, then NSX) and the bundle download process is knowledge that directly reduces change management risk in production.

8. Use the VCF Fleet API from Day One

VCF 9.x surfaces a comprehensive REST API through SDDC Manager and VCF Operations. Practice using it from the beginning — for host commissioning, workload domain deployment, certificate management, and lifecycle operations. The UI is useful for learning the platform’s conceptual model, but production operations teams operate through the API and automation pipelines. Familiarity with the API also makes you a more effective reviewer of infrastructure-as-code implementations.

9. Document Your Lab As If It Were Production

Maintain a simple design document — even a markdown file in a git repo — that records your IP allocations, VLAN assignments, hardware configuration, component versions, and architectural decisions. This practice has two benefits: it forces you to articulate your design choices (which reveals gaps), and it gives you a recovery runbook when (not if) something in the lab breaks.

10. License Within 90 Days (Or Plan Your Rebuild Window)

VCF 9.x deploys in evaluation mode and is fully functional for 90 days. If you’re building a long-lived lab, plan for licensing or a rebuild before the evaluation window expires. The VCF Operations will guide you through the Broadcom Business Services Console licensing flow.

And that’s it for this post. In the next post of this series, I will discuss the hardware and networking requirements!!!

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing.