Posts

Introduction Every workload domain you’ll ever stand up in VCF inherits whatever the physical network underneath it can actually deliver. By the time you’re in the workload domain creation wizard picking a VDS profile, the rack layout, the ToR trunk configuration, and the MTU on every switch port in between have already decided how much of that wizard’s promise you can keep. This post works bottom-up: what the physical fabric needs to provide, how vSphere Distributed Switches carve that fabric into traffic types, and how NSX Edge nodes hand off to it over BGP. ...

Introduction Every VCF Instance starts with a management domain – it’s the first workload domain deployed, and it never stops being special. This post breaks down exactly what components live inside a management domain per Broadcom’s official documentation, why the very first one in a fleet carries extra weight, and the shared-vs-dedicated NSX tradeoff that shows up in almost every design conversation. What Every VCF Domain Contains Per the VCF Taxonomy documentation, any VCF domain – management or workload – is built from the same base components: one vCenter instance, one or more vSphere clusters with vSphere HA and DRS enabled, at least one vSphere Distributed Switch per cluster plus NSX segments for workload traffic, a dedicated or shared NSX Manager instance, optional NSX Edge or Virtual Network Appliance clusters added after domain creation, and one or more shared storage allocations. ...

Introduction Once you’ve internalized “one Fleet across every site,” the next question is practical: how do you actually design that fleet across a headquarters site, a DR site, and edge or sovereign-cloud locations? This post breaks down the core VCF Instance/Fleet constructs and the four fleet deployment designs Broadcom documents for VCF 9.1, and maps them to the multi-site patterns operators actually build. The Three Constructs, Revisited Broadcom’s VCF Taxonomy defines three nested constructs worth keeping straight: ...

Introduction Managing the lifecycle of a VMware Cloud Foundation environment has historically required coordinated upgrades across multiple products, ESX, vCenter, NSX, and vSAN, with complex compatibility matrices and manual orchestration. VCF 9 changes this experience by moving lifecycle management into VCF Operations: the SDDC Manager UI is deprecated, and its LCM workflows now live in VCF Operations Fleet Management, giving you a single place to plan and orchestrate upgrades across every domain. ...

Introduction vSAN Express Storage Architecture (ESA) is the recommended storage architecture for all new VMware Cloud Foundation 9 deployments. ESA represents a ground-up redesign of the vSAN storage stack, purpose-built to exploit the performance characteristics of modern NVMe flash media. In this post, we explore the vSAN ESA architecture, design decisions, VCF 9.1’s new Auto-RAID capability, and best practices for storage policy design. Architectural Overview The diagram below illustrates the vSAN ESA architecture in a VCF 9 environment, from the NVMe hardware layer through the vSAN data path and management plane: ...

Introduction One of the most impactful networking changes in VCF 9 is the introduction of Virtual Private Cloud (VPC) networking as the primary multi-tenancy model in NSX 9.0. VPCs replace the manual overlay segment and Tier-1 gateway model of previous VCF releases with a cloud-native, self-service networking abstraction that aligns with industry standards. In this post, we dive deep into the VCF 9 VPC architecture, Transit Gateway design patterns, and how application teams can consume VPC-based networking from vCenter, VCF Automation, and vSphere Supervisor. ...

Introduction With the VCF 9 management domain up and running, the next step in your private cloud journey is creating workload domains. A workload domain groups ESX hosts under a dedicated vCenter instance, along with NSX networking and storage, so it can host tenant or departmental workloads. Depending on how you configure NSX connectivity during creation, a workload domain can become VPC-ready either immediately or after a short follow-up step: more on that below. ...

Introduction VMware Cloud Foundation 9 collapses what used to be three separate consoles into one control plane. If you’re coming from a 5.x background, this is arguably the single biggest mental model shift in the release: you stop thinking “one SDDC Manager per site” and start thinking “one Fleet across every site.” This post breaks down what Fleet actually is, which components feed into it, and how the pieces map to Broadcom’s official architecture documentation. ...

Introduction Deploying VMware Cloud Foundation 9 is a structured process that, when followed correctly, results in a fully configured SDDC in a matter of hours. This guide walks through the complete deployment flow from planning through a functional management domain. Note: VCF 9 replaces the Cloud Builder appliance used in VCF 5.x with the new VCF Installer: a new virtual appliance downloaded from the Broadcom Support portal that provides automated deployment and configuration workflows for the VCF environment. Unlike Cloud Builder which was a single-purpose OVA, the VCF Installer also supports VCF Converge (bringing existing vSphere infrastructure into VCF) and downloading/staging all required VCF component binaries. ...

Overview VMware Cloud Foundation 9 (VCF 9) represents a significant evolution in how Broadcom delivers its software-defined data center stack. Released on June 17, 2025, VCF 9 unifies ESX 9.0, vCenter 9.0, NSX 9.0, and vSAN under a single platform version. In this post, we explore the core architectural changes that differentiate VCF 9 from its predecessors and understand why these changes matter for enterprise deployments. VCF 9 Architecture Overview The diagram below shows the high-level architecture of a VCF 9 environment, spanning the management domain and workload domains with all core components: ...