SDDC Manager Bring-up vs VCF 9.0 Fleet Manager Deployment

Deploy the Cloud Builder OVA to your VCF 5.2 lab environment. From vSphere Client on the physical ESXi host, right-click the management datastore and select 'Upload Files' or use vSphere OVA import wizard. Deploy the Cloud Builder OVA (typically ovftool or direct vSphere import). Power on the VM and wait for the service to initialize (5-10 minutes). Obtain the Cloud Builder IP from the console or DHCP lease.

Access the Cloud Builder UI: open a browser and navigate to https://<cloud-builder-ip>. Log in with admin@local and the password from your DPW. You should see a wizard prompting you to upload or fill in deployment parameters.

Upload the DPW (or fill in the bring-up spec form if DPW upload isn't available). Navigate to the bring-up parameters section and either: (a) click 'Upload DPW' and select your Excel file, or (b) manually fill in the form fields. Cloud Builder will parse and validate the DPW. Wait for validation to complete (2-5 minutes). If validation passes, you will see a green checkmark.

Start the bring-up process: click the 'Start Bring-up' or 'Deploy' button. Cloud Builder will immediately begin the orchestrated deployment sequence. Watch the progress tracker in the Cloud Builder UI. Major milestones (in order): (1) ESXi host configuration + vSAN cluster creation (10-20 min), (2) SDDC Manager VM deployment + initialization (15-25 min), (3) vCenter VM deployment + registration to SDDC Manager (10-15 min), (4) NSX Manager VM deployment + integration (10-20 min), (5) Host commissioning + cluster completion (10-15 min). Total time: 60-90 minutes.

Upon completion, verify the SDDC Manager deployment by navigating to the SDDC Manager UI: https://<sddc-manager-fqdn>. Log in with administrator@vsphere.local and the password from the bring-up spec. Confirm the management domain is listed with status 'Active'.

Document the post-bring-up surface. In SDDC Manager, navigate to: (1) Inventory > Workload Domains (should show 1 management domain), (2) Inventory > Hosts (should show 4 ESXi hosts, all commissioned), (3) Inventory > Clusters (should show 1 cluster with vSAN enabled), (4) Infrastructure > Licensing (should show management domain and workload domain licenses), (5) Administration > System Configuration > Services (should show all services running). Take a screenshot of each screen.

Download the VCF 9.0 Installer media (ISO or OVA) from Broadcom support portal. The Installer is the entry point for VCF 9.0 bring-up. It provides a web UI for defining VCF Instances and drives the full deployment workflow. Deploy the Installer OVA to your VCF 9.0 lab physical ESXi host using the same process as Cloud Builder. Power on and obtain its IP from DHCP.

Access the VCF Installer UI: https://<installer-ip>. Log in with admin and the default password (usually 'vmware' or as specified in Installer docs). You should see a welcome wizard prompting you to create a new VCF Instance.

Create a new VCF Instance: click 'Create New Instance' and fill in the Instance definition form. Unlike VCF 5.2's DPW (Excel), VCF 9.0 uses a JSON-based Instance definition. The form will guide you through: (1) Instance name (e.g., 'prod-instance-01'), (2) Management domain FQDN (e.g., 'md.vcf.lab'), (3) ESXi host count and sizing (4 hosts, 12 vCPU, 96 GB RAM each minimum), (4) vSAN configuration (FTT=1), (5) NSX Manager specification (3 nodes HA or single node for lab), (6) vCenter instance settings, (7) Licensing information. Complete all required fields.

Validate the Instance definition: click 'Validate' and wait for the Installer to check all parameters. This validation is more comprehensive than VCF 5.2's DPW validation: it checks IP reachability, FQDN DNS resolution, network connectivity, and physical ESXi host capacity. If all checks pass, you will see green status indicators.

Start the Instance deployment: click 'Deploy Instance'. The Installer will execute the bring-up sequence similar to Cloud Builder, but with a different orchestration engine. Watch the progress tracker. Major milestones: (1) Pre-flight checks on all ESXi hosts (10 min), (2) Nested ESXi deployment (if using nested labs) OR host commissioning (if using physical hosts), (3) vCenter deployment via OVA, (4) NSX Manager deployment and cluster formation, (5) VCF Fleet Manager initialization, (6) VCF Operations UI startup, (7) License activation. Total time: 60-120 minutes.

Upon completion, verify the Fleet Manager and VCF Operations deployment. The Installer UI will display URLs for: (1) Fleet Manager UI (https://<fleet-manager-ip>), (2) VCF Operations UI (https://<operations-ip>). Navigate to Fleet Manager and log in with admin@local and the password from the Instance definition. Verify your Instance is listed and shows status 'Running' or 'Healthy'.

Create a comparison spreadsheet with three columns: (1) Operational Task, (2) VCF 5.2 SDDC Manager, (3) VCF 9.0 Fleet Manager / Operations. List the following operational tasks: (a) View management domain status, (b) Commission a new ESXi host, (c) Create a workload domain, (d) View licensing status, (e) Check system health and alarms, (f) Perform a VCF upgrade, (g) Access vCenter, (h) Access NSX Manager, (i) View audit logs, (j) Configure LDAP/SAML.

In your VCF 5.2 SDDC Manager UI (from Task 2), navigate to each operational task and document the exact menu path and UI elements. For example: (a) View management domain status: Inventory > Workload Domains > management, (b) Commission a new host: Infrastructure > Hosts > add host, etc. Fill in column 2 of your spreadsheet with these paths.

In your VCF 9.0 Fleet Manager + VCF Operations UI (from Task 3), navigate to the equivalent tasks and document the new menu paths. Be prepared to find that some tasks have moved or been consolidated. For example: (a) View management domain status: VCF Operations > Inventory > Instance > Details, (b) Commission a new host: VCF Operations > Infrastructure > Hosts > Add Host, etc. Fill in column 3 of your spreadsheet.

For each task, note which console is used in VCF 9.0: (a) Fleet Manager (for Instance management), (b) VCF Operations (for Day 2 operations), (c) vCenter (for VM management, unchanged), (d) NSX Manager (for network operations, unchanged). Compare to VCF 5.2, where SDDC Manager is the primary console for most operations.

Now examine the API/CLI differences. VCF 5.2 uses REST APIs under the SDDC Manager endpoint (https://sddc-manager.lab/api/v1/). VCF 9.0 splits APIs: Fleet Manager (https://fleet-manager.lab/api/v1/) for Instance management, VCF Operations (https://operations.lab/api/v1/*) for Day 2, and vCenter/NSX unchanged. Test an API call from each version. Example: VCF 5.2: curl -X GET https://sddc-manager/api/v1/workload-domains -H 'Authorization: Bearer <token>'. VCF 9.0: curl -X GET https://operations/api/v1/instances/<instance-id>/domains -H 'Authorization: Bearer <token>'. Document the endpoint structure differences.

Create a summary document comparing the two architectures: (1) Control plane location: VCF 5.2 (Cloud Builder + SDDC Manager, self-contained), VCF 9.0 (external Installer + Fleet Manager + VCF Operations, distributed). (2) Orchestration: VCF 5.2 (synchronous, single bring-up flow), VCF 9.0 (asynchronous, multi-Instance support). (3) Operational model: VCF 5.2 (single domain focus), VCF 9.0 (multi-domain, multi-Instance). (4) API design: VCF 5.2 (monolithic SDDC Manager API), VCF 9.0 (distributed APIs by function). (5) Day 2 implications: Document 3 specific operational differences you observe (e.g., upgrade workflows, licensing, multi-site management).

Define the three key design decisions that led to the Fleet/Instance model: (1) Reusability: A single Fleet Manager can orchestrate multiple VCF Instances across different sites or customers (multi-tenancy in SaaS scenarios). (2) Day 2 Automation: By separating Instance definitions from operational controls, VCF 9.0 enables templated Instance deployments and infrastructure-as-code patterns. (3) Upgrade Pathing: Fleet Manager can upgrade Instances independently, allowing rolling upgrades or phased rollouts. For each decision, write 2-3 sentences explaining the benefit and any trade-off (e.g., increased operational complexity, need for new training).

Outline a migration path from VCF 5.2 to 9.0 for a hypothetical organization running 3 VCF 5.2 domains (1 management + 2 workload domains). Specify the steps: (1) Deploy VCF 9.0 Installer and Fleet Manager in parallel with VCF 5.2 environment, (2) Migrate workload domain data (VMs, policies, etc.) via vCenter API or Migration Toolkit, (3) Validate workload in VCF 9.0, (4) Decommission VCF 5.2. For each step, estimate the downtime and risk level. Document any data that cannot be migrated automatically (e.g., custom SDDC Manager configurations, NSX policies) and require manual re-creation.

Compare the licensing models: VCF 5.2 uses per-instance licensing (one license per SDDC Manager). VCF 9.0 uses fleet-based licensing (one fleet license covers all Instances under a Fleet Manager, but with per-workload-domain entitlements). Document the license cost implications: Does VCF 9.0 cost more or less for a multi-Instance environment? What about a single Instance? Write a cost comparison for 1x, 3x, and 5x Instance scenarios.

Identify three workload profiles where VCF 9.0's Fleet/Instance model is superior to VCF 5.2, and three where VCF 5.2 might still be better (or where the choice is neutral): (a) Superior in VCF 9.0: (i) Service provider managing multiple customer VCF environments (fleet-level isolation and multi-tenancy), (ii) Enterprise with planned multi-site disaster recovery (per-Instance upgrades enable staggered rollouts), (iii) Rapid infrastructure scaling (templated Instance definitions enable faster provisioning). (b) VCF 5.2 may be preferable: (i) Small single-site deployments (operational simplicity), (ii) Organizations deeply invested in SDDC Manager API automations (potential re-training cost), (iii) Environments requiring extensive custom SDDC Manager configuration (less well-documented migration path in 9.0). Document the trade-offs.

Create a RCAR (Requirements, Constraints, Assumptions, Risks) analysis for deploying VCF 9.0 Fleet Manager at a new customer site (as opposed to SDDC Manager in VCF 5.2). (a) Requirements: Fleet Manager must support 5+ Instances, multi-LDAP domain authentication, per-Instance upgrade capability. (b) Constraints: Physical infrastructure limited to 3 datacenters; bandwidth between sites limited to 1 Gbps. (c) Assumptions: Customer has existing Okta OIDC IdP; VCF Automation will be used (not required for basic fleet). (d) Risks: Fleet Manager is relatively new (9.0.x) — potential for undiscovered bugs; migration from competitor's infrastructure may have data loss risks.