6.1 VCF Fleet Management & Existing vCenter Import Workflows

6.1 VCF Fleet Management & Existing vCenter Import Workflows

Exam Focus: In VMware Cloud Foundation (VCF) 9.0, infrastructure management transcends the boundaries of a single software-defined data center. For the VCP-VCF (2V0-17.25) exam, candidates must master the Multi-Instance Fleet Management architecture, understand how distributed SDDC Manager instances federate for centralized governance, and thoroughly understand the brownfield migration workflow executed via the VCF Import tool. You must know the mandatory network normalization prerequisites, the execution stages of the validation engine, and the immutable architectural rule that brownfield import applies exclusively to Virtual Infrastructure (VI) Workload Domains.

[!IMPORTANT] Where this lives in VCF 9.0. Broadcom moved the fleet-wide management surface in VMware Cloud Foundation 9.0. VCF Operations provides the fleet management capabilities — fleet extension, lifecycle, certificate, and password management. SDDC Manager still exists as a per-instance component and can still perform several of these tasks, but the SDDC Manager UI is deprecated and is slated for removal in a future major release, its lifecycle management APIs have moved to VCF Operations, and its identity-configuration APIs are deprecated in favour of VCF Operations. When an exam item asks where a fleet-wide task is performed in 9.0, VCF Operations is the current answer; treat SDDC Manager as the legacy surface that remains for compatibility.

---

VCF 9.0 Multi-Instance Fleet Management Architecture

As enterprise organizations expand their hybrid and private cloud footprints across multiple regional data centers, edge locations, and sovereign boundaries, managing independent Cloud Foundation instances as isolated operational islands becomes untenable. In legacy deployments (VCF 4.x and early 5.x), administrators were forced to log into distinct SDDC Manager consoles, coordinate manual software version alignment, and aggregate capacity metrics through disparate spreadsheets or external monitoring tools.

VMware Cloud Foundation 9.0 introduces Multi-Instance Fleet Management, elevating multi-instance federation into a native, cloud-scale operating model. Fleet Management delivers centralized governance, global inventory visibility, and unified lifecycle tracking across multiple distributed VCF instances through a single-pane-of-glass administrative interface.

Federated Control Plane Topologies

The Fleet Management architecture operates on a federated control plane topology:

• Primary / Controller SDDC Manager: Acts as the central administrative aggregation point. The controller instance hosts the global fleet dashboard, aggregates health telemetry, orchestrates multi-site compliance audits, and maintains global licensing visibility.
• Member SDDC Manager Instances: Geographically dispersed SDDC Manager deployments that join the fleet federation. Each member instance maintains autonomous local control over its local Management Domain and VI Workload Domains, ensuring that a wide-area network (WAN) partition between sites does not disrupt local workload execution or local cluster management.
• Mutual TLS (mTLS) Secure Channel: Inter-instance communication between the controller and member SDDC Managers is secured using mutual TLS authentication. Public key infrastructure (PKI) certificates are exchanged during the federation joining workflow, establishing a cryptographically encrypted RESTful communication channel over TCP port 443.

Multi-Instance Fleet Control Plane Topology:

   ┌────────────────────────────────────────────────────────┐
   │      Primary SDDC Manager (Fleet Controller)           │
   │   - Global Inventory View    - Consolidated Licensing  │
   │   - Fleet-Wide Health        - Compliance Baselines    │
   └───────────────▲────────────────────────▲───────────────┘
                   │                        │
         mTLS (TCP 443)           mTLS (TCP 443)
                   │                        │
   ┌───────────────▼────────┐      ┌────────▼───────────────┐
   │ Member SDDC Manager 01 │      │ Member SDDC Manager 02 │
   │   (Datacenter Alpha)   │      │   (Datacenter Beta)    │
   │  Local Mgmt + VI WLDs  │      │  Local Mgmt + VI WLDs  │
   └────────────────────────┘      └────────────────────────┘

Core Fleet Management Capabilities

1. Global Aggregated Inventory: The fleet controller discovers and continuously synchronizes inventory metadata across all federated sites. Cloud administrators can query the global inventory to locate specific virtual machines, clusters, physical ESXi hosts, or NSX edge clusters regardless of the physical datacenter hosting the resource.
2. Consolidated Licensing Governance: VCF 9.0 integrates enterprise subscription license keys and capacity pools across the entire fleet. Administrators can monitor global core usage against purchased capacity, track license consumption trends across business units, and identify impending license expirations from a single interface.
3. Fleet-Wide Lifecycle Coordination: While local SDDC Managers execute the actual rolling component updates, the fleet management plane allows administrators to schedule synchronized maintenance windows, assess version currency across all instances, and identify sites that have fallen behind the corporate Bill of Materials (BOM) standard.
4. Aggregated Alerting and Health Telemetry: Critical system alarms, hardware degradations, and configuration anomalies are rolled up to the global fleet view, enabling site reliability engineering (SRE) teams to detect recurring systemic issues across disparate physical locations.

---

Brownfield Migration & The VCF Import Tool

A primary hurdle in enterprise cloud adoption has historically been the "greenfield mandate." Prior to modern migration tooling, adopting VMware Cloud Foundation required deploying completely new, greenfield physical clusters using the installer appliance, followed by complex, time-consuming cross-vCenter vMotion operations or storage-level replications to move workloads out of existing legacy environments. For organizations managing thousands of production virtual machines across heavily utilized vSphere clusters, the associated downtime risks, physical hardware duplication costs, and network re-architecting made platform modernization prohibitive.

To eliminate this friction, VMware introduced and matured the VCF Import capability (integrated directly into SDDC Manager in VCF 5.2 and 9.0). VCF Import provides an automated, in-place conversion workflow that discovers existing standalone vSphere 8.x environments and unmanaged vCenter Server instances, validates their configuration against Cloud Foundation architectural standards, and assimilates them into VCF as fully managed Virtual Infrastructure (VI) Workload Domains—without requiring virtual machine migrations, compute rebuilds, or workload disruption.

---

Architectural Prerequisites & Network Normalization

Before a standalone vCenter Server and its associated vSphere clusters can be converted into a VCF VI Workload Domain, the source environment must satisfy stringent technical prerequisites and undergo network normalization.

Baseline Software & Environment Prerequisites

• Target Software Version: The existing standalone vCenter Server and all ESXi hosts within the candidate clusters must run supported vSphere releases (vSphere 8.0 Update 2 or later, aligned with the target VCF 9.0 Bill of Materials). Environments running legacy vSphere 7.x must be upgraded prior to initiating import.
• DNS and NTP Uniformity: Flawless forward (A) and reverse (PTR) DNS resolution must exist for the candidate vCenter Server, all ESXi hosts, and all management endpoints. Clock drift between the candidate vCenter, ESXi hosts, and SDDC Manager must not exceed 120 seconds; excessive time skew breaks token validation and SSL handshakes.
• Administrative Credentials: High-privilege administrative credentials (administrator@vsphere.local or equivalent) for the candidate vCenter Server, as well as root credentials for all ESXi hosts, must be available and supplied to SDDC Manager.
• Storage Architecture: Candidate clusters must utilize supported shared storage topologies. If vSAN is used, all disk groups must be healthy, running supported on-disk format versions, and governed by valid Storage Policy-Based Management (SPBM) rules. If external storage (Fibre Channel VMFS, NFS, or vVols) is utilized, the datastores must be uniformly mounted and accessible across all hosts in the cluster.

The Network Normalization Imperative

In unmanaged legacy environments, networking configurations frequently drift into bespoke, non-standard architectures. VCF enforces strict standardization to guarantee that software-defined lifecycle operations, NSX encapsulation, and vMotion networks operate reliably.

[!IMPORTANT] The Standard vSwitch (VSS) Prohibition: VMware Cloud Foundation strictly prohibits the use of legacy Standard vSwitches (VSS) for managed workload domains. Prior to initiating brownfield import, administrators must migrate all physical network adapters (vmnics), VMkernel interfaces (Management, vMotion, Storage), and virtual machine port groups from standard switches to vSphere Distributed Switches (VDS).

Network normalization requires standardizing the following parameters across all candidate hosts:

1. VDS Software Version: The distributed switch version must align with the target vSphere release.
2. Uplink Teaming and Naming: Physical uplinks must adhere to consistent teaming policies (e.g., Route Based on Physical NIC Load or Explicit Failover) and uniform naming conventions across all hosts in the cluster.
3. MTU Standardization (Jumbo Frames): The MTU across distributed switches supporting vSAN or planned NSX Geneve overlay traffic must be standardized to jumbo frames (MTU 9000). A mismatched MTU between hypervisor VMkernel interfaces and physical top-of-rack switches will cause packet fragmentation and dropped overlay packets.
4. Port Group VLAN Segregation: Management, vMotion, and storage traffic must reside on dedicated, non-overlapping VLANs with proper 802.1Q tagging.

---

End-to-End VCF Brownfield Import Workflow

The VCF Import workflow is executed directly through the SDDC Manager interface or programmatically via the VCF REST API. The procedure follows four distinct, sequential phases:

Brownfield vCenter Import Execution Phases:

┌──────────────────────┐      ┌──────────────────────┐      ┌──────────────────────┐      ┌──────────────────────┐
│ 1. Discovery & Scan  │ ───> │ 2. Automated Checks  │ ───> │ 3. Network & NSX     │ ───> │ 4. Domain Conversion │
│ - Connect to vCenter │      │ - Compute & CPU EVC  │      │ - Attach / Deploy    │      │ - Update SDDC DB     │
│ - Enumerate Clusters │      │ - Storage & Licensing│      │   NSX Manager        │      │ - Apply vLCM Image   │
│ - Discover Hosts/VDS │      │ - DNS / NTP Skew     │      │ - Prep Transport Node│      │ - Workload Domain ON │
└──────────────────────┘      └──────────────────────┘      └──────────────────────┘      └──────────────────────┘

Phase 1: Discovery and Inventory Scanning

The administrator navigates to Workload Domains > Import Workload Domain in SDDC Manager and provides the Fully Qualified Domain Name (FQDN) and administrative credentials of the target standalone vCenter Server. SDDC Manager establishes an authenticated API session, inspects the inventory hierarchy, and discovers:

• Datacenters, clusters, and individual ESXi hosts.
• Distributed virtual switches, uplink configurations, and port group mappings.
• Shared datastores (vSAN, VMFS, NFS, vVols).
• Active virtual machines and their compute resource assignments.

Phase 2: Automated Pre-Import Validation Engine

Once the inventory is scanned, SDDC Manager executes an exhaustive validation suite. The validation engine tests dozens of operational criteria to ensure the environment conforms to Cloud Foundation standards before any changes are committed:

• Compute Compatibility: Verifies that all hosts within each cluster possess compatible CPU families, uniform instruction sets (Enhanced vMotion Compatibility / EVC baselines), and sufficient memory capacity.
• Licensing Validation: Confirms that valid VCF or vSphere solution license keys are available and can be applied to the converted entities.
• Storage Policy Compliance: Verifies that all virtual disks conform to active SPBM policies and that vSAN storage pools possess adequate slack space for maintenance operations.
• Security & Certificate Validation: Inspects ESXi SSL certificates, host thumbprints, and SSH availability to ensure secure communication can be established.

If any validation check fails (e.g., clock drift exceeding 120 seconds, or a host interface remaining on a standard switch), the engine generates an explicit error report with remediation instructions. Administrators must remediate the underlying issue and re-run the validation engine until a 100% green status is achieved.

Phase 3: Network Integration and NSX Deployment

Depending on the design specification, the administrator chooses whether to:

• Deploy New NSX Infrastructure: SDDC Manager automatically deploys a dedicated NSX Manager cluster for the imported workload domain, configures transport zones, and prepares the ESXi hosts as NSX Transport Nodes using the normalized VDS.
• Integrate Existing NSX: If the brownfield vCenter already has an existing, validated NSX deployment running a supported version, SDDC Manager discovers and registers the existing NSX Manager cluster into its inventory.

Phase 4: Conversion Execution and VI Workload Domain Assimilation

With validation complete and network services aligned, SDDC Manager executes the conversion:

1. Database Registration: SDDC Manager writes the vCenter, cluster, host, and datastore metadata into its internal PostgreSQL database.
2. Lifecycle Manager Standardization: The cluster is transitioned to vSphere Lifecycle Manager (vLCM) desired-state cluster images. A target base ESXi image, vendor add-on, and NSX components are linked to the cluster definition.
3. Domain Finalization: The vCenter Server and its clusters are officially registered as a managed VI Workload Domain. All subsequent operational actions—including capacity expansion, host commissioning/decommissioning, certificate replacement, password rotation, and software upgrades—are now governed exclusively through SDDC Manager.

---

Architectural Constraints & Candidate Traps

[!IMPORTANT] The Management Domain Greenfield Mandate: A critical concept tested on the VCP-VCF exam is that an existing standalone vCenter cannot be imported to serve as the initial VCF Management Domain. The Management Domain contains the foundational Cloud Foundation control plane (SDDC Manager, Management vCenter, and Management NSX cluster) and must always be deployed greenfield using the VCF Installer. Brownfield import via the VCF Import tool applies strictly to secondary Virtual Infrastructure (VI) Workload Domains.

[!WARNING] Unsupported Brownfield Configurations: The VCF Import validation engine will immediately halt and reject clusters that contain:

• Active standard vSwitches (VSS) carrying VMkernel or production VM traffic.
• Heterogeneous ESXi CPU architectures within the same cluster lacking an active EVC baseline.
• Non-standard third-party kernel modules (VIBs) that conflict with the target VCF Bill of Materials.
• Orphaned virtual machine disks or broken storage policies that prevent vLCM image reconciliation.