VCenter

Introduction Every VI workload domain you stand up in VCF asks the same networking question: does it join an existing NSX Manager, or get its own? The Networking page of the workload domain creation wizard boils this down to two buttons – “Join Existing NSX Manager Instance” and “Create New NSX Manager Instance” – but the operational consequences run much deeper than a single click. This is a per-domain decision, not a fleet-wide one, and a VCF instance scaling toward its 25-domain ceiling will likely end up with a mix of both. ...

Introduction Every VI workload domain in a VCF instance got there one of two ways: it was built from scratch through the workload domain wizard, or it was an existing vCenter environment that VCF Operations absorbed as-is. These aren’t just two UI paths to the same result – they carry different prerequisites, different day-one side effects, and different long-term upgrade constraints. Picking the wrong one for your situation doesn’t just cost time in the wizard; it can lock a workload domain out of upgrade paths for its entire lifecycle. ...

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. ...