VCF Evolution: Version History & Migration Paths (2.x → 9.0)

VCF Evolution: Detailed Version Map and Paradigm Shifts#

Complete VCF Version Timeline (2.0 to 9.0.2)

VCF 2.x ERA (2016-2017) — Foundation

• 2.0 (2016): Initial VCF release, vSphere + NSX-V + vSAN bundled
• Features: VI Workload Domain, Management Cluster, NSX-V DFW
• vSphere: 6.0+, NSX: 6.2+, vSAN: 6.1+
• Known issue: LCM not available (manual cluster deployment)
• 2.1-2.3: Minor updates, incremental features, NSX-V focus

VCF 3.x ERA (2017-2019) — Modernization

3.0 (2017): Major: LCM (Lifecycle Manager), Cloud Builder, NSX-T preview

Features: Declarative infrastructure, automated provisioning

vSphere: 6.5, NSX-T 2.0 preview (not production)

3.5, 3.7, 3.8, 3.9, 3.10: Incremental NSX-T improvements, vSphere 6.7 support
Deprecation: vCloud Director 9.x sunset planning

VCF 4.x ERA (2019-2021) — NSX-T Integration

4.0 (2019): NSX-T MANDATORY (NSX-V sunset begins)

• Features: Native NSX-T integration, Federation preview, vSAN 6.7 max
• vSphere: 6.7U3+, NSX-T 2.4+, vSAN: 6.7
• 4.1-4.5: vSphere 7.0 support, Federation GA, workload management (VKS) preview
• Deprecation: NSX-V end-of-support (extend ESXi x86 support only)

VCF 5.x ERA (2021-2023) — Aria Integration

5.0 (2021): Aria Operations integration, HCX bundled

• Features: Automated compliance templates, Aria Ops multi-cloud
• vSphere: 7.0+, NSX-T 3.0+, vSAN: 7.0
• 5.1, 5.2: vSphere 7 latest updates, Aria Ops for Logs integration
• Known issue: Some customers report Aria Ops over-collection (high CPU)
• Deprecation: vSAN 6.x end-of-support

VCF 9.0 ERA (2024+) — Massive Refactor

9.0 (2024): Major architectural changes, unified operations

• Features: VCF Operations (consolidated Aria+Ops+Logs+Networks+Automation),
• Fleet Manager (global multi-instance management), vSphere+ preview
• vSphere: 8.0+, NSX: 4.1+, vSAN: 8.0+
• Breaking changes: SDDC Manager deprecated (automation via VCF Ops),
• credential management via VCF Ops (not vCenter)
• 9.0.1, 9.0.2 (2024-2025): Bug fixes, refinements

Upgrade Compatibility Matrix:

  2.x -> 3.x: Direct upgrade supported
  3.x -> 4.0: Direct upgrade supported (NSX-V -> T migration separate)
  4.x -> 5.x: Direct upgrade supported
  5.x -> 9.0: Requires 5.2+ as jumping-off point (can't skip 6/7/8)
  Note: No skip-version upgrades allowed (2.x -> 5.x not supported)
Paradigm Shifts Timeline
Key evolution moments that changed VCF architecture:
NSX-V to NSX-T Migration (VCF 4.0, 2019)

• Shift from distributed routing (NSX-V DLR, edge VMs) to centralized routing (NSX-T Tier-0/1, edge VMs or bare-metal). API model changed (REST-first vs vSphere-centric). Tooling: migration tools provided for 18-month window, then NSX-V de-supported. Impact: existing scripts broke (API changes), required re-training.

VCF on External vSphere (vSphere+ Era, VCF 4.x)

Early VCF tightly coupled to vSphere cluster (vCenter managed VCF). Later: ability to deploy VCF on pre-existing vSphere cluster (external vSphere). Decoupling: VCF management cluster no longer required on same cluster as workloads (allows brownfield deployments). Game-changer for existing vSphere shops (adopt VCF incrementally).

HCX Bundled into VCF (VCF 4.x)

HCX was separate appliance (cost, deployment overhead). VCX 4.0+: HCX functionality built into VCF (no separate license, included in VCF cost). Implication: cloud-to-cloud migrations simplified (vMotion-like experience for cross-cloud moves). Shift: cloud-agnostic infrastructure.

Workload Management / VKS Introduction (VCF 4.0+)

Kubernetes adoption trend required VCF support. Solution: Workload Management (WM) = Supervisor + TKG. Paradigm shift: VCF now serves both VMs and containers (unified platform). Implication: ops teams must learn Kubernetes (significant skill ramp).

VMware Identity Services Consolidation (VCF 5.x)

Multiple identity backends (vCenter SSO, external LDAP, Okta separate integrations). VCF 5.x: unified identity model (vSphere SSO as source of truth, federation with Okta/Azure AD). Implication: simpler credential management, fewer identity sources to audit.

VCF 9.0 Unified Operations and SDDC Manager Deprecation (2024)

SDDC Manager (day-2 operations tool) deprecated. VCF 9.0: operations consolidated into VCF Operations (formerly Aria Ops + Logs + Networks). Implication: learning curve for existing SDDC Manager users (API changes, workflow changes). Advantage: single pane of glass, fewer tools, simplified licensing.

Licensing and Commercial Evolution

VMware commercial model evolved significantly:

Pre-Broadcom: Socket-based Licensing

vSphere/vSAN licensed per socket (CPU socket). Example: 2-socket host = 1 license per socket minimum. Implication: high CPU count servers more expensive per-socket. Enterprise negotiated volume discounts (socket count unknown upfront).

Core-Based Licensing (Pre-2024)

Shift from socket to core count (CPU core licensing). More granular (small servers cheaper, large servers justified cost). Implication: licensing dept happy (cost aligns with actual compute).

Broadcom Subscription Model (2024+)

Broadcom acquisition completed; shift to per-core annual subscription model. VCF 9.0+ enforces subscription licensing (no perpetual option). Cost structure: annual renewal, per-core pricing (based on vSAN + vSphere + NSX cores). Implication: CapEx -> OpEx model shift, licensing now tied to support/updates.

Key Takeaways

• VCF has no skip-version upgrades: 5.2 is the mandatory stepping stone to 9.0 (cannot jump 6/7/8)
• NSX-V to NSX-T migration (VCF 4.0) was the largest architectural shift, requiring API retraining and script rewrites
• SDDC Manager deprecated in VCF 9.0; all day-2 operations move to VCF Operations (consolidation of Aria + Logs + Networks)
• Licensing evolved from socket-based → core-based → Broadcom subscription; VCF 9.0 enforces subscription-only (no perpetual option)
• VCF 5.2 is the stable, production-ready release before the massive 9.0 refactor; many enterprises maintain 5.2 until 9.0 is proven stable

Upgrade Path Planning: 5.2.x to 9.0.x#

Strategic Planning for 5.2 → 9.0 Migrations

Pre-Upgrade Checks and Compatibility Validation

1. Compatibility Matrix Validation

• Check supported combinations: vSphere 8.0+ required for VCF 9.0
• NSX version: must be 4.1+ (check current NSX-T version, plan migration if on 3.x)
• vSAN version: must be 8.0+ (upgrade vSAN first if on 7.0 or lower)
• Verify SDDC Manager end-of-support date (it's deprecated but still operational in 9.0 during transition)

2. HCL (Hardware Compatibility List) Validation

• CPU minimum: verify all ESXi hosts meet VCF 9.0 CPU requirements (generally Haswell-era or newer)
• Disk space: VCF 9.0 components require more storage (VCF Operations, Fleet Manager consume more space)
• Network requirements: NSX 4.1 requires higher bandwidth for telemetry (Broadcom's expanded observability)
• Storage HCL: if using vSAN, verify SSD models are on 9.0 HCL (some older models deprecated)

3. Backup and Rollback Strategy

• Snapshot all management cluster VMs (SDDC Manager, vCenter, NSX, vSAN) before upgrade begins
• Export SDDC Manager backup (Settings > Backup & Restore) — essential for rollback
• Backup vCenter database (FCLI backup or native vCenter backup)
• Backup NSX-T config (NSX System > Backup & Restore)
• Document current vSAN cluster config, cluster UUID, witness node (if stretched cluster)
• Test restore procedure in pre-prod if available (many customers skip this, then regret during actual failures)

Upgrade Sequence (Mandatory Order)

The VCF 9.0 upgrade sequence is RIGID — out-of-order upgrades will fail with cryptic errors.

1. SDDC Manager (First)

• Download VCF 9.0 SDDC Manager patch bundle
• Stop workload domain operations (pause NSX HA, pause vSAN rebalance)
• Upgrade SDDC Manager in place (single-node or HA cluster) — typically 30-45 min
• Validate SDDC Manager is running, can reach vCenter and NSX
• Check SDDC Manager logs for errors (often hidden in UI)
• Do NOT upgrade vCenter until SDDC Manager is stable. ORDER (VCF 5.2): SDDC Manager + VCF services -> Aria Suite Lifecycle -> NSX -> vCenter -> ESXi. NSX precedes vCenter. In VCF 9.0 (KB 390634) the fleet layer goes first: VCF Operations -> ... -> SDDC Manager -> NSX -> vCenter -> Supervisor -> ESXi (at least 10 min validation)

2. vCenter (Second)

   — vCenter 8.0 Update X → 8.0 Update Y (9.0-compatible version)

• Upgrade using native vCenter upgrade (not LCM — LCM is deprecated)
• Typical duration: 45-60 min
• Validate vCenter is responding, all plugins loaded (vSAN, NSX)
• Check SSL certificates haven't auto-expired during upgrade (common gotcha)

3. NSX-T (Third)

   — NSX 3.x → 4.1.x (check latest 4.1 release for 9.0 support)

• Upgrade Manager nodes, then Controller nodes, then Edge nodes
• Manager upgrade: 30-45 min, Controllers: 15-20 min each, Edges: 10-15 min each
• Validate each tier has quorum before proceeding to next
• Check NSX plugin in vCenter after Edge upgrade

4. ESXi Hosts (Fourth)

• Upgrade hosts in rolling fashion (one per vMotion batch)
• Evacuate workload VMs from host, upgrade, validate NSX agent, re-populate
• Duration: 5-10 min per host (depends on evacuation time)
• Validate host compliance in SDDC Manager, NSX reporting

Common Upgrade Failures and Mitigations

1. SSL Certificate Expiry

Problem: During vCenter upgrade, auto-signed or issued SSL certs can expire mid-process, causing upgrade to hang.

Mitigation: Pre-upgrade, check all certificate expiration dates (vCenter, NSX Manager, ESXi, SDDC Manager). Renew any expiring within 6 months. Use FCLI to validate cert chain.

Recovery: If upgrade fails due to cert, manually refresh cert on halted system, then retry upgrade.

2. NTP Drift

Problem: If management cluster time drift >30 sec during upgrade, NSX Manager and vCenter can't communicate, causing timeout failures.

Mitigation: Pre-upgrade, validate all management cluster VMs and ESXi hosts are synchronized to within 100ms. Check SDDC Manager NTP sync status (vCenter Settings > Date & Time).

Recovery: Stop upgrade, sync time (chronyc force-step or similar), then retry.

3. Insufficient Disk Space

Problem: VCF 9.0 components (Fleet Manager, expanded VCF Ops) require more disk; SDDC Manager scratch partition can fill during upgrade, causing rollback.

Mitigation: Pre-upgrade, verify free space on all management cluster disks: SDDC Manager (/root and /var min 50GB free), vCenter (/storage/core min 100GB free), NSX Manager (/var min 30GB free).

Recovery: Extend disks (if hypervisor allows), clear logs/temp, retry upgrade.

4. Workload Domain Instability During Upgrade

Problem: If workload domain VMs are still running heavy workloads during SDDC Manager upgrade, NSX-T upgrade can trigger unexpected vMotion, overloading network.

Mitigation: Pre-upgrade, pause or drain workloads from workload domains. Disable vSAN rebalance, pause HA monitoring during NSX upgrade.

Recovery: Re-enable HA monitoring, let vMotion complete naturally; manually migrate stuck VMs if needed.

5. NSX Edge Gateway Failure

Problem: During NSX Edge upgrade, if edge is single-node (not HA), north-south traffic drops, causing tenant workload outages.

Mitigation: Pre-upgrade, validate all edges are in HA mode (2+ edge nodes per edge gateway). Plan upgrade during maintenance window. Pre-position backup edges if single-node edges exist.

Recovery: Manually trigger failover to standby edge, complete upgrade, validate traffic flow.

Rollback Procedures

Rollback is only possible if you stopped BEFORE NSX/ESXi upgrade (i.e., rollback is vCenter/SDDC Manager only, not full stack).

1. If SDDC Manager upgrade failed (pre-vCenter)

• Restore SDDC Manager VM from pre-upgrade snapshot
• Verify vCenter and NSX are still on previous version (they should be)
• Re-run SDDC Manager upgrade after troubleshooting root cause

2. If vCenter upgrade failed (pre-NSX)

• Restore vCenter VM from pre-upgrade snapshot
• Verify SDDC Manager is still connected (may need credential refresh)
• Investigate vCenter upgrade logs, retry

3. If NSX upgrade failed (pre-ESXi)

• NSX upgrade is atomic per-tier; if Manager upgrade succeeded but Controller failed, stop Controller upgrade
• Restore NSX Manager from backup (FCLI backup, or native NSX backup)
• Investigate NSX Manager logs, retry after fix

4. If ESXi Host upgrade failed

• Host stays in upgrade mode; reboot host to roll back ESXi
• VMs will reboot; expect 5-10 min downtime
• Once host is back to previous ESXi version, investigate cause, retry

5. If you've already upgraded NSX and ESXi

• Full rollback is NOT supported; you must live-migrate back (expensive, risky)
• Instead: forward-migrate, fix the issue, then upgrade again

VCF Lifecycle Manager (LCM) Deprecation Note

In VCF 5.2, LCM is the tool for upgrades (SDDC Manager, vCenter, NSX, ESXi). In VCF 9.0, LCM is DEPRECATED and replaced by:

• Interop Matrix: reference tool (no longer enforces order)
• Manual upgrade procedure: each component has native upgrade process
• VCF Operations Upgrade Advisor: new tool to validate readiness (still preview in early 9.0 releases)

Implications:

• Admins upgrading from 5.2 must learn new manual processes (no "upgrade all" button)
• Each component requires manual validation between steps
• More error-prone, requires discipline and documentation

Key Takeaways

• Upgrade sequence is RIGID: SDDC Manager → vCenter → NSX → ESXi; out-of-order upgrades fail with cryptic errors
• Pre-upgrade checklist is critical: SSL certs, NTP sync, disk space validation prevent 80% of failures
• SSL certificate expiry and NTP drift are the top 2 silent killers; validate both before starting upgrade
• Rollback is only possible before NSX/ESXi upgrade; once those start, you're committed to forward-migration
• LCM is deprecated in VCF 9.0; admins must switch to manual upgrade procedures, validating each tier before proceeding

Brownfield VCF Adoption: Converting Existing vSphere to VCF#

Real-World Path: Adopting VCF on Existing vSphere Clusters

Why Brownfield Adoption Matters

Most enterprises don't build VCF from scratch (greenfield). Instead, they have:

• Existing vSphere clusters (vSphere 7.0+)
• NSX-T already deployed (or NSX-V requiring migration)
• vSAN clusters or external storage (SAN, NFS)
• Legacy workloads that can't be disrupted

VCF Import Tool enables adoption without rip-and-replace. This section covers:

• Requirements to convert standalone vSphere cluster to VCF-managed cluster
• Networking prerequisites and NSX deployment considerations
• Storage implications (vSAN vs external)
• Licensing conversion from perpetual to subscription

VCF Import Tool: Prerequisites and Process

1. Infrastructure Requirements

• Existing vSphere cluster: 3+ ESXi hosts (can be vSphere 7.0 or 8.0)
• vCenter: must be 7.0 Update 3+, preferably 8.0+ (for 9.0 adoption)
• Network isolation: cluster must be able to reach management network where SDDC Manager will be deployed
• Minimum storage: cluster must have at least 2TB free for VCF components (SDDC Manager, NSX, Aria Ops agents)
• Current cluster workloads: CAN remain during import (non-disruptive migration)

2. VCF Import Process (High Level)

Step 1: Deploy VCF management cluster on external infrastructure

Provision 3+ ESXi hosts (can be separate from workload cluster)

Install vCenter, NSX, vSAN (if desired)

Deploy SDDC Manager

Step 2: Validate connectivity between management and workload cluster

SDDC Manager must reach vCenter in workload cluster

NSX in management cluster must reach NSX in workload cluster (if pre-deployed)

Step 3: Run VCF Import tool

Tool runs from SDDC Manager UI

Scans existing cluster for compliance (checks vCenter version, NSX configuration, host count)

Validates licenses (perpetual vSphere/NSX licenses will be converted to subscription)

Step 4: Execute import

Tool creates new Workload Domain, registers existing cluster

Existing VMs remain running throughout import

Post-import, cluster operates under VCF governance (Aria Ops integration, NSX policies, vSAN dedup)

3. Non-Disruptive Import

• Workloads do NOT need to be powered off
• vCenter remains accessible during import
• Network connectivity is preserved (existing VM networks stay online)
• Duration: typically 30-60 min for import scanning and registration

Networking Prerequisites and NSX Deployment

1. NSX Requirement

• VCF requires NSX for network overlay (even for brownfield adoption)
• If workload cluster is running NSX-V: must migrate to NSX-T BEFORE or DURING VCF import
• If workload cluster has NO NSX: must deploy NSX-T first
• NSX-T must be 3.0+ for VCF 5.2, 4.1+ for VCF 9.0

2. NSX Deployment on Brownfield Cluster

Pre-requisites:

• 3+ ESXi hosts with at least 16GB RAM per host (NSX Controller needs memory)
• Dedicated management network segment (10.x.x.x or similar, isolated from workloads)
• VLANs or overlay for tenant networks (NSX Segments)

Deployment approach:

Option A: Deploy NSX Manager/Controller cluster on existing workload cluster

• Advantage: no extra hardware, existing hardware supports NSX
• Disadvantage: NSX agents run on same cluster (slight overhead)
• Risk: if NSX fails, workload cluster networking impacted

Option B: Deploy NSX on separate management cluster (best practice)

Advantage: NSX isolated, easier troubleshooting, management cluster failure doesn't impact workloads

Disadvantage: requires extra hardware

Recommended for production: 3 separate hosts for NSX Manager

3. Networking Planning

• Uplink networks: which physical NICs will carry NSX traffic? (usually dedicated or shared with management VLAN)
• Edge Gateway placement: where will edges run? (can be on workload cluster or separate)
• Underlay network: must be L2 contiguous for NSX Geneve VXLAN tunneling
• Overlay networks: plan Segment (logical switch) design for tenant workloads

Storage Considerations: vSAN vs External

1. vSAN-Based Brownfield Adoption (Recommended)

Scenario: Existing cluster uses vSAN; adopt VCF with vSAN as underlying storage

Requirements:

• vSAN cluster must be 6.7+ (for VCF 5.2) or 8.0+ (for VCF 9.0)
• All-Flash or Hybrid: either is supported (all-flash preferred for production)
• Minimum 4 hosts (3-host minimum for VCF, but vSAN prefers 4+)
• Replication factor: 2 or 3 (plan capacity accordingly)

Import process:

• VCF import recognizes existing vSAN cluster
• No re-initialization required (existing VMDK data preserved)
• vSAN policies automatically applied post-import
• Deduplication and compression enabled by default in VCF 9.0

Post-import:

• vSAN is now managed by VCF (capacity planning, policy updates via SDDC Manager)
• vSAN stretched cluster (2-site) is supported but adds complexity
• vSAN witness node for 2-node clusters: supported but rare in brownfield

2. External Storage-Based Adoption (vSAN, NFS, SAN)

Scenario: Existing cluster uses NFS/SAN; adopt VCF without vSAN

Requirements:

• NFS or SAN must be 9.0 HCL-compatible (check Broadcom HCL)
• If using iSCSI SAN: ensure multipath is configured correctly (VCF validation will check)
• Datastore size: min 500GB per datastore (larger preferred for production)
• Performance: ensure SAN/NFS latency <5ms (VCF workload domain assumes low-latency storage)

Import process:

• VCF import recognizes external storage datastore
• Existing VMs remain on datastore throughout import
• Post-import, VCF applies storage policies (replication, snapshots) via vSAN or vSphere native replication

Post-import:

• If external storage: vSAN is not enabled; storage is managed via vSphere native policies
• If you decide to migrate to vSAN later: can add vSAN hosts to cluster, then migrate data

Licensing Conversion: Perpetual to Subscription

1. Pre-Import Licensing State

• Existing vSphere licenses: likely perpetual (socket-based or core-based)
• Existing NSX licenses: likely perpetual
• vSAN licenses: likely perpetual or subscription
• Support contract: may be expired (VCF requires active support for subscription licensing)

2. VCF Licensing Model

VCF 9.0 enforces Broadcom subscription model:

• Per-core annual subscription (pricing varies by geography, volume)
• Includes vSphere, NSX, vSAN, Aria Ops, Aria Automation (if deployed)
• Support is bundled (no separate support contract)
• Renewal is automatic unless canceled

3. License Conversion Process

Pre-import:

• Broadcom licensing team validates perpetual license entitlements
• Conversion rate: perpetual licenses converted to 3 years of subscription (rough estimate, varies)
• Calculate cost: compare perpetual license value vs 3-year subscription
• Budget impact: if perpetual licenses are old, subscription may be more expensive (discuss with Broadcom)

During import:

• VCF import tool checks license status (perpetual vs subscription)
• If perpetual: generates conversion code for Broadcom licensing
• Workload domain is created with subscription licensing

Post-import:

• First year subscription begins (annual renewal date set)
• Monthly/quarterly reporting of core usage (Broadcom may invoice if cores increase)
• Can renew, upgrade, or downgrade at renewal date

4. License Considerations

• Core count: VCF subscription is per-core (across vSphere, NSX, vSAN); ensure you have enough for current + growth
• Hybrid licensing: if you have some perpetual hosts + some subscription, upgrade costs increase
• Grace period: none; licensing must be in place before import (tools won't start otherwise)
• Licensing audit: post-import, Broadcom may audit core usage; ensure accuracy

Brownfield Adoption Roadmap: Example Scenario

Company: Mid-size enterprise, 50 ESXi hosts across 3 vSphere clusters, vSAN-based storage

Month 1-2: Planning

Choose 1 pilot cluster (12 ESXi hosts) for VCF import

Validate cluster meets VCF 5.2 requirements (vSphere 7.0+, vSAN 7.0+)

Plan NSX-T deployment (will NSX be separate or on cluster?)

Engage Broadcom licensing to understand perpetual-to-subscription conversion

Month 3: Prepare

Deploy 3 new ESXi hosts for VCF management cluster (if not using existing cluster)

Deploy vCenter, SDDC Manager, NSX on management cluster

Deploy NSX on pilot workload cluster (if not already present)

Month 4: Import

Run VCF import tool on pilot cluster

Validate post-import: workloads running, Aria Ops agents reporting, NSX policies applied

Test vMotion, snapshots, policy-based management

Month 5-6: Validation and optimization

Monitor workload cluster performance (ensure NSX overhead acceptable)

Tune vSAN policies (replication, striping)

Validate licensing compliance

Month 7-12: Scale

Import remaining 2 clusters

Consolidate Federation (link clusters across sites for multi-cluster management)

Decommission older management infrastructure (if VCF on separate cluster)

Common Brownfield Adoption Challenges

1. NSX Migration (NSX-V to NSX-T)

Challenge: Existing NSX-V environment requires migration; migration tools have support limits
Solution: Plan 2-3 month migration window, use Broadcom migration services, test in pre-prod

2. IP Address Exhaustion

Challenge: Brownfield cluster was designed for vSphere; NSX adds management network, overlay networks
Solution: Pre-plan IP subnets, potentially use IPv6 for future overlay networks, validate IPAM capacity

3. Performance Overhead

Challenge: NSX agents on ESXi can consume 2-3% CPU/memory; some workloads notice this
Solution: Run performance baseline pre-import, post-import validation, tune NSX policies

4. Compliance and Security

Challenge: Existing cluster may have old security policies (ACLs); VCF requires NSX DFW policies
Solution: Migrate ACL rules to NSX DFW policies, use DFW templates for standardization

5. Licensing Audit

Challenge: Historical perpetual licenses may not match current host count; conversion can be expensive
Solution: Early licensing discussion with Broadcom, consider phased adoption (1 cluster per year)

Key Takeaways

• VCF Import Tool enables non-disruptive adoption of existing vSphere clusters; workloads remain running throughout migration
• NSX-T is mandatory for VCF; if cluster is NSX-V, migration must happen before or during VCF import
• vSAN-based brownfield adoption is preferred (existing data preserved, no re-initialization); external storage is also supported
• Broadcom subscription licensing is enforced in VCF 9.0; perpetual licenses convert to 3-year subscription (cost impact varies)
• IP address planning, NSX overhead profiling, and license audit are the top 3 planning items for brownfield adoption

VCF 5.2 Deep Dive: VCF 5.2 Architecture & Components#

VCF 5.2 Architecture & Components VCF 5.2

VMware Cloud Foundation 5.2 is the integrated SDDC platform that most enterprises run in production today. It unifies vSphere (ESXi + vCenter), vSAN, NSX, and the optional Aria Suite under a single lifecycle-managed control plane orchestrated by SDDC Manager. A VCF deployment is always created by the Cloud Builder appliance through a process called bring-up, after which Cloud Builder is powered off and SDDC Manager becomes the authoritative Day-N controller. This section documents every architectural role, component, and deployment option required for a VCDX-level understanding of VCF 5.2.

1. SDDC Manager — the central orchestrator

SDDC Manager is a 4 vCPU / 16 GB RAM / 908 GB Photon appliance that runs in the management domain and owns the following responsibilities:

• Inventory of truth: keeps the authoritative database of hosts, clusters, workload domains, NSX/vCenter instances, licenses, network pools, and credentials. Underlying store is PostgreSQL (platform DB) on the SDDC Manager appliance.
• Bring-up handoff: after Cloud Builder completes the first-run workflow, inventory and control move to SDDC Manager. Cloud Builder is then powered off.
• Workload-domain lifecycle: creates, expands, shrinks, renames and deletes VI workload domains (dedicated vCenter, optional dedicated or shared NSX Manager cluster, optional NSX Edge cluster).
• Host lifecycle: commissions ESXi hosts into an Unassigned Hosts pool, assigns them to clusters, and decommissions them back.
• Lifecycle Management (LCM): downloads install/upgrade/async-patch/flexible-BOM/independent-SDDC-Manager bundles from the online VMware Depot or an offline depot, stages them, runs upgrade prechecks, and drives the upgrade sequence in the required order.
• Certificate Management: integrates with Microsoft CA, OpenSSL, or any third-party CA to replace VMCA-issued certs on vCenter, NSX, Avi LB, SDDC Manager, and Aria Suite Lifecycle. ESXi certs are not managed by SDDC Manager.
• Password Management: rotates, updates, retries and manages passwords for vCenter root, NSX root/admin/audit, ESXi root, SDDC Manager local users, and Aria components.
• Backup & Restore: orchestrates file-based backups over SFTP (encrypted with a backup passphrase) and image-based snapshots; supports full or partial restore.
• Drift reconciliation: detects and applies Configuration Updates (FEATURE or FIX) from the Repository to keep component configs aligned with the current VCF BOM.
• REST API and PowerShell modules: exposes the VMware.VCF.* PowerShell modules and a full REST API at https:///v1/. Developer Center in the UI provides an API Explorer.
• SoS utility: /opt/vmware/sddc-support/sos runs health checks, collects support bundles, and performs log analysis.

` SSH login to SDDC Manager uses the vcf service account; root is kept for break-glass. Key paths: /opt/vmware/vcf/version.txt (current VCF version), /var/log/vmware/vcf/bringup/ (bring-up logs), /opt/vmware/vcf/operationsmanager/scripts/cli/sddcmanager_restart_services.sh` (safe service restart).

2. Cloud Builder appliance — the bring-up engine

Cloud Builder is a disposable 4 vCPU / 4 GB RAM / 279 GB (25.1 GB thin / 253.8 GB thick) Photon appliance whose only job is to stand up the first management cluster and hand it off to SDDC Manager.

• Deployment targets: can run on any ESXi host, VMware Workstation, or Fusion. It does not need to run on VCF hardware — only needs L3 reachability to the management VLAN, DNS, and NTP.
• Two input methods: the Excel Deployment Parameter Workbook uploaded through the UI at https://, OR a JSON payload through the API (JSON is required for custom CA-signed ESXi certificates).
• Validation: before bring-up Cloud Builder validates DNS forward and reverse lookups, NTP, VLAN reachability, MTU, ESXi fingerprints/thumbprints, vSAN HCL, license keys, and password complexity. Failures highlight the workbook cells in red.
• Bring-up deliverables: deploys four management ESXi hosts into a vSAN cluster, the management vCenter Server, a 3-node NSX Manager cluster, SDDC Manager, and optionally Aria Suite Lifecycle; creates the vSphere Distributed Switch per the vDS profile; configures licenses.
• Log path: /opt/vmware/bringup/logs/vcf-bringup-debug.log is the primary debug log; root logs live under /var/log/vmware/vcf/bringup/.
• After success: download the deployment report, click Finish, launch SDDC Manager, then power off the Cloud Builder VM. It is not part of Day-2 operations and must not be deleted — Broadcom requires it be kept for support but powered off.

3. vSphere — ESXi and vCenter Server

vSphere is the compute foundation. Every workload domain has exactly one dedicated vCenter Server appliance, and every vCenter runs in the management domain (never co-located with the workloads it manages, except for the management vCenter itself).

• vCenter HA in VCF: only vSphere HA is supported to protect vCenter. vCenter HA (active/passive/witness) and vSphere FT are NOT supported for VCF-managed vCenters.
• Tiny — 10 hosts / 100 VMs
• Small — 100 hosts / 1,000 VMs (default for management domain)
• Medium — 400 hosts / 4,000 VMs (default for VI workload domain)
• Large — 1,000 hosts / 10,000 VMs (16 vCPU / 39 GB)
• X-Large — 2,000 hosts / 35,000 VMs in vSphere 8.0; 2,500 hosts / 45,000 VMs in vSphere/VCF 9.0 (24 vCPU / 58 GB)
• ESXi: a host in a VCF-managed cluster has its certificate regenerated after hostname/FQDN is set, runs the vSphere Cluster Services VMs (vCLS), and is enrolled as an NSX host transport node when the cluster joins NSX.

4. vSAN — the default principal storage

• vSAN OSA (Original Storage Architecture) remains the default in VCF 5.2: each host contributes one flash cache device + one or more capacity devices, combined into disk groups. Minimum 2 disk groups per host, 600 GB minimum cache tier, 256 minimum storage controller queue depth, 32 GB host RAM to support the maximum number of disk groups. For hybrid configurations, cache tier must be at least 10% of capacity tier.
• vSAN ESA (Express Storage Architecture) is optional and requires vLCM images, NVMe TLC flash, hosts on the ESA ReadyNode HCL, and 25-GbE NICs + 512 GB RAM per host. vSAN ESA clusters cannot be stretched in VCF 5.2.
• vSAN Max is a disaggregated, storage-only cluster type (former name reused in VCF 9.0 as vSAN Storage). Provides a remote datastore to other vSAN ESA or vSAN Compute clusters. Minimum 4 hosts, max 24 hosts per vSAN Max cluster plus up to 104 compute clients (128 total).
• vSAN Compute Clusters — hosts with no local storage that mount a remote vSAN OSA/ESA/Max datastore from another cluster within the same workload domain.
• Free-space guardrail: keep at least 30% free on the vSAN datastore.

5. NSX — the network virtualization plane

• NSX Manager cluster = 3 nodes + 1 VIP (4 IPs total on the same L2). The management-domain NSX Manager is always dedicated; VI workload domains may share an NSX Manager cluster — up to 14 VI workload domains can share one NSX Manager cluster in the same SSO domain, or up to 16 isolated VI workload domains.
• NSX Manager sizes: Extra-Small (CSM only), Small (PoC), Medium — up to 128 hosts (default for management domain), Large — up to 1,024 hosts (default for VI workload domains), Extra-Large — up to 2,048 hosts. Non-default sizes in a VI WLD require the API.
• Small — PoC only
• Medium — L2–L4, < 2 Gbps (4 GB RAM, 2 vCPU, 200 GB)
• Large — L2–L4 + L7 LB, 2–10 Gbps (32 GB RAM, 8 vCPU, 200 GB)
• Extra-Large — multi-Gbps L7 LB/VPN (64 GB RAM, 16 vCPU, 200 GB)
• NSX Federation uses a manually-deployed Global Manager cluster (3 active + 3 standby) across VCF instances. Max 4 locations per cross-instance Tier-0; 4 with Medium GM, 16 with Large/XL GM. Required RTEP MTU: 1,500 minimum, 1,700 preferred, 9,000 recommended; max 500 ms latency (150 ms for workload mobility).
• Transport zones: one overlay TZ per NSX instance (shared across all clusters of that instance), plus one VLAN TZ for N–S and one for VLAN-backed segments.
• Routing: BGP is the required dynamic routing protocol. Keep-alive 4 s, hold-down ≤ 12 s.

6. The Aria Suite (formerly vRealize)

VCF 5.2 completes the vRealize → Aria rename that began in late 2022. The components deploy through VMware Aria Suite Lifecycle (formerly vRealize Suite Lifecycle Manager), itself driven by SDDC Manager. All Aria VMs live in the management domain.

Workspace ONE Access sizes range from Extra-Small (3,000 users) up to Extra-Extra-Large (100,000 users). A clustered deployment is always 3 nodes behind an NSX load-balancer VIP, requiring 5 IPs on the cross-instance segment. Storage per Workspace ONE Access node: 100 GB thin.

7. Management Domain vs. VI Workload Domain

Workload domains are the primary unit of consumption in VCF. A workload domain is a logical set of vSphere clusters managed by a dedicated vCenter Server, with optional NSX networking, provisioned by SDDC Manager.

8. Standard vs. Consolidated architecture

VCF 5.2 supports two architectural models. Standard is the VMware-recommended best practice and the starting point for every reference design.

Both models use the same bring-up path. A consolidated domain can be scaled up to a standard architecture later by adding a VI workload domain and migrating workloads off the management cluster.

9. Deployment options (VCF topologies)

• Single VCF instance, single AZ — baseline; up to 25 workload domains; vSphere HA protects against host failures.
• Single VCF instance, multiple AZs (stretched) — management domain must be stretched first before any VI workload-domain cluster can be stretched; up to 2 AZs; requires at least 10 Gbps between AZs and < 5 ms RTT; witness in a third location.
• Multiple VCF instances, single AZ each — typically paired with NSX Federation for unified policy across sites.
• Multiple VCF instances, multiple AZs per instance — maximum resilience; each instance is internally stretched and all instances are federated.

10. Component interaction at steady state (Day-2)

After bring-up, the control plane interacts as follows:

• SDDC Manager talks to each vCenter via its SSO credential; to NSX Manager via admin API; to ESXi only indirectly (via vCenter) for non-LCM operations; to Aria Suite Lifecycle via its API.
• Workload-domain vCenter Server instances are joined in an Enhanced Linked Mode (ELM) ring within a single SSO domain (up to 15 vCenters). Isolated workload domains have their own SSO.
• NSX Manager is the control plane for all transport nodes (ESXi + Edge VMs); NSX Global Manager (when Federation is used) writes global state that is replicated to each NSX Local Manager.
• Aria Operations, Aria Operations for Logs and Aria Operations for Networks collect telemetry from vCenter, NSX and Aria Automation; Aria Automation consumes vCenter/NSX/vSAN/Workspace ONE Access for self-service cloud.
• Workspace ONE Access is the identity broker for the Aria stack; vCenter SSO is the identity broker for vSphere/NSX/SDDC Manager. VCF 5.2 adds optional external IdP integration (one of: ADFS, Okta, or Microsoft Entra ID — only one at a time).

Reference documentation: VCF 5.2 Documentation Portal · VCF 5.2 Design Guide · VCF 5.2 Administration Guide · VMware Aria Suite TechDocs.

Version Comparison

Key Takeaways

• SDDC Manager is the Day-N controller (4 vCPU/16 GB/908 GB Photon appliance) with PostgreSQL as single source of truth
• Cloud Builder (4 vCPU/4 GB/279 GB) is disposable — powered off after bring-up, never deleted
• Each workload domain has exactly one dedicated vCenter; vCenter HA (active/passive/witness) is NOT supported in VCF
• NSX Manager cluster is 3 nodes minimum; shared across domains OR dedicated per domain
• vSAN is the ONLY supported storage for management domain boot/config; NFS/VMFS for workload domains

VCF 5.2 Deep Dive: Component BOM & Versions#

VCF 5.2 Component BOM & Versions VCF 5.2

A BOM (Bill of Materials) is the precise set of component versions that a specific VCF release certifies together. Every workload domain in a VCF instance tracks its current BOM state, and LCM enforces that in-place upgrades move the entire BOM atomically — with the exception of three 5.2-introduced features (Independent SDDC Manager Upgrade, Flexible BOM Upgrade, and Async Patch) that allow bounded deviations. This section documents the VCF 5.2 BOM, the hardware and network prerequisites that enforce it, and the specific minimums you must budget for a design.

Core VCF 5.2.x BOM (authoritative components)

The BOM evolves across 5.2 maintenance releases (5.2.0 → 5.2.1 → 5.2.1.1 → 5.2.1.2 → 5.2.2 …). Always confirm against the Broadcom Interoperability Matrix and the VCF 5.2 Release Notes before building a design. The table below reflects the baseline GA BOM family.

Hardware compatibility requirements (non-negotiable)

• Every ESXi host must be on the VMware Compatibility Guide and, for vSAN, on the vSAN ReadyNode HCL (use vSAN ESA ReadyNode HCL for ESA clusters).
• DPU-capable hosts (SmartNICs) require ESXi 8.0 U3 and UEFI boot.
• All hosts in a single management-domain default cluster must be homogeneous (VCF-ESX-RCMD-CFG-002).
• Boot device — high-endurance SSD, minimum 128 GB to maximise ESX-OS data space.
• Hyperthreading MUST NOT be counted when sizing CPU (VCF-ESX-RCMD-CFG-003). Size against physical cores only.
• TPM modules, if present, must run the latest 2.0 firmware. If present but unused, disable in BIOS (KB 312159).
• All hosts in a cluster must share the same DPU vendor when DPUs are used.

Minimum host specs

Supported storage types

Network requirements (MTU, VLANs, IP pools)

• VLAN range accepted: 0–4094 (validate against fabric).
• MTU range (Network Pool): 1,500–9,000. Default vDS is 9,000.
• MTU minimums: physical switches and vDS carrying overlay, vSAN or vMotion need 1,700 bytes minimum (Geneve + VXLAN headroom); 9,000 for jumbo frames.
• NSX Federation RTEP MTU: minimum 1,500, preferred 1,700, jumbo recommended 9,000.
• Host-to-ToR: 25-GbE or higher (10-GbE minimum); dedicated Edge clusters recommend 100-GbE per ToR.
• Stretched cluster: ≥10 Gbps between AZs, < 5 ms RTT.
• NSX Federation latency: ≤ 500 ms between instances (≤ 150 ms for Cross vCenter vMotion).
• Remote cluster (satellite) WAN: min bandwidth 10 Mbps, max latency 100 ms.
• No LAG/LACP/vPC/EtherChannel on ESXi host uplinks.
• BGP timers required: keep-alive 4 s; hold-down ≤ 12 s.
• VMkernel MTU defaults: management 1500, vMotion 9000, vSAN 9000, NFS 9000, Host TEP 9000.

VLANs and subnets you must plan

IP pool minimums to budget

• NSX Manager cluster — 4 IPs (3 nodes + VIP) per cluster.
• NSX Global Manager — 4 IPs per cluster × 2 (active + standby).
• Host TEP / Edge TEP — one IP per transport node per VLAN; use DHCP or static IP pool on the NSX Host Overlay VLAN.
• Stretched cluster — witness VM (vSAN Witness Appliance) at a third site.
• Workload Management (Tanzu) — pod subnet /22, service subnet /24, ingress /27, egress /27 minimums.
• Workspace ONE Access cluster — 5 IPs on the cross-instance segment (3 nodes + VIP + service).
• Temporary IP per vCenter upgrade from VCF 4.5.x source (and every 5.2.1 vCenter RDU upgrade) — can be reused across vCenters sequentially; parallel upgrades need additional IPs.

vSAN-specific numbers you will be asked about

Password-complexity reference for component accounts

Supported special characters: @ ! # $ % ? ^. Always disallowed: * { } [ ] ( ) / \\\\ ' " \ ~ , ; : .

Other limits to memorize

• Max hosts per vSphere cluster — 64.
• Max NSX Edge cluster size — 10 nodes (min 2).
• Active/Active Tier-0 max uplink nodes — 8; Active/Standby — 2.
• Max workload domains per VCF instance — 25.
• Max workload domains per single SSO domain (ELM) — 15 including the management domain.
• Max isolated VI workload domains per VCF instance — 24.
• Max convert/import domains — 24.
• WLD name — 3–20 chars, alphanumeric, no spaces.
• Delete WLD — up to 20 minutes; create WLD — up to ~5 hours.

Reference documentation: VCF 5.2 Design Guide · VCF 5.2 Deployment Guide · NSX 4.2 Documentation · vSAN 8.0 Documentation.

Key Takeaways

• VCF 5.2 BOM: ESXi 8.0U3, vCenter 8.0U3, NSX 4.2.x, vSAN 8.0U3
• Flexible BOM allows independent component updates within tested compatibility ranges
• Boot device minimum is 128 GB (SSD/NVMe recommended, no SD cards for production)
• 32 GB RAM minimum per ESXi host; 512 GB+ recommended for production workload domains

VCF 5.2 Deep Dive: VCF 5.2 Deployment & Day-0#

VCF 5.2 Deployment & Day-0 VCF 5.2

VCF bring-up is a one-time, highly-orchestrated process: fill the Deployment Parameter Workbook, upload it into Cloud Builder, and Cloud Builder deploys vCenter, NSX Manager, SDDC Manager, and (optionally) Aria Suite Lifecycle on four (or three, in 5.2.1+) prepared ESXi hosts, forming the management domain on a vSAN cluster. Once complete, SDDC Manager becomes the authoritative Day-N controller and Cloud Builder is powered off.

Planning prerequisites

• Use the official Planning and Preparation Workbook and Deployment Parameter Workbook from the Broadcom Support Portal.
• Rack and cable the four management ESXi hosts on leaf-spine (default) with 25-GbE or higher host-to-ToR links; disable LAG/LACP on all ESXi uplinks.
• Prepare DNS — forward and reverse records for: each ESXi host, Cloud Builder, SDDC Manager, vCenter, NSX Manager cluster (3 nodes + VIP = 4 records), Aria Suite Lifecycle (if bundled), and any Aria VMs.
• Configure NTP reachable from the management VLAN. Synchronise the Cloud Builder clock to the same source.
• Ensure external services are ready: AD / LDAP (for post-deploy IdP), syslog target, SFTP server for backups.
• Obtain licenses: VCF 5.2 uses traditional 25-character license keys (per-component: vSphere, vSAN, NSX, HCX, Aria, Workspace ONE Access). New vSphere 8.x / vSAN 8.x licenses are required when upgrading from older VCF versions.
• Determine FIPS-140-2 mode: optional, set at bring-up ONLY — cannot be changed afterward.
• Determine custom ESXi certificates: only JSON bring-up (not Excel) supports Custom ESXi certificate mode (securitySpec.esxiCertsMode=Custom, rootCaCerts).

## Complete deployment workflow (20 steps)
  - Complete the Planning & Preparation Workbook.
  - Prepare physical infrastructure (racks, cabling, ToR switches, DNS/NTP servers).
  - Deploy the Cloud Builder OVA on ESXi, Workstation, or Fusion (4 vCPU / 4 GB / 279 GB).
  - SSH to Cloud Builder, verify ping to each ESXi host and DNS forward + reverse lookups.
  - (Optional) Create a custom ESXi ISO: Get-DepotBaseImages / Get-DepotAddons / New-IsoImage, or use vSphere Lifecycle Manager image export.
  - Install ESXi on all four management hosts (mount ISO, UEFI/BIOS boot, accept EULA, select boot disk ≥128 GB, set root password).
  - Configure host network via DCUI (F2): Configure Management Network → VLAN → Static IPv4 → DNS → set FQDN → confirm reboot.
  - Configure the VM Network port group VLAN on each host using the VMware Host Client.
  - Configure NTP on each host — Edit NTP Settings → enable → start with host → add servers → Save → Start.
  - Regenerate self-signed certificates after FQDN is set: enable SSH, run /sbin/generate-certificates, reboot, disable SSH. Cert files live at /etc/vmware/ssl/rui.crt and rui.key.
  - (Optional) Replace ESXi certs with external CA-signed certificates (copy to /etc/vmware/ssl as rui.crt / rui.key). This path requires JSON bring-up.
  - Download the Deployment Parameter Workbook from the Broadcom Support portal.
  - Fill in the workbook sheets: Credentials, Hosts and Networks (VLANs, vDS profile, hosts, inclusion ranges, thumbprints, NSX host overlay), Deploy Parameters (DNS / NTP / DNS zone / CEIP / FIPS, License Keys, vSphere, NSX, SDDC Manager).
  - (Optional) Convert the workbook to JSON to enable custom ESXi certs or automation.
  - Log into the Cloud Builder UI at https:// with admin credentials.
  - Accept EULA → Select VMware Cloud Foundation → acknowledge prerequisites.
  - Upload the completed workbook → wait for validation → resolve warnings/errors (Cloud Builder flags red cells for missing/invalid data).
  - Click Deploy SDDC. Cloud Builder provisions vCenter, NSX Manager cluster, SDDC Manager and forms the management domain. Watch /opt/vmware/bringup/logs/vcf-bringup-debug.log if something stalls.
  - On success, download the deployment report, click Finish, launch SDDC Manager, then power off Cloud Builder.
  - Day-0 hardening: configure online/offline depot, SFTP/file-based backups, replace VMCA certs with MS CA / OpenSSL / 3rd-party CA, rotate passwords, configure automation account.
`````` `````` `````` ```` ``

## The Deployment Parameter Workbook
The workbook is the authoritative input to bring-up. It has four tabbed sheets:
  - Introduction — overview, guidance and version notes.
  - Credentials — accounts & initial passwords for ESXi, SSO admin, vCenter root, NSX root/CLI/audit, SDDC Manager root/vcf/admin@local, Cloud Builder admin/root.
  - Hosts and Networks — VLANs, MTUs, IP ranges/subnet masks for mgmt, vMotion, vSAN, overlay; vDS profile choice; four (or more) host records with FQDN/IP; vSAN and vMotion IP inclusion ranges; optional ESXi SSL/SSH thumbprints.
  - Deploy Parameters — Existing Infrastructure (DNS, NTP, DNS zone, CEIP, FIPS); License Keys (vSphere, vSAN, NSX, SDDC Manager); vSphere Infrastructure; VMware NSX (VIP, subnet); SDDC Manager network.
Workbook rules: yellow cells contain sample values — replace them. Red cells flag missing or failed validation. Never copy and paste between cells (triggers Excel formula breakage). Workbook Excel validation is limited — Cloud Builder performs the authoritative validation on upload.

## Password complexity at bring-up
The workbook rejects passwords that fail these rules:

Account type | Length | Complexity
-|--|--|-
SSO admin, vCenter root | 8–20 | Mix upper/lower/digit and one of @ ! # $ % ^ ?; no * {}[]()/\\\\'"\`~,;:.<>
NSX root, NSX UI/CLI admin, NSX audit | 12–127 | Same charset, plus at least 5 different characters
SDDC Manager admin@local | 12–127 | Same as NSX without 5-different-chars requirement
SDDC Manager root & super-user vcf, Cloud Builder admin & root | ≥15 | Same charset, must not contain dictionary word (e.g. VMware1! is rejected)

```` `` ````

## vDS profile choice
At bring-up you choose one of three profiles; other configurations require the API.

Profile | Topology | pNICs
-|--|--|-
Profile 1 | Single vDS carrying Management + vMotion + vSAN + Host Overlay | 2 or 4 pNICs
Profile 2 | Two vDS — Primary: Management + vMotion + Host Overlay; Secondary: vSAN | 4 pNICs
Profile 3 | Two vDS — Primary: Management + vMotion + vSAN; Secondary: Host Overlay | 4 pNICs

Default vDS MTU = 9000. Each vDS can carry either an Overlay or VLAN Transport Zone. With vSAN ReadyNodes, the vDS count is frozen at bring-up — you cannot add a vDS to a cluster later.

## ESXi thumbprint validation (optional)
If Validate Thumbprints = Yes in the workbook, collect each host's SSH fingerprint and SSL thumbprint before upload:
`ssh-keygen -lf /dev/null) openssl s_client -connect hostname:443  /dev/null | openssl x509 -sha256 -fingerprint -noout -in /dev/stdin` Start TSM-SSH temporarily on each host (VMware Host Client → Manage → Services), capture fingerprints from Cloud Builder, then stop TSM-SSH again.

## Cluster minimums you must honour at bring-up

Cluster | Single AZ minimum | Multi-AZ minimum
-|--|--|-
Management default (vSAN) | 4 hosts (3 in 5.2.1) | 8 hosts, equally distributed + witness
Management additional (vSAN) | 3 (4 recommended) | 6 (8 recommended)
Management additional (NFS/FC/vVols) | 3 minimum | n/a
VI WLD (vSAN) | 3 (4 recommended) | 6 (8 recommended)
VI WLD (NFS/FC/vVols + vLCM images) | 2 minimum | n/a
NSX Manager cluster | 3 nodes always
NSX Global Manager cluster (Federation) | 3 nodes active + 3 nodes standby
NSX Edge cluster | Min 2 nodes; max 10
Workspace ONE Access cluster | 3 nodes behind NSX LB VIP
Anti-affinity floor for 3-node VM cluster | Minimum 4 physical hosts in the underlying vSphere cluster

## HA admission-control policy

Cluster type | CPU/Memory reserved
-|--|-
Management default, single AZ | 25%
Management default, multi-AZ | 50%
Additional or VI clusters, single AZ | 33%
Additional or VI clusters, multi-AZ | 50%

Compute overcommit — vCPU:pCPU ≤ 2:1 on the management domain, ≤ 8:1 on VI workload domains.

## Creating a VI Workload Domain (Day-0+)
After bring-up, the first VI workload domain is created in SDDC Manager UI or API. Prerequisites:
  - DHCP on the NSX Host Overlay VLAN or a static IP pool.
  - Min 3 hosts in SDDC Manager inventory (2 for NFS/FC/vVols + vLCM images); 3 for Workload Management.
  - For vVols, the VASA provider must be added to vCenter first.
  - Free pNIC on each host; vLCM image available if using vLCM images.
  - NSX Manager and vCenter install bundles downloaded into SDDC Manager and matching the mgmt-domain versions.
  - Unique WLD name — 3–20 chars, no spaces, alphanumerics.
  - Passwords ready for the new vCenter root and NSX admin — 12–16 chars with upper + lower + digit + special from ! @ # $ ^ *; no dictionary words, palindromes, four-char monotonic sequences or three consecutive repeats.
  - All FQDNs/IPs resolvable in DNS.
  - NFS: datastore name, share path, NFS server IP; read/write permissions.
  - VMFS-FC: zoning done, volumes mounted, datastore created on hosts first.
  - License Now requires: NSX, vSAN (if used) and vSphere licenses.
``

## Stretched cluster deployment
  - Management domain default cluster must be stretched first — prerequisite for stretching any VI WLD cluster.
  - Single stretch cluster = 8 hosts (4 per AZ) + witness in a third fault domain; site disaster tolerance = Site mirroring – stretched cluster.
  - Bandwidth ≥10 Gbps between AZs; RTT < 5 ms.
  - vSAN witness appliance sizes: Tiny (10 VMs / 750 witness components), Medium (500 VMs / 21,833), Large (>500 VMs / 45,000), XL (>500 VMs / 64,000).
  - Witness VMkernel adapter for vSAN witness traffic must be different from vSAN data VMkernel; on each ESXi host place vSAN-witness traffic on the Management VMkernel; on the witness appliance the same VMkernel carries management and witness traffic.
  - vSAN ESA clusters cannot be stretched. Use vSAN OSA for stretched topologies.
  - Only clusters created via the Stretch Cluster API are treated as stretched by VCF.

## Import / convert an existing vSphere environment (VCF 5.2 new capability)
Starting with VCF 5.2, customers can convert an existing vSphere environment into a VCF management or workload domain without greenfield bring-up. The VCF Import Tool lives on SDDC Manager at `/home/vcf/vcf-import-package/vcf-brownfield-import-/vcf-brownfield-toolset`; the primary script is `vcf_brownfield.py`.
  - Convert — a vSphere environment becomes the management domain.
  - Import — an existing vSphere environment is added as a VI workload domain (up to 24 convert/import domains per instance).
  - Requirements include: a supported vCenter (must reach port 443 and 5480), compatible ESXi/NSX versions, NSX Manager cluster with VIP, licensed components, host homogeneity, and passing the Import pre-checks (network topology, certs, storage).
  - Workflow: run pre-check → generate inventory JSON → validate → run import → resolve remediations → verify in SDDC Manager.
  - Troubleshoot via /home/vcf/vcfimport alt path and support bundles (sos --health-check).

Day-0 hardening checklist

• Configure Depot Settings — Online (VMware Depot via Broadcom Support Portal account) or Offline (FQDN/IP, port, user/pass; disables online depot).
• Configure backups — SFTP target for file-based backup of SDDC Manager and each NSX Manager; image-based backups for vCenter (supplied by third-party).
• Replace VMCA certificates with MS CA, OpenSSL or third-party CA.
• Rotate all bring-up passwords via SDDC Manager Password Management.
• Configure IdP: add AD over LDAP/OpenLDAP identity sources in vCenter SSO; optionally configure one external IdP (ADFS, Okta, or Microsoft Entra ID — Okta & Entra require vSphere 8.0 U2+ and NSX 4.1.2+).
• Configure SoS baseline — sudo /opt/vmware/sddc-support/sos --health-check.
• Power off Cloud Builder (do not delete).

Reference documentation: VCF 5.2 Getting Started & Deployment Guide · VCF 5.2 Design Guide.

Key Takeaways

• Bring-up is a 20+ step automated workflow driven by Cloud Builder
• Deployment Parameter Workbook (Excel) or JSON payload are the two input methods
• Pre-validation checks: DNS, NTP, VLAN, MTU, ESXi thumbprints, vSAN HCL, licenses, passwords
• Minimum 4 ESXi hosts for management domain (3 for consolidated architecture)

VCF 5.2 Deep Dive: VCF 5.2 Day-2 Operations#

VCF 5.2 Day-2 Operations VCF 5.2

Day-2 in VCF 5.2 spans every operational task after bring-up: host and cluster life-cycling, certificate and password management, identity providers, backup/restore, monitoring, shutdown/startup, and administrative automation. This section covers SDDC Manager's operational surface, incorporates the ten authoritative VCF 5.2 operations study notes, and aligns with the Broadcom Administration and Operations guides.

1. SDDC Manager administration surface

• UI: https:///. Login with vcf/admin@local or an SSO identity. First-login onboarding guides you through depot, backup, CEIP, and password rotation.
• API: https:///v1/ exposed via the Developer Center. Swagger-style API Explorer in the UI.
• SSH: vcf service account (sudo to root for break-glass).

  - CEIP: activate/deactivate from Administration → Customer Experience Improvement Program. Can be toggled at any time.

• Health checks: sudo /opt/vmware/sddc-support/sos --health-check. Full SoS catalog below.
• Service restart: echo 'y' | /opt/vmware/vcf/operationsmanager/scripts/cli/sddcmanager_restart_services.sh.
• Version: cat /opt/vmware/vcf/version.txt.
• PowerShell: VMware.VCF.* modules (installed via PowerShell Gallery) let you script every SDDC Manager operation.

2. Host management — commissioning, decommissioning, maintenance

  - Commissioning (Administration → Hosts → Commission Hosts): host must be installed, on the management VLAN, with FQDN in DNS, NTP configured, and a valid SSH fingerprint / SSL thumbprint. ESXi cert must be regenerated after FQDN change. Host is placed in the Unassigned Hosts pool.
  - Network pool is chosen during commissioning. A network pool bundles vMotion + vSAN (and optionally NFS) ranges. MTU range 1500–9000; VLAN range 0–4094.
  - Assignment: commissioned hosts join a cluster via Add Host (Inventory → Workload Domains → domain → Clusters → Actions → Add Host). For NSX-Edge-hosting clusters only L2 uniform NIC configurations are allowed; L2 non-uniform and L3 non-uniform are not permitted on such clusters.
  - Decommissioning: host must first be removed from its cluster. SDDC Manager then removes NSX host transport node role, certificates, and credentials.
  - Lockdown mode: configured in vCenter per host; Normal mode required for SDDC Manager LCM tasks on that host. KB 336894 describes disabling lockdown when LCM fails.
  - Replace host components — SDDC Manager supports replacement of disks, memory, NICs per the runbook in the Operations Guide (put host in maintenance mode → replace → exit maintenance → SDDC Manager auto-discovers; for NIC changes you may re-bind uplinks to the vDS).

3. Cluster management — add/remove hosts, scale out, delete

• Add host (prereqs): host Active in inventory; balanced cluster warning if new host does not match pre-existing hosts; license present; same principal storage type (mgmt = vSAN; VI = any); for VMFS-FC pre-zoning + datastore; if Edge-hosting cluster only L2 uniform NICs; IP pool must have capacity; DPU vendor must match.
• Add cluster: min 3 hosts (2 for NFS/FC/vVols + vLCM images); License Now requires vSphere + vSAN licenses; DHCP on Host Overlay VLAN unless static pool configured.
• Expand / Shrink / Rename: SDDC Manager tracks cluster state and rebalances vSAN after resize; rename propagates to vCenter.
• Multi-rack compute VI WLD: dedicated host uplink profile per rack, separate host TEP VLAN per rack, dedicated host TEP IP pool per rack. Uses L3 fabric between racks.
• Delete WLD: up to ~20 minutes; KB 78635 for NSX Edge cluster deletion; KB 95445 to re-register NSX as an SSO relying partner.

  - Drift (Sync): under WLD → Manage Workload Domain Configuration Drift; SDDC Manager reconciles out-of-band changes in vCenter / NSX Manager. Backed by Configuration Updates of type FEATURE or FIX.

4. License key management

  - Administration → Licensing. 25-character license keys per product (vSphere, vSAN, NSX, SDDC Manager, Aria).

• Update, add, relicense, or run a license-check; SDDC Manager tracks capacity use across all WLDs.
• New vSphere 8.x / vSAN 8.x keys are required when upgrading to the VCF 5.2 BOM.
• KB 319282 — VCF solution-license-key guidance.

5. Storage management (Day-2)

  - vSAN — Storage Management → vSAN. Maintain 30% free space floor. Mount remote vSAN datastore (OSA from OSA, ESA from ESA/Max) within the same WLD via HCI Mesh. Datastores on non-VCF clusters cannot be mounted on VCF clusters and vice versa.

• NFS — datastore name, share path, NFS server IP; NFS mount requires vDS network pool and MTU 9000 preferred.
• VMFS on FC — zoning, volume mount, datastore creation on hosts before adding to cluster.
• HCI Mesh — cross-cluster remote datastore consumption (vSAN OSA or ESA). Administered via vSphere Client.
• vVols — VASA provider required in vCenter; certificate rotation coordinated with VASA.

6. Monitoring & Supportability

• SDDC Manager Notifications banner — fires on expiring certs (<30 days), failed tasks, and health events.
• SoS utility: /opt/vmware/sddc-support/sos — full-stack health check, log collection, password check, certificate check, vSAN health, DNS/NTP validation.
• Support dir: /var/log/vmware/vcf/sddc-support/.

  - DNS / NTP server updates — Administration → VMware CEIP → DNS Configuration / NTP Configuration; propagates changes across ESXi, vCenter, NSX, SDDC Manager.

• Integrate with Aria Operations for Logs for centralized syslog and Aria Operations for capacity/performance.

7. User, group, and identity-provider management

• Roles: Admin, Operator, Viewer.
• Identity sources (vCenter SSO): AD over LDAP, OpenLDAP — added to the SSO domain as sources.
• External IdP integration (VCF 5.2): one at a time — ADFS, Okta, or Microsoft Entra ID. Okta and Entra ID require vSphere 8.0 U2+ and NSX 4.1.2+.
• Local service accounts: SDDC Manager vcf, admin@local; Cloud Builder admin, root; component root accounts per product.

## 8. Authoritative Day-2 study notes (from VCF 5.2 documentation)
The following seven study notes capture step-by-step procedures that the Broadcom documentation calls out as authoritative. Each note is sourced from the VCF 5.2 Administration and Operations guides. The remaining three standalones on lifecycle topics appear in the Lifecycle Management section.

## VCF 5.2 Certificate Management VCF 5.2

### Default signing CA per component

Component | Default signing CA | LCM
-|--|--|-
SDDC Manager | Management domain VMCA | SDDC Manager UI or plug-in.
NSX Local Manager | Management domain VMCA | SDDC Manager.
NSX Edge | Not applicable | —
NSX Global Manager | Self-signed | Manual — VCF does not manage.
vCenter Server | Local workload-domain VMCA | SDDC Manager.
ESXi | ESXi VMCA | Manual, or API with Trusted Root for enterprise CA-signed initial deployment.

### Supported external CAs
  - Microsoft Active Directory Certificate Services (enterprise CA).
  - OpenSSL (lab / disconnected).
  - Third-party CA via manual CSR + signed-cert install.

### Microsoft CA integration prerequisites
  - CA URL MUST start with https:// and end with /certsrv, e.g. https://ca.rainpole.io/certsrv.
  - The same Windows Server must host both Certification Authority and Certification Authority Web Enrollment roles.
  - Web Server (IIS) with Basic Authentication enabled on the CertSrv site.
  - A “VMware” certificate template duplicated from the Web Server template, with Enhanced Key Usage Server Authentication + Client Authentication, Request Handling: Allow private key to be exported.
  - SDDC Manager account with Enroll permission on that template.
`````` ``

### Standard rotation workflow
  - Administration → Security → Certificates → select component → Generate CSR.
  - Generate Signed Certificate (auto-signs via configured CA) OR upload an externally signed cert.
  - Install Certificate. SDDC Manager snapshots the target, installs the cert, and removes the snapshot.

### Expired-certificate remediation order (critical)
  - Replace NSX Local Manager cluster/node cert (SDDC temporarily skips CA validation).
  - Replace vCenter cert with a VMCA-signed cert (SDDC temporarily skips CA validation).
  - Replace SDDC Manager cert.
  - Use SDDC Manager UI to replace NSX and vCenter again with the real external CA-signed certs.

### Trust-store management
  - If a cert is rotated outside SDDC Manager, it must be added to the SDDC Manager trust store (available VCF 4.5.1+).
  - List: GET /v1/sddc-manager/trusted-certificates.
  - Remove by alias: DELETE /v1/sddc-manager/trusted-certificates/{alias}.
  - Add via Developer Center or POST /v1/sddc-manager/trusted-certificates with PEM payload.
`` `` ``

### Banner & auto-renewal
VCF 5.2 displays an expiry banner 30 days before cert expiry. There is no auto-renewal — auto-renewal is a VCF 9.x feature. Keep a calendar reminder aligned with the 30-day banner and the 15-day/5-day SoS thresholds.

## VCF 5.2 Password Policy Matrix VCF 5.2

### Default expiration

Account | Default max age | Notes
-|--|--|-
SDDC Manager admin@local | Never | Break-glass; rotate manually.
SDDC Manager vcf (super user) | 365 days | Used by automation.
SDDC Manager root | 90 days | Appliance root.
SDDC Manager backup | 365 days | Internal backup user.
administrator@vsphere.local | 90 days | Default SSO admin; does not lock out.
vCenter root | 90 days (warn 7) | Appliance root.
NSX Manager / Edge admin, root, audit | 90 days | PAM-governed; 12-127 char complexity.
Workspace ONE Access local users | 60 days | Managed by WSA policy.
ESXi local users | 99999 days | Practically never; set by Security.PasswordMaxDays.
Cloud Builder admin, root | 90 days | Min 15 chars.

`` `` `` `` `` `` `````` `` ````

### Complexity requirements

Account | Length | Character classes
-|--|--|-
SDDC Manager root, vcf; Cloud Builder admin, root | 15+ (15–127) | upper + lower + digit + special; no dictionary words.
SSO admin, vCenter root | 8–20 | min 1 upper, 1 lower, 1 digit, 1 special; max 1 identical adjacent.
NSX admin, NSX UI/CLI, NSX audit, SDDC admin@local | 12–127 | 4 classes; keep ≤ 20 chars if using SDDC Manager password rotation — longer strings break rotation.
ESXi local | retry=3, disabled/disabled/disabled/7/7 tiers | PAM passwdqc; PasswordHistory = 0 by default.

```````` `` `` ``

### Account lockout defaults

Component | Max fails | Window | Unlock duration | Notes
-|--|--|--|--|-
ESXi | 5 (Security.AccountLockFailures) | n/a | 900 s (AccountUnlockTime) | Applies to ESXi Shell & API.
vCenter SSO | 5 | 180 s | 900 s | Excludes administrator@vsphere.local and system accounts.
vCenter appliance | 3 | — | root 300 s / others 900 s | /etc/security/faillock.conf may reset on restart.
NSX Manager API | 5 | 180 s | 900 s | Per-user.
NSX Manager CLI | 5 | — | 900 s | Via PAM.
NSX Edge CLI | 5 | 900 s | 900 s | —
SDDC Manager local users | PAM faillock defaults | — | 900 s | —

```` `` ``

### Password rotation workflow (SDDC Manager)
  - Administration → Security → Passwords.
  - Select components → Rotate Now or Schedule (default 90-day cadence for rotatable components).
  - For credentials changed out-of-band, run Remediate Password to resynchronize SDDC Manager.
  - Use Credentials Lookup utility to retrieve current passwords; never read them from the backend DB.
  - Banner notification fires 14 days before expiry in the SDDC Manager UI.

### Special caveats
  - Workspace ONE Access password rotation must be driven through Aria Suite Lifecycle for clustered deployments so the embedded Postgres user stays in sync.
  - Disallowed specials are documented per component; generally $ & / | are restricted in NSX and SDDC accounts.
``

## VCF 5.2 Shutdown and Startup — Authoritative Order VCF 5.2

### Why order matters
SDDC Manager and the NSX / vCenter control plane have dependencies that prevent clean shutdown if services are stopped in the wrong sequence. Violating the published order produces stale NSX control-plane state, vSAN object-alignment errors on restart, and vCenter inventory corruption.

### Shutdown order (management domain last)
  - Quiesce customer VMs in every VI workload domain (gracefully shut down or move off).
  - For each VI WLD cluster: disable HA, place vSphere Cluster Services (vCLS) into Retreat Mode (config.vcls.clusters.domain-c.enabled = false), then power down vCLS VMs.
  - Run the vSAN Shutdown Cluster wizard on each VI vSAN cluster.
  - Power off VI ESXi hosts.
  - Shut down each VI workload domain NSX Edge cluster, then NSX Local Manager cluster, then vCenter Server.
  - Shut down Aria Automation, then Aria Operations, then Aria Operations for Logs.
  - Shut down Workspace ONE Access (cluster nodes in reverse-join order).
  - Shut down Aria Suite Lifecycle.
  - Management-domain NSX Edge cluster → NSX Local Manager cluster.
  - Management vCenter Server.
  - SDDC Manager.
  - Management cluster: vCLS Retreat Mode → vSAN Shutdown Cluster wizard.
  - Power off management ESXi hosts.
```` ``

### Startup order (reverse — management first)
  - Power on management ESXi hosts; wait for vSAN to go healthy (vSAN automatically exits maintenance if “Shutdown Cluster” wizard was used).
  - Exit vCLS Retreat Mode on the management cluster; let vCLS VMs auto-create.
  - Power on SDDC Manager.
  - Power on management vCenter Server.
  - Power on management NSX Local Manager cluster, then management NSX Edge nodes.
  - Power on Aria Suite Lifecycle, then Workspace ONE Access nodes.
  - Power on Aria Operations for Logs → Aria Operations → Aria Automation (strict order).
  - For each VI workload domain: vCenter → NSX Local Manager → NSX Edges.
  - Power on VI ESXi hosts; exit vCLS Retreat Mode; re-enable HA.
  - Run vSAN Shutdown Cluster wizard “Restart Cluster” for VI vSAN clusters.
  - Power on customer VMs.
``

### Key commands
  - Retreat Mode: Configure > vSphere Cluster Services > Advanced Options → set config.vcls.clusters.domain-c.enabled to false, save, wait 1 minute; vCLS VMs auto-remove.
  - vSAN Shutdown wizard: Cluster > Actions > vSAN > Shutdown Cluster (8.0+); wizard handles on-disk quiescence, witness (for stretched), and power-off order.
  - Host enter maintenance (no data migration, preferred for planned shutdown): esxcli system maintenanceMode set -e true -m noAction.
`````` `` ``

### Common failure modes
  - Skipping Retreat Mode leaves vCLS VMs stuck during vSAN shutdown — they are protected from power-off and block the wizard.
  - Shutting down SDDC Manager before Aria Suite Lifecycle breaks orchestrated resume of Aria component state.
  - Powering VI NSX Edges off after VI NSX Managers can strand BGP sessions and produce stale VTEP state.

## VCF 5.2 Backup and Restore VCF 5.2

### SDDC Manager backup defaults
  - Automatic backup enabled by default.
  - Schedule: every day at 04:02 AM, with take-backup-on-state-change enabled.
  - Retention: last 7 backups; 1 day of hourly; 7 days of daily.
  - Encryption passphrase protects the tarball.
  - External SFTP target is a prerequisite for file-based restore.

### SFTP requirements (authoritative)
  - Publish BOTH a 256-bit ECDSA and a 2048-bit RSA SSH public key.
  - Allowed host-key algorithms: rsa-sha2-512, rsa-sha2-256, ecdsa-sha2-nistp256/384/521.
  - FIPS MAC: hmac-sha2-256. FIPS Kex: diffie-hellman-group-exchange-sha256. SHA-1 rejected.
  - SFTP host fingerprint must be captured in the SDDC Manager backup config; path, user, password or key required.
`````` ````

### NSX Local Manager backup
  - Configured automatically during bring-up; cluster backup runs hourly.
  - Inventory backups on change (~5-minute cadence).
  - Retained 7 days on the same SFTP endpoint.

### vCenter Server backup
  - Configured on the vCenter VAMI (port 5480) — not through SDDC Manager.
  - Targets: SFTP, FTPS, HTTP(S), SCP, NFS, SMB.
  - Recommendation: weekly full + daily incremental, or daily full for smaller vCenters.
  - Coordinate SDDC Manager and all same-SSO vCenter backup schedules into the SAME 5-minute window for consistent restore.

### File-based restore of SDDC Manager
  - Deploy a new SDDC Manager appliance from OVA matching the backup version.
  - Provide the SFTP location and encryption passphrase.
  - Restore runs in approximately 45 minutes; full NSX + vCenter inventory reconciliation ≈ 2 hours.

### Image-based (VM-level) backup
Not supported as a primary recovery mechanism for SDDC Manager. Use file-based restore for SDDC Manager; use native vCenter restore for vCenter; use NSX file-based restore for NSX Manager. Image-based backup may supplement, but do not attempt quiesced VMDK snapshots of SDDC Manager for production recovery.

### RPO / RTO

Scenario | RPO | RTO
-|--|--|-
SDDC Manager daily | 24 h | ~45 min
NSX Local Manager hourly | 1 h | ~2 h (cluster rebuild + inventory reconcile)
vCenter daily full | 24 h | 30–60 min

## VCF Import Tool (VCF 5.2 / 5.2.1) VCF 5.2

### Purpose
Brings brownfield vCenter / NSX / ESXi estates under VCF management without reinstalling. Two scenarios:
  - Convert (Scenario A): existing vCenter environment becomes the management domain of a new VCF instance — SDDC Manager is deployed fresh and imports the existing components.
  - Import (Scenario B): existing vCenter environment becomes a VI workload domain of an existing VCF instance.

### Build / version matrix
  - VCF Import Tool 5.2: pairs with SDDC Manager 5.2.x.
  - VCF Import Tool 5.2.1.2 + SDDC Manager 5.2.1.1 — first release that supports LACP on imported vDS.
  - Target vCenter MUST use HTTPS port 443. Custom ports are not supported.
  - VMFS-FCoE as principal for a converted management default cluster is supported from VCF 5.2.1.

### Supported principal storage on import
  - Converted management default cluster: vSAN, NFS v3, VMFS-FC, VMFS-FCoE (5.2.1+). Greenfield management domains still require vSAN.
  - NFS v4.1, VVOLs, and native iSCSI are NOT supported for a converted default management cluster.
  - VI WLDs (via Import scenario): vSAN / NFS v3 / VMFS-FC / vVols.

### Cluster constraints
  - Management domain default cluster minimum: 4 hosts (3 in 5.2.1+).
  - VI workload domain minimum: 3 hosts (2 with NFS / VMFS-FC / vVols + vLCM images).
  - All hosts in an imported cluster must share the same ESXi patch level and the same vDS version.
  - Source vDS must not use LACP unless Import Tool 5.2.1.2 + SDDC 5.2.1.1.

### High-level workflow
  - Deploy the VCF Import Tool VM (or run the bundled CLI on the Import Tool OVA).
  - Deploy SDDC Manager OVA (Scenario A only) — do not yet associate with the vCenter.
  - Run vcf-brownfield.py check against the target vCenter to produce the readiness report.
  - Remediate: align ESXi builds, remove unsupported LACP (if unsupported combo), ensure NSX-T already exists and is healthy, clean up unsupported storage, align vDS names, ensure no custom port 443 overrides.
  - Run vcf-brownfield.py convert (Scenario A) or import (Scenario B) — the tool drives SDDC Manager inventory ingestion.
  - Post-import: run the Sync workflow in SDDC Manager to reconcile configuration drift, then rotate passwords and certificates through SDDC Manager to bring them under policy.
`` ````

### SSO rules
  - Scenario A: the existing SSO domain becomes the VCF SSO domain. Default vsphere.local still permitted but a custom SSO domain is preserved.
  - Scenario B: imported vCenter may join the shared SSO (Ring ELM, ≤15 WLDs) or be isolated in its own SSO.
``

### Post-import housekeeping
  - Rotate all credentials through SDDC Manager.
  - Configure SFTP backup target; run first SDDC Manager backup.
  - Ensure NSX Manager cluster backup has switched to SDDC-configured hourly cadence.
  - Install licenses via SDDC Manager > Administration > Licensing.

## Stretched vSAN Clusters in VCF 5.2 VCF 5.2

### Supported topology
  - Two data sites (AZ1, AZ2) plus a witness host at a third site.
  - Supported for management default cluster (multi-AZ min 8 hosts) and for VI workload domain clusters (multi-AZ min 6, 8 recommended).
  - Each site is represented by a vSAN Fault Domain; witness is a vSAN Witness Appliance (virtual ESXi).
  - ESA clusters cannot be stretched in VCF 5.2.
  - HCI Mesh is NOT supported on stretched clusters.

### Latency and bandwidth

Link | RTT | Bandwidth
-|--|--|-
AZ1 ↔ AZ2 (data-to-data) | < 5 ms | ≥ 10 Gbps
Data ↔ Witness | ≤ 200 ms (≤ 10 hosts/site); < 100 ms (11–15 hosts/site) | 100 Mbps minimum (generic vSAN)
NSX Manager inter-node | < 10 ms | —
NSX Manager ↔ Transport Node | < 150 ms | —
Cross-vCenter vMotion | < 150 ms | —

### VLAN and MTU
  - Each AZ has its own management, vSAN, vMotion, NSX Host Overlay VLANs routed between sites.
  - vSAN / vMotion / Overlay MTU 9000 end-to-end; Geneve minimum 1700 per VCF 5.2.
  - Witness traffic separation (WTS) recommended: dedicated VMkernel on data hosts pointing to the witness network.

### Storage policy
  - Site Disaster Tolerance = Dual site mirroring. FTT within site configurable (1 or 2) depending on host count.
  - Preferred site defined; secondary takes over on preferred-site failure.
  - Read Locality automatic — reads served from the local site except during recovery.

### HA configuration
  - Admission control: 50% CPU/memory for multi-AZ (VCF-CLS-RCMD-CFG-004 family).
  - Set multiple das.isolationaddress0..4 pointing to gateways at both AZs.
  - Set das.iostatsinterval = 0 to reduce false positives on VMCP.
  - Configure VM/Host DRS groups and VM-Host should rules to anchor workloads to their preferred AZ.
`` ``

### Unsupported configurations
  - ESA + stretched cluster.
  - Stretched + HCI Mesh.
  - Stretched + vSAN Max.
  - Witness appliance on either data AZ (must be third site or colocated with management of a separate instance).

### SDDC Manager stretch workflow
  - Deploy the vSAN Witness Appliance at the third site; add to management vCenter (not to any VCF cluster).
  - Run SDDC Manager Stretch Cluster API: POST /v1/clusters/{id} with clusterStretchSpec.
  - SDDC Manager configures fault domains, witness, NSX transport node profiles, DRS/HA settings.
  - Post-stretch: verify with sos --health-check --domain-name .
```` ``

## NSX Federation in VCF 5.2 VCF 5.2

### Concept
NSX Federation unifies the NSX control plane across multiple VCF instances. Each instance retains its NSX Local Manager; a new NSX Global Manager cluster (active + standby) provides cross-instance network/security object definitions and policy push.

### Deployment requirements
  - NSX Global Manager cluster: 3 Medium nodes (active); optional 3-node standby cluster at the secondary instance.
  - Deployed manually — SDDC Manager does not orchestrate NSX Global Manager lifecycle in VCF 5.2.
  - Each instance must run the same NSX version (patch levels aligned).
  - Inter-instance RTT < 500 ms (VCF-NET-REQD-CFG-006).
  - Cross-vCenter vMotion mobility: < 150 ms.

### Topology options
  - Active / Standby: one location runs the primary Global Manager cluster; the other is standby, promoted manually.
  - Stretched networks (Tier-1 spanning two locations) or Tier-1s pinned to a single location with cross-location Tier-0 ECMP.
  - Distributed Firewall policy defined on Global Manager, pushed to every Local Manager.

### Constraints in VCF 5.2
  - AVN (Application Virtual Networks) is NOT supported when the management NSX is part of Federation.
  - NSX Global Manager upgrades are manual — follow the NSX upgrade guide, always upgrade Global Manager before any Local Manager in the same federation.
  - NSX Global Manager certificates are self-signed by default and must be manually rotated.
  - Configuration drift reconciliation (Sync) only applies to Local Managers; Global Manager is out of SDDC Manager scope.

### Federation-aware upgrade order
  - NSX Global Manager (active cluster) first.
  - NSX Global Manager standby cluster.
  - Each instance's NSX Local Manager and Edges.
  - Then continue the usual per-instance order: vCenter → ESXi.

### Tier-1 location config
  - Tier-1 can be location-specific (pinned) or stretched (active-active across locations).
  - Edge cluster placement must satisfy service HA: Active-Standby needs exactly 2 Edges at the service location; Active-Active up to 8.

## 9. Backup & restore — comprehensive matrix

Component | Method | Notes
-|--|--|-
SDDC Manager | SFTP file-based backup | Encrypted with a backup passphrase. Configure under Administration → Backup Configuration. Recommended every 24 h. On-demand backups run before upgrades.
vCenter Server | vCenter built-in file-based backup (FTPS/SCP/HTTP/HTTPS/SMB/NFS/SFTP) | Can also be image-based snapshot backed up by third-party (Veeam, Avamar).
NSX Manager | NSX native SFTP backup | Schedule interval + on-demand. Cluster backups include all three nodes.
NSX Edge | Backed up as part of NSX Manager backup | Redeploy from NSX Manager if an Edge is lost.
Aria Suite Lifecycle | Image-based + file-based | Follows Aria Suite LCM backup workflow.
Workspace ONE Access | Image-based | Cluster: snapshot all 3 nodes coordinated.
ESXi | Config backup via host (host profile or vim-cmd hostsvc/firmware/backup_config) | Not centrally orchestrated by SDDC Manager.

``

## 10. Key paths, commands and URLs (quick reference)
  - Cloud Builder bring-up log: /opt/vmware/bringup/logs/vcf-bringup-debug.log
  - Cloud Builder logs dir: /var/log/vmware/vcf/bringup/
  - SDDC Manager support logs: /var/log/vmware/vcf/sddc-support/
  - SoS utility: /opt/vmware/sddc-support/sos
  - Service restart: echo 'y' | /opt/vmware/vcf/operationsmanager/scripts/cli/sddcmanager_restart_services.sh
  - ESXi cert regenerate: /sbin/generate-certificates (cert files in /etc/vmware/ssl as rui.crt / rui.key)
  - vSAN HCL JSON URL: historically https://partnerweb.vmware.com/service/vsan/all.json (endpoint retired post-Broadcom; current HCL data via https://compatibilityguide.broadcom.com/; cached locally at /opt/vmware/bringup/tmp/all.json)
  - NFS bundle mount: /nfs/vmware/vcf/nfs-mount/bundle/
  - SDDC Manager import tool dir: /home/vcf/vcf-import-package/vcf-brownfield-import-/vcf-brownfield-toolset
  - Postgres: DB platform, user postgres.
  - Trusted cert API: GET /v1/sddc-manager/trusted-certificates, DELETE /v1/sddc-manager/trusted-certificates/{alias}.
  - Cloud Builder UI: https:// with admin default user.
  - vCenter management interface: https://:5480 (port 443 required for import).
`` `` `` `` `` ```````` ```` `` `` ```` ```` ```` ``

## 11. Important KB references
  - KB 88287 — supported async patches.
  - KB 78635 — deleting an NSX Edge cluster.
  - KB 95445 — re-register NSX as a relying partner after WLD delete.
  - KB 378126 — 100 HTTP API req/sec NSX limit.
  - KB 336894 — disable Lockdown Mode to unstick LCM.
  - KB 70656 — TRUSTED_ROOT_CRLS store issue.
  - KB 85527 — CertGenVVS tool.
  - KB 408300 — using non-certified ESA disks for PoC only.
  - KB 319282 — VCF solution license-key guidance.
  - KB 92227 — vSphere with Tanzu specific upgrade sequence.
  - KB 312168 — offline depot configuration.
  - KB 312159 — disabling unused TPM modules.
`` Reference documentation: VCF 5.2 Administration Guide · VCF 5.2 Operations Guide · vSAN 8.0 Documentation.

Key Takeaways

• Password rotation is critical: SDDC Manager manages passwords for vCenter, NSX, ESXi, Aria components
• Certificate management supports Microsoft CA, OpenSSL, and third-party CAs (ESXi certs NOT managed)
• SoS utility (/opt/vmware/sddc-support/sos) is the primary health check and support bundle tool
• Backup strategy: file-based (SFTP) and image-based (snapshots) with encrypted backup passphrase

VCF 5.2 Deep Dive: VCF 5.2 Lifecycle Management#

VCF 5.2 Lifecycle Management VCF 5.2

Lifecycle Management in VCF is the orchestrated, prescribed-order upgrade and patching of every component in a workload domain's Bill of Materials. SDDC Manager is the sole entry point: it downloads bundles from the depot, stages them, runs pre-checks, and enforces the upgrade sequence. VCF 5.2 introduces three important flexibilities — Independent SDDC Manager Upgrade, Flexible BOM, and native Async Patch — while keeping the same six BOM-state machine and strict management-domain-first rule.

1. Upgrade path support (5.2 target)

• You can upgrade to VCF 5.2.x sequentially or with skip-level from VCF 4.5, 5.0, or 5.1.
• Any VCF instance running a release earlier than 4.5 must first upgrade the management domain and all VI workload domains to 4.5.x before targeting 5.2.
• For clusters with vSphere with Tanzu / Workload Management, consult KB 92227 for the Supervisor-aware upgrade sequence.
• Verify the Broadcom Interoperability Matrix and the VCF 5.2.x Release Notes before any upgrade.

2. Bundle types & depot

SDDC Manager supports two depot modes (one at a time): Online (VMware Depot via Broadcom Support Portal) and Offline (FQDN/IP, port, user/pass). Switching to offline disables and removes the online depot connection.

• Install Bundles — binaries for creating VI workload domains (vCenter, NSX, Aria Suite Lifecycle). Labelled Install Only Bundle in the UI.
• Upgrade Bundles — the main LCM artefact. Upgrades a specific component to a target BOM version.
• Async Patch Bundles — critical out-of-cycle patches to NSX Manager / vCenter / ESXi when no upgrade bundle exists. Starting in VCF 5.2 these can be downloaded directly in the SDDC Manager UI or via the Bundle Transfer Utility (pre-5.2 required the Async Patch Tool just to fetch them).
• Independent SDDC Manager Bundles — 4th-digit bundles (e.g. 5.2.0.1) that upgrade SDDC Manager by itself once the instance is at 5.2+.
• Flexible BOM Upgrade Bundles — let you select specific target versions per component (including async-patch versions) when upgrading.

3. The six BOM states

4. Upgrade order (management-domain first, always)

• SDDC Manager (management domain) — must upgrade first. Always backed up automatically before upgrade.

  - Aria Suite (via Aria Suite Lifecycle) — Workspace ONE Access → Aria Operations for Logs → Aria Operations → Aria Automation → Aria Operations for Networks.
  - NSX Global Manager (if using Federation).
  - NSX Local Manager cluster (management domain).
  - NSX Edge cluster.
  - ESXi host transport nodes (via vLCM image remediation).
  - vCenter Server (management domain).
  - ESXi hosts (management cluster, vLCM image remediation).
  - vSAN on-disk format upgrade (post-ESXi, if required).
  - Repeat steps 3–9 for each VI Workload Domain — but you may upgrade multiple VI WLDs in parallel (different WLDs) subject to resource windows.
  - Post-upgrade tasks: clear stale ARP after vCenter switchover (ip -s -s neigh flush all), NFS re-mount validations, re-run SoS health-check.
`` Within a workload domain the canonical order is: NSX → vCenter → ESXi/vSAN → SDDC Manager → Aria (SDDC Manager is global to the instance, so it is actually done once at step 1).

5. Upgrade prerequisites (authoritative list)

• Allocate a temporary IP address per vCenter upgrade when upgrading from 4.5.x (management subnet; can be reused sequentially). Also required for every 5.2.1 vCenter RDU upgrade.
• Obtain updated vSphere 8.x / vSAN 8.x licenses.
• Verify no expired or expiring passwords (Password Management dashboard).
• Verify no expired or expiring certificates on every workload domain.
• Verify ESXi TPM module status: if present, run latest 2.0 firmware or disable in BIOS (KB 312159).
• Verify ESXi hardware is on the target version's VMware Compatibility Guide.
• Manually update the vSAN HCL database (KB 2145116).
• Back up SDDC Manager, every vCenter, and every NSX Manager (file-based and image-level). Take a cold snapshot of SDDC Manager.
• Ensure no failed workflows and no resources in activating or error state — halt and call Broadcom Support if any.
• Read the 5.2 Release Notes for known upgrade issues.
• Deactivate all VCF 4.x async patches and run inventory sync before upgrading (VCF 5.0+ no longer requires the Async Patch Tool for upgrades from async-patched VCF).
• Review the NSX Upgrade Guide's Operational Impacts section.
• Ensure no active alarms in vSphere Client.
• Download the upgrade bundles for every component being upgraded.

6. Pre-check procedure (VCF 5.2)

  - Inventory → Workload Domains → [domain] → Updates → Run Precheck.

• Target Version dropdown: choose General Upgrade Readiness or a specific 5.2.x target.
• Parallel prechecks across multiple WLDs are supported.
• The precheck validates ~40 items: disk space, backup currency, certificate state, vSAN health, NTP skew, password state, BOM compatibility, drift.
• Versions prior to SDDC Manager 5.0 run the legacy Precheck Update — Versions Prior to SDDC Manager 5.0 variant.

7. Bundle download (online)

  - Administration → Depot Settings → Authenticate for the VMware Depot with Broadcom Support Portal credentials.
  - Lifecycle Management → Bundle Management → Bundles tab. The Availability column shows Available (apply now) or Future (another bundle must apply first).

• Click View Details for version/release-date details; Download Now or Schedule Download; see the Download History tab.

8. Offline / dark-site depot workflow

• On an internet-connected host, run the Bundle Transfer Utility (lcm-bundle-transfer-util) with --download and the required manifest; only this tool is supported.
• Transport bundles to the dark site.

  - On the SDDC-Manager-side, configure the Offline Depot (Administration → Depot Settings → Set Up → FQDN/IP, port, user/pass). This disables and removes the online depot connection.

• Upload bundles to the depot with --upload.
• VCF 5.2+ supports shared offline depots across multiple SDDC Manager instances (KB 312168).

` Proxy: SDDC Manager supports an HTTPS proxy for online depot. The Bundle Transfer Utility accepts its own proxy options.

9. Transition from vSphere Lifecycle Manager Baselines to Images

• VCF 5.2 encourages moving clusters from vLCM Baselines (the older workflow) to vLCM Images for declarative management.
• Prerequisites: supported topology, all hosts at the baseline target, current NSX Transport Node profile compatible, valid vLCM image candidate from the depot.
• Compliance states: Compliant, Non-compliant, Unknown, In Progress, Staged. Some known false positives can be added to the cluster's Ignore List.
• PowerShell: menu-driven wrapper provided; key cmdlets reach the Compliance-Check / Transition / Remediation APIs.
• API path: POST /v1/clusters/{id}/vlcm-transition with image spec.

10. Management domain upgrade — step by step

• Run precheck against the management domain; resolve all failures.
• Apply the VCF upgrade bundle to SDDC Manager.
• Apply Configuration Updates (drift) required for the target BOM.
• Upgrade Aria Suite via Aria Suite Lifecycle workflow.
• If Federation: upgrade NSX Global Manager first (LCM orchestrated).
• Upgrade the management-domain NSX Manager cluster (prechecked, then applied; upgrade affects only this WLD's NSX because shared NSX cluster upgrades wait for all sharing WLDs).
• Upgrade the management-domain vCenter Server (uses a temporary IP when source is 4.5.x).

  - Upgrade the management-cluster ESXi hosts via vLCM image remediation (SDDC Manager orchestrates cluster remediation: host → maintenance → remediate → exit → next).

• Post-upgrade tasks: verify SSO/ELM, vSAN health, NSX health, Aria integration, SDDC Manager dashboards.

11. VI workload domain upgrade — step by step

• Precheck the VI WLD.

  - Component order: NSX Local Manager cluster → NSX Edge cluster → ESXi transport nodes → vCenter Server → ESXi hosts → (optional) vSAN on-disk format.

• For shared NSX Manager deployments, NSX Manager is upgraded only when every host cluster in every sharing WLD is selected for upgrade. Upgrading just one of the sharing WLDs upgrades its transport nodes but leaves NSX Manager at the source BOM.
• Post-upgrade: re-test HA, DRS, vSAN, NFS re-mounts, Edge service health.

12. Patching (5.2+)

  - Lifecycle Management → Plan Patching: browse available async and upgrade patches per domain.

• Install vCenter / ESXi / NSX patches in place of a full upgrade when only a fix-level patch is needed.
• SDDC Manager precheck enforces compatibility; incompatible combinations block apply.

13. Independent SDDC Manager Upgrade

• Allows upgrading just SDDC Manager (and the VCF services) without touching vCenter / NSX / ESXi.
• Delivered via a dedicated bundle tile in the UI (4th-digit version such as 5.2.0.1).
• Prerequisites: instance already at 5.2+, no failed workflows, backups current, depot configured.
• Useful for consuming new VCF orchestration capabilities early; managed components can remain at their current BOM for a time-bounded window.

14. Troubleshooting upgrades

• SDDC Manager issues: restart services script above; check /var/log/vmware/vcf/sddc-support/; run sos --health-check.

  - vCenter issues: after switchover, traffic stalls on hosts — clear stale ARP with ip -s -s neigh flush all; see KB 370882 for vCenter 6.5 → 8.0 U3 upgrade edge cases.

• NSX shared-cluster issues: verify every sharing WLD is selected; KB 95445 to re-register NSX post-WLD delete.
• Lockdown on ESXi blocks LCM tasks — KB 336894 to disable.

15. Authoritative lifecycle study notes (from VCF 5.2 documentation)

The following two notes are sourced directly from the VCF 5.2 Lifecycle Management Guide and the Async Patch Tool 1.2 documentation.

SDDC Manager Upgrade States and Bundle Types VCF 5.2

Six upgrade BOM states

Five bundle types

• Install Bundles: binaries for VI workload-domain creation (vCenter, NSX, Aria Suite Lifecycle). Marked “Install Only Bundle” in the UI.
• Upgrade Bundles: component upgrades. Main lifecycle artifact.
• Async Patch Bundles: critical patches for NSX / vCenter / ESXi outside the main BOM cadence.
• Independent SDDC Manager Bundles: (new in VCF 5.2) let you upgrade SDDC Manager independently from the rest of the BOM. 4th tile in the UI.
• Configuration Drift Bundles: deliver Configuration Updates (FEATURE or FIX) that reconcile 2nd-party components with VCF-prescribed state.

Flexible BOM Upgrade

• VCF 5.2 introduces Flexible BOM: permits upgrading vCenter or NSX ahead of ESXi within a support matrix.
• Guardrails enforced by SDDC Manager precheck — incompatible combinations block.
• Intended for customers pinned on a specific ESXi build.

Configuration Updates (drift reconciliation)

• Types: FEATURE (adds prescribed capability) and FIX (re-aligns existing state).
• CloudAdminRoleConfigDrift (VCF 5.0).
• DvpgConfigurationDrift (VCF 5.1) — creates VM_MANAGEMENT DVPG and migrates management VMs for traffic separation.
• RegisterSDDCmanagerAsVCExtensionConfigDrift (VCF 5.2).
• vSAN HA isolation-address drift, Compute Manager registration drift.

  - Apply through SDDC Manager Repository → Configuration Updates tab.

Precheck (VCF 5.2)

  - UI location: Inventory → Workload Domains → [domain] → Updates → RUN PRECHECK.

• Target Version dropdown: “General Upgrade Readiness” + available VCF targets.
• Parallel precheck across multiple workload domains supported.
• Validates ~40 items — disk space, backup status, certs, vSAN health, NTP skew, password health, BOM compatibility, drift.
• Versions prior to SDDC Manager 5.0 run the legacy “Precheck Update - Versions Prior to SDDC Manager 5.0” variant.

Flexible BOM Upgrade and Async Patch Tool VCF 5.2

Async Patch Tool (ASPT)

• Delivered as a separate Broadcom-supplied CLI.
• Applies critical component patches (NSX / vCenter / ESXi) outside the main BOM cadence.

  - Not required to enable the 5.x→5.x upgrade path — SDDC Manager natively exposes async patches starting VCF 5.2 under Plan Patching.
  - For 4.y → 5.x upgrades from an async-patched 4.y state, ASPT is still required to unblock the upgrade path.

• Runtime prompts: patch selection, parallel download confirmation, deployment confirmation; supports dry-run mode.
• Log path: /var/log/async-patch-tool/.

Flexible BOM

• Allows vCenter or NSX to be upgraded ahead of ESXi within a published support matrix.
• SDDC Manager precheck enforces compatibility; non-supported combinations block the upgrade.
• Useful for pinning ESXi on an unchanged vSphere build while adopting a newer NSX or vCenter patch.

Independent SDDC Manager Upgrade

• Upgrades SDDC Manager and the VCF services without touching vCenter / NSX / ESXi.
• Delivered via a dedicated bundle tile in the UI.
• Useful for consuming new VCF orchestration capabilities sooner; the managed components can remain on their current BOM for a time-bounded window.

Bundle Transfer Utility (offline)

• CLI: lcm-bundle-transfer-util — only supported download tool for offline use.
• Workflow: (1) on internet-connected host, download the manifest and bundles with --download; (2) transport to dark site; (3) on SDDC Manager side, --upload to the local depot.
• VCF 5.2+ supports shared offline depots (KB 312168).
• Configuring an offline depot DISABLES and removes the online depot connection — SDDC Manager supports one depot type at a time.

Temporary-IP rules for vCenter upgrades

• Required for every vCenter upgrade from a VCF 4.5.x source.
• Required for all VCF 5.2.1 vCenter RDU upgrades.
• IP can be reused sequentially across vCenters; parallel upgrades need additional temp IPs.
• If traffic stalls on hosts after switchover: clear stale ARP with ip -s -s neigh flush all.

NSX upgrade scope in shared-NSX deployments

When several workload domains share an NSX Manager cluster, NSX Manager is only upgraded when every host cluster in every sharing workload domain is selected for upgrade. Upgrading just one of the sharing workload domains upgrades its transport nodes but leaves the NSX Manager cluster on the source BOM.

16. Async Patch Tool 1.2 — reference

  - Delivered as a separate Broadcom-supplied CLI; not required for 5.x → 5.x upgrades (starting VCF 5.2, async patches are exposed in SDDC Manager natively under Plan Patching).
  - Still required for 4.y → 5.x upgrades from an async-patched 4.y state (unblocks the path).

• Two modes: online (fetches bundles over the internet) and offline (pre-staged bundles).
• Runtime prompts: patch selection, parallel download confirmation, deployment confirmation. Supports dry-run.
• Log path: /var/log/async-patch-tool/.
• Upgrade matrix after applying an async patch is documented in KB 88287.

17. Flexible BOM Upgrade — reference

• Lets you choose specific target versions per component (e.g. upgrade vCenter ahead of ESXi) within a published support matrix.
• SDDC Manager precheck enforces compatibility; non-supported combinations are blocked.
• Typical use case: pin ESXi on an unchanged vSphere build while adopting a newer NSX or vCenter patch.

  - Procedure: Lifecycle Management → Upgrades → select a WLD → choose Flexible BOM Upgrade → pick component target versions → precheck → apply.

18. Drift remediation (Configuration Updates)

Configuration Updates are prescribed JSON workflows SDDC Manager runs against a workload domain to (re)align its configuration to the current BOM. Two categories:

• FEATURE — adds a prescribed capability (e.g. DvpgConfigurationDrift in VCF 5.1 creates the VM_MANAGEMENT DVPG and migrates management VMs for traffic separation).
• FIX — re-aligns an existing state (e.g. vSAN HA isolation-address drift, compute-manager registration drift).

```` Examples: `CloudAdminRoleConfigDrift` (VCF 5.0), `DvpgConfigurationDrift` (VCF 5.1), `RegisterSDDCmanagerAsVCExtensionConfigDrift` (VCF 5.2). Apply through SDDC Manager → Repository → Configuration Updates tab.

Reference documentation: VCF 5.2 Lifecycle Management Guide · VCF 5.2 Release Notes & Interop.

Version Comparison

Key Takeaways

• LCM downloads bundles from VMware Depot (online) or offline depot, stages, runs prechecks, then upgrades
• Upgrade sequence is strict: NSX → vCenter → ESXi → vSAN → SDDC Manager → Aria
• Async patches allow out-of-cycle security fixes without full BOM upgrade
• Skip-level upgrades are NOT supported — must go through each intermediate version

VCF 5.2 Deep Dive: VCF 5.2 → 9.0 Migration Guide#

VCF 5.2 → 9.0 Migration Guide VCF 5.2 → 9.0

VCF 9.0 is a major re-architecture, not a maintenance release. It re-scopes VCF from a per-instance SDDC into a fleet-wide private cloud, retires the SDDC Manager UI as the fleet control plane, renames the Aria suite, makes vSAN ESA the default, replaces Cloud Builder with VCF Installer, and shifts licensing from 25-char keys to subscription license files. Understanding these shifts is mandatory for any architect designing a brownfield VCF 5.2 environment with a forward-looking migration path.

1. Architectural shifts at a glance

2. Component renaming cheat sheet

3. New concepts in VCF 9.0

• VCF Private Cloud — top-level construct; contains one or more VCF Fleets.
• VCF Fleet — a set of VCF Instances plus standalone vCenters managed by a single set of fleet-level management components (VCF Operations + VCF Automation).
• VCF Instance — the unit that used to be called the "SDDC": management domain + zero or more workload domains.
• VCF Operations Console — new UI/UX that replaces the fleet-scope of SDDC Manager.
• VCF Operations fleet management appliance — adds infra-management automation workflows to VCF Operations.
• VCF Operations collector groups / nodes — collect data from vCenter, NSX, vSAN adapters (scale-out data collection).
• VCF Identity Broker — brokers VCF SSO; embedded in vCenter or 3-node appliance cluster.
• VCF Single Sign-On models — Fleet-Wide SSO, Cross VCF Instance SSO, Single VCF Instance SSO.
• VPC (Virtual Private Cloud) + NSX Transit Gateway — tenant-oriented networking constructs now manageable from vSphere Client.
• VCF Automation Organization types — All Apps Organizations vs. VM Apps Organizations.
• vSphere Supervisor deployment modes — Single-Zone, Multi-Zone (3 vSphere Zones), Single Host, Easy Supervisor (simplified PoC).
• vSphere Zones — boundaries mapping to vSphere clusters, tagged as Management and/or Workload zones.
• Simplified Supervisor Model — single control plane VM, single vNIC, no load balancer.
• Continuous Availability VCF Operations Model — pair of nodes across two AZs (<10 ms).
• Native logging in VCF Operations 9.0 — new product-internal logging solution; optional alternative to deploying VCF Operations for Logs.
• Marketplace plug-in — for downloading/installing management packs.
• Custom Management Pack Builder — design/test/install custom packs via JSON/XML REST APIs.
• Diagnostic Findings — consolidated known issues + VMSA-based security exposures + best practices.
• Log Assist — uploads support bundles directly to Broadcom Support from VCF Operations.
• Configuration Management with Git repository integration for template versioning.
• Unified non-disruptive TLS certificate management with auto-renewal for VMCA, MSCA, OpenSSL and external CAs.
• VCF Business Services console (vcf.broadcom.com) for subscription license management, usage analytics, and contract management.

4. Licensing — 5.2 vs 9.0

5. UI consolidation — where each workflow lives

6. Networking changes

• NSX Manager mode removed: VCF 9.0 is Policy-only. Any Manager-mode constructs from earlier NSX versions must be converted to Policy objects before upgrade (NSX Promote or manual Policy re-creation).
• VPC and VPC Subnets — new NSX-native tenant networking constructs usable directly from vSphere Client.
• Distributed Connectivity — a new alternative to Centralized Connectivity that does not require Edge nodes for east-west segments; VLAN-backed transit gateway option.
• Simplified Edge workflow — max 10 Edge nodes per Edge cluster (min 2) in the vCenter simplified workflow.
• Edge-node password management — VCF can now auto-manage Edge CLI/Root passwords during Edge cluster creation/import.

7. Storage changes

• vSAN ESA is default; vSAN OSA remains supported but is no longer the primary recommendation.
• vSAN Max becomes vSAN Storage — storage-only cluster type providing remote datastore to ESA or Compute clusters.
• New vSAN Compute stretch cluster type — consumer of a remote stretched vSAN datastore; no local witness; symmetric/asymmetric topology with site affinity.
• Stretched cluster expansion now available via API for ESA, OSA, Compute, and Storage cluster types.
• Multi-rack L3 vSAN HCI cluster deployment via API (greenfield in 9.0).
• vVols deprecated — critical bug fixes only in 9.0, future removal announced. Plan exits now.

8. Domain & workload management changes

• Import Existing vCenter workflow enhanced — NSX Federation Local Manager import in 9.0.1+; DFW auto-enables on DVPGs.
• vSphere Supervisor can now be activated directly at WLD creation (requires Centralized Connectivity).
• Configuration Drift sync via VCF Operations reconciles out-of-band changes (formerly SDDC-Manager-Repository-driven).

  - VCF Operations API Explorer (Developer Center → APIs & SDKs) now hosts the SDDC Manager API and is the primary path for LACP, L3 multi-rack, and stretched cluster operations.

9. Upgrade path from VCF 5.2 to 9.0

• Target version: 9.0 directly from 5.2.x is supported if the management domain is at 5.2 and all VI WLDs are at 5.2 (or within a supported Mixed-BOM window documented in the 9.0 Release Notes).
• Review the new licensing model: you must register with the VCF Business Services console (vcf.broadcom.com) and convert per-component keys to subscription licenses.
• Ensure all NSX objects are in Policy mode; convert any remaining Manager-mode objects before upgrade.
• Evaluate vVols usage and plan an exit (deprecated).
• Budget for VCF Installer, new VCF Operations / Automation footprints, and Identity Broker cluster.
• Validate hardware for vSAN ESA default (NVMe TLC, 25-GbE, 512 GB RAM per host).

  - Upgrade sequence (high level): SDDC Manager → VCF Installer (new) / VCF Operations fleet deployment → Identity Broker → per-instance upgrades following the same management-domain-first rule → migrate workflows from SDDC Manager UI to VCF Operations Console → decommission old SDDC Manager UI roles.

• Post-upgrade: re-test every Day-2 workflow in its new location (host commissioning in vSphere Client; license mgmt in VCF Ops/Business Services; VPC via vSphere Client).

10. Breaking changes & removed features

• SDDC Manager UI is deprecated as the fleet control plane; scripts and runbooks that depend on its workflow endpoints must be ported.
• NSX Manager mode is removed — Policy mode only.
• vVols is deprecated (critical bug-fix only; future removal announced).
• Per-component 25-char license keys retire in favour of subscription license files.
• "SDDC" as a management construct is replaced by the VCF Instance + VCF Fleet taxonomy.
• "ESXi" rebrands to "ESX" in all product names and CLI paths where applicable.
• "Cloud Builder" is replaced by "VCF Installer" — retain existing Cloud Builder OVAs only for rebuild of 5.2 instances.
• Remote Clusters are rebranded as VCF Edge with new minimums — some 5.2 remote-cluster designs must be re-validated against 9.0 Edge sizing.
• Tanzu Kubernetes Grid (TKG) is now VKS under vSphere Supervisor Platform — plan Kubernetes namespace continuity carefully.
• Stateless Auto Deploy ESX hosts have no evaluation period in 9.0 — must be licensed immediately.

11. Migration design guardrails (what to tell customers now running 5.2)

• Every new VCF 5.2 deployment should assume a 9.0 migration within 24 months — stage the design for it: plan DNS/IP for Identity Broker cluster, plan hardware refresh to vSAN ESA NVMe, avoid new vVols deployments, standardise on NSX Policy-mode workflows.
• Design Aria deployments with name-agnostic integrations (avoid hard-coding "Aria Operations" endpoints in monitoring scripts) — renaming to VCF Operations will break them.
• Audit license entitlement — ensure Broadcom Support account can sign into vcf.broadcom.com.
• Define a documented "day-2 handoff map" for every operational runbook so the team knows which workflows are in SDDC Manager UI today vs. where they will live post-upgrade (vSphere Client / VCF Ops Console / VCF Business Services).
• If running NSX Federation, review the 9.0 Federation Local Manager import changes (9.0.1+).

  - If running vSphere with Tanzu, plan the TKG → VKS transition using the documented Supervisor upgrade model.

Reference documentation: VCF 9.0 Documentation Portal · VCF 9.0 Deployment & Upgrade Guide · VCF Business Services console.

Version Comparison

Key Takeaways

• VCF 5.2 is the mandatory stepping stone to VCF 9.0 (no skip to 6/7/8)
• Pre-upgrade checklist: VUM baselines cleared, snapshots removed, vSAN health green, NSX backup taken
• HCX is the recommended tool for workload migration between VCF instances
• Brownfield adoption: convert existing vSphere to VCF using Import Workload Domain workflow

VCF 5.2 Deep Dive: VCF 5.2 Design Patterns & Blueprints#

VCF 5.2 Design Patterns & Blueprints VCF 5.2

The VCF 5.2 Design Guide organises every architectural decision into Requirements (REQD — mandatory; deviations not permitted) and Recommendations (RCMD — best practice; deviations permitted with justification). Each decision is tracked with an ID like VCF--REQD--. This section enumerates the design blueprints, the key decision catalogues, and the design patterns for multi-rack and dedicated Edge deployments.

1. Decision ID taxonomy

2. Core network-design decisions (leaf-spine)

• VCF-NET-REQD-CFG-001: Do not use EtherChannel (LAG, LACP, or vPC) for ESXi host uplinks.
• VCF-NET-REQD-CFG-002: Use VLANs to separate physical network functions.
• VCF-NET-REQD-CFG-003: Configure VLANs as members of an 802.1Q trunk.
• VCF-NET-REQD-CFG-004: Set MTU to at least 1,700 bytes on physical ports, vDS, vDS port groups, and N-VDS switches for Overlay (Geneve), vSAN and vMotion. Geneve absolute minimum is 1,600; 1,700 provides growth; 9,000 recommended jumbo frames.
• VCF-NET-L3MR-REQD-CFG-001: For multi-rack compute VI workload-domain clusters, provide separate VLANs per rack for host management, vSAN, vMotion and host overlay.
• VCF-NET-L3MR-REQD-CFG-002: Subnets per rack must be routable and reachable between leaf switches.
• VCF-NET-REQD-CFG-005 (Federation): Set RTEP MTU to at least 1,500 (1,700 preferred, 9,000 recommended) between instances.
• VCF-NET-REQD-CFG-006 (Federation): Inter-instance latency < 500 ms.
• VCF-NET-REQD-CFG-007 (Federation): Provide routed connection between NSX Manager clusters; unique routable IPs per fault domain.
• Host-to-ToR uplink speed: recommended 25-GbE or higher; 10-GbE minimum; dedicated Edge cluster recommends 100-GbE per ToR.

3. vSAN design — key decisions

• VCF-VSAN-REQD-CFG-001: Provide sufficient raw capacity for the workload domain's initial need.
• VCF-VSAN-REQD-CFG-002: Provide the required minimum number of hosts per cluster type.
• VCF-VSAN-REQD-CFG-003 (ESA): Verify all hardware on vSAN HCL.
• VCF-VSAN-MAX-REQD-CFG-001: At least four nodes for the initial vSAN Max cluster.
• VCF-VSAN-REQD-CFG-004 (Stretched): Add Site disaster tolerance = Site mirroring – stretched cluster to the default vSAN storage policy.
• VCF-VSAN-REQD-CFG-005 (Stretched): Two fault domains (one per AZ); assign each host to its AZ fault domain.
• VCF-VSAN-REQD-CFG-006 (Stretched): Create an individual vSAN storage policy per stretched cluster.
• VCF-VSAN-WTN-REQD-CFG-001..006: Deploy witness appliance in a third location; size to required cluster capacity; connect its first VMkernel to the witness-site management network; static IP; DNS forward/reverse; internal NTP sync.
• VCF-VSAN-L3MR-REQD-CFG-001: Configure vSAN fault domains per rack in L3 multi-rack clusters.
• VCF-VSAN-ESA-L3MR-REQD-CFG-001: Minimum 4 racks for L3 multi-rack ESA clusters.

4. vSphere (ESXi + vCenter) decisions

• VCF-ESX-REQD-CFG-001..002: Install at least the minimum number of ESXi hosts; verify each host matches the required CPU/memory/storage spec.
• VCF-ESX-REQD-SEC-001: Regenerate each ESXi host's certificate after assigning its FQDN.
• VCF-ESX-RCMD-CFG-001: Use vSAN ReadyNodes for every management-domain host.
• VCF-ESX-RCMD-CFG-002: Homogeneous hardware across the default management cluster.
• VCF-ESX-RCMD-CFG-003: Size CPU by physical cores only — do not count hyperthreading.
• VCF-ESX-RCMD-CFG-004: Boot device ≥ 128 GB.
• VCF-ESX-RCMD-NET-001..002: Separate host management VLAN from VM management VLAN.
• VCF-VCS-REQD-CFG-001: Dedicated vCenter appliance for the management domain of each VCF instance.
• VCF-VCS-REQD-SSO-STD-001: Join all vCenter instances within the VCF instance to a single SSO domain (max 15).
• VCF-VCS-REQD-SSO-STD-002: Create a ring topology between vCenter instances (ELM).
• VCF-VCS-REQD-SSO-ISO-001: Isolated WLDs each in their own SSO domain (up to 25 WLDs per instance).
• VCF-VCS-RCMD-CFG-001..005: Default Small for mgmt domain, Medium for VI; protect with vSphere HA (restart priority = high); add appliance to first-AZ VM group for stretched clusters.
• HA-only policy: vCenter HA and vSphere FT are NOT supported for VCF-managed vCenters — only vSphere HA.

5. NSX decisions

• VCF-NSX-LM-REQD-CFG-001..002: NSX Manager cluster on VM management network; three nodes in the default mgmt cluster.
• VCF-NSX-LM-RCMD-CFG-001..006: Appropriately sized nodes, VIP on shared L2, DRS anti-affinity, HA high restart priority; for stretched, VM group for first AZ.
• VCF-NSX-EDGE-REQD-CFG-001..004: Edge management on VM management network; two pNICs (vmnic0, vmnic1) with fp-eth0/1 pinned (failover); dedicated edge overlay VLAN distinct from host overlay; uplink profile with three teaming policies (default = load balance source both active, named = failover uplink1 only, named = failover uplink2 only).
• VCF-NSX-MR-EDGE-REQD-ENV-001 / CFG-001: Place ≥1 Edge VM per Edge cluster onto each vSphere cluster in a separate rack; connect each Edge management interface per rack to the VM management network.
• VCF-NSX-OVERLAY-REQD-CFG-001..005: All ESXi hosts as transport nodes using TNPs; MTU ≥ 1,600 for Geneve; single overlay TZ per NSX instance.
• VCF-NSX-AVN-REQD-CFG-001..005: Create one cross-instance NSX segment for mobile Aria components; local-instance segments per VCF instance; in Federation extend the cross-instance segment and migrate local-instance segments to local-instance Tier-1 gateways.
• VCF-NSX-AVN-RCMD-CFG-001: Use overlay-backed AVNs with eBGP between DC fabric and Edge nodes.
• VCF-NSX-LB-REQD-CFG-001..007: Deploy a standalone Tier-1 gateway for load balancing AVNs; connect to the cross-instance segment; in Federation deploy cold-standby in second instance and plan manual LB-rule sync.
• VCF-NSX-BGP-REQD-CFG-001..012: ECMP between Tier-0 and L3 devices via two VLANs; named teaming policies; VLAN TZ for edge uplink; Tier-1 in active-standby; stretched ECMP requires IP prefix list + route-map out with AS-path prepend (local AS twice) + route-map in for default route with lower local-preference.
• Required BGP timers — keep-alive 4 s, hold-down ≤ 12 s.

6. Routing & operating models

7. SDDC Manager, Aria Suite Lifecycle, Workspace ONE Access

• VCF-SDDCMGR-REQD-CFG-001..003: Deploy SDDC Manager in the first AZ of the management domain, default config, on VM management network.
• VCF-SDDCMGR-RCMD-CFG-001..004: Internet or authenticated proxy for depot; VMware Customer Connect / Broadcom Support account with VCF entitlement; external CA for certificates.
• VCF-VASL-REQD-CFG-001..002: Deploy Aria Suite Lifecycle per VCF instance in the management domain via SDDC Manager.
• Global Environment — contains Workspace ONE Access (required before deploying Aria Automation).
• VCF Mode — infrastructure inventory retrieved from SDDC Manager, deployments synced back (limited to one instance of each Aria product).
• Standalone Mode — manually-entered infra, multiple product instances allowed.

  - Global Environment → VCF Mode, Cross-instance Logical DC, Workspace ONE Access.
  - Cross-instance → Aria Operations analytics/collector + Aria Automation cluster.
  - Each instance → Aria Operations for Logs cluster per VCF instance.

• Workspace ONE Access clustered LB config: monitor URL /SAAS/API/1.0/REST/system/health/heartbeat, HTTP 200 OK; LEAST_CONNECTION algorithm; HTTP 1.1; SNAT Auto Map; JSESSIONID cookie persistence (rewrite mode); L7 HTTP VS on port 443; application profile timeout 3,600 s with X-Forwarded-For insert.
• Workspace ONE Access integrations: supported with NSX; not supported directly with vCenter or SDDC Manager (they use vCenter SSO).

8. Information Security decisions — access & accounts

9. Information Security decisions — certificates

• VCF-SDDC-RCMD-SEC-001: Replace VMCA-signed certs on all management appliances with internal-CA-signed certs.
• VCF-SDDC-RCMD-SEC-002: Use SHA-2 or higher.
• VCF-SDDC-RCMD-SEC-003: Perform SSL cert LCM for all mgmt appliances via SDDC Manager or Plug-in.

10. Reference topology blueprints (Rainpole)

All blueprints use the same default design-elements catalogue (External Services, Leaf-Spine, Management Domain, Aria Suite Lifecycle, Workspace ONE Access, LCM, Account + Cert Management). Blueprints 3 and 5 add the Stretched Clusters addendum. Blueprints 4 and 5 add the NSX Federation addendum. Each blueprint is fully parameterised in the Rainpole reference deployment.

11. Cluster & Edge design patterns

Design Pattern — Multi-Rack Compute VI Workload Domain Cluster

Deploy a compute cluster spanning multiple racks with vSAN storage and a Layer-3 network fabric, providing rack-level resiliency. Architecture: Standard; Workload domain: VI; Cluster-to-rack: spans multiple racks; Physical network: Leaf-Spine. Applies the L3-multi-rack variants of Physical Network, vSAN, vSphere Cluster, vSphere Networking, and Overlay decision sets.

Design Pattern — Dedicated Edge Scale and Performance

Deploy an NSX Edge cluster on its own dedicated vSphere cluster for maximum performance with a consistent bandwidth budget to north-south traffic. Architecture: Standard; Workload domain: VI; Topology: Single Instance Single AZ (can combine with multi-rack Edge for Multi-Instance Single AZ). Applies the Leaf-Spine Dedicated-Edge and vSphere Networking Dedicated-Edge decision sets.

Design Pattern — Multi-Rack Edge Availability

Deploy an NSX Edge cluster with Edge VMs on two dedicated vSphere clusters in two independent racks for rack-level resiliency. Architecture: Standard; Workload domain: VI; Topology: Single Instance Single AZ. Applies the multi-rack Edge Node and BGP Routing decision sets (VCF-NSX-MR-EDGE-, VCF-NSX-MRE-BGP-).

12. Authoritative design-blueprint study notes (from VCF 5.2 documentation)

VCF 5.2 Design Blueprints, Topologies, and Patterns VCF 5.2

Four supported deployment topologies

• Single Instance - Single Availability Zone: one VCF instance, one AZ; baseline for SMB and tier-2 workloads.
• Single Instance - Multiple Availability Zones: stretched management and (optionally) VI clusters across two AZs within a metro.
• Multiple Instances - Single AZ each: two or more independent VCF instances (DC+DC). Usually paired with NSX Federation for unified policy.
• Multiple Instances - Multiple AZ: maximum resiliency; each instance internally stretched, and all instances federated.

Five Rainpole reference design blueprints

Architecture models

• Standard: separate management vs VI WLDs. Baseline for VCDX-level design.
• Consolidated: management and initial workloads share the management cluster. Constrained by 2:1 CPU ratio; acceptable for small environments only; split into standard as scale grows.

Cluster design patterns

• Default management cluster: vSAN (greenfield) or NFS v3 / VMFS-FC / VMFS-FCoE (converted via Import Tool in 5.2.1+). Min 4 hosts (3 in 5.2.1+).
• Additional management cluster: for Aria Suite, Avi Controllers, or migration staging. Principal storage flexible.
• VI workload domain cluster: tenant-facing. Principal vSAN / NFS v3 / VMFS-FC / vVols.
• Stretched cluster: OSA only in VCF 5.2; 8-host minimum for management default multi-AZ.
• vSAN Max cluster: ESA-only storage cluster, 4–24 hosts, 104 compute-only hosts via HCI Mesh; not for management default cluster.
• Remote cluster: external storage, 2–16 hosts, 100 ms / 10 Mbps budget.
• Dedicated Edge cluster: 100-GbE host-to-ToR, separate from compute; Large Edge VMs for production L7 LB; up to 10 Edge nodes per cluster.

vDS profile options (bring-up)

• Profile 1: 2 × 10 GbE uplinks with all traffic types on a single vDS.
• Profile 2: 4 × 10 GbE — management/vSAN on one vDS, vMotion/NSX on another.
• Profile 3: 2 × 25 GbE (or 2 × 100 GbE) high-throughput single vDS.

NIOC (Network I/O Control) default share values

Multi-rack design

• Dedicated Edge cluster on a separate rack requires host-to-ToR 100 GbE and a routed overlay.
• Compute VI workload domains span racks using the leaf-spine design; all VLANs routed to every rack.
• Cluster-to-rack mapping must keep vSAN failure domains intact — prefer “one cluster per rack” or define rack-aware fault domains.

Identity provider constraints (VCF 5.2)

• Only ONE external IdP at a time: ADFS, Okta, or Microsoft Entra ID.
• Okta and Entra require vSphere 8.0 U2+ and NSX 4.1.2+.
• AD over LDAP / OpenLDAP is an identity source added to vCenter SSO, not a full external IdP.
• Workspace ONE Access clustered = 3 nodes behind NSX LB VIP; requires 5 IPs on the cross-instance segment.

13. Sizing reference at a glance (from the Design Guide)

14. HA admission control & overcommit (design reminders)

• Management domain CPU overcommit: vCPU:pCPU ≤ 2:1.
• VI workload domain CPU overcommit: vCPU:pCPU ≤ 8:1.
• vSAN free-space floor: 30%.
• Anti-affinity for 3-node management VM clusters requires at least 4 physical hosts underneath.

Reference documentation: VCF 5.2 Design Guide — Design Elements Summary · NSX 4.2 Documentation · vSAN 8.0 Documentation.

Key Takeaways

• Consolidated architecture: management + workload on same cluster (minimum 3 hosts, max ~100 VMs)
• Standard architecture: separate management and workload domains (recommended for production)
• Multi-AZ design: stretch clusters across availability zones with vSAN stretched cluster
• Network design: minimum 2 vDS (management + workload), VLAN-backed or overlay (NSX) segments