Dr. Pranay Jha

In Part 12 we chose the adoption path. If your answer was converge, this is the post that turns that decision into a running management domain. And here is the thing nobody tells you up front: the VCF Installer wizard at the end is almost boring. It asks for the components it should reuse, you fill in the gaps, you click go. The week of effort lives entirely in getting your existing environment into a state the Installer will accept. Skip that framing and you will launch the wizard, hit a validation wall, and spend two days unwinding it.

So this runbook is front-loaded on purpose. We spend most of our words on assessment and remediation, because that is where converges actually succeed or fail.

What converge actually does

Converge takes a non-VCF vCenter and the ESX hosts under it and uses them as the building blocks of a new VCF management domain. The VCF Installer deploys into the same cluster as the residing vCenter, then adds whatever VCF components you do not already have: SDDC Manager, NSX, VCF Operations, and VCF Automation. The result is a fully VCF-managed instance where lifecycle, certificate, and password management now run through the platform instead of by hand. The workloads on those hosts never move. That in-place property is the whole reason to choose converge over a greenfield build plus migration.

One distinction to keep straight, because it changes the prerequisites: converge creates a new management domain. It is not the same as import, which folds a vCenter into a VCF instance you already run as a workload domain. For a VCF platform, the converge scenarios in this post apply to the management domain only. You import and upgrade additional workload domains later, from VCF Operations, after the management domain exists.

Step 1: Assess and find your blockers first

Before you touch anything, inventory the environment and check it against the supported configuration list. Most failed converges trace back to one of a small set of blockers, so look for these specifically.

• Enhanced Linked Mode (ELM). A vCenter joined in ELM cannot be converged. This is the single most common stopper. You have to break ELM first, which has real SSO consequences, covered in Step 2.
• Standard switches. You need a vSphere Distributed Switch at version 8.0 or later. Hosts running VMkernel interfaces on standard switches will not pass. Cisco virtual switches (Nexus 1000V and the like) are not supported at all.
• DRS automation level. The cluster must run fully automated DRS. Manual or partially automated DRS is rejected. This is a one-click fix but easy to miss.
• vLCM baselines. Clusters must use vSphere Lifecycle Manager images, not the older baselines. Convert baseline-managed clusters to images before you upgrade to ESX 9.0.
• Hard exclusions. Dell VxRail clusters, vCenter HA (VCHA), dynamically allocated VMkernel IP addresses, and partial cluster selection are not supported. All clusters under a vCenter convert together.

Storage and host counts matter too. A simple deployment needs a minimum of 3 ESX hosts with vSAN, or 2 hosts with external storage. A high availability deployment of VCF Operations, VCF Automation, and NSX needs a minimum of 4 hosts. Where multiple datastores exist, VCF picks the principal storage by priority: vSAN, then NFS v3, VMFS, NFS 4.1, iSCSI, and vVols last (and vVols is deprecated in version 9, so do not build on it). Starting in 9.0.1 the datastore with the most free space wins instead, and you can override the choice with the existingDatastoreName property if you converge from a JSON spec.

Step 2: Remediate and upgrade, in the right order

There is a sequence to this, and the order is not optional. Components have interdependencies, and upgrading the wrong one first can strand you. The typical full path, assuming Aria components are present, looks like this.

1. Patch Aria Suite Lifecycle. If deployed, it must be at 8.18 Patch 2 or later before a conversion is allowed.
2. Upgrade Aria Operations to VCF Operations 9.x. This becomes the operations plane of your VCF instance.
3. (Optional, separate workstream) Aria Automation. Import it to VCF Operations and upgrade to 9.x. Custom workflows take time to test, so split this out rather than gating the converge on it.
4. Break ELM. If your vCenter has no existing NSX registrations, upgrade vCenter to 9.0.x first, then break ELM with the SSO utility. Plan your SSO domain topology before you do this, it is not a casual command.
5. Upgrade vCenter. For converge to 9.0.0, or to 9.0.1 with no NSX, vCenter must be 9.0 or later. For converge to 9.0.1 with NSX attached, vCenter can be 8.0 U1a or later with NSX 4.1.0.2 or later.
6. Upgrade ESX hosts. For 9.0.0, hosts must be on ESX 9 before conversion. For 9.0.1, hosts may stay on 8.0 Update 1a or later.

The ELM break deserves a hard look because it is the step people run on reflex and regret. Use the supported utility, and understand it changes how your vCenters share an SSO domain:

# On the vCenter appliance, list nodes in the SSO/vCenter domain
cmsso-util domain-repoint --help

# Break Enhanced Linked Mode without downtime (run from the VCSA shell)
cmsso-util break-elm --no-check-certs 
  --url https://<vcenter-fqdn> 
  -u administrator@vsphere.local

# Confirm DRS is fully automated (PowerCLI)
Get-Cluster | Select Name, DrsEnabled, DrsAutomationLevel

# Confirm the VDS version on each switch (PowerCLI)
Get-VDSwitch | Select Name, Version

If you are sitting on standard switches, migrate to a VDS 8.0 or later before any of this. If your VMkernel interfaces use dynamic IPs, move them to static. Both are documented vSphere procedures, and both are far less stressful done in advance than discovered mid-converge. If you have not nailed down the underlay and overlay design, go back to the VCF 9 planning and prerequisites checklist before remediation, not after.

The NSX and version trap

This is the one I would flag to any client before they pick a target build. Whether your existing NSX comes along for the ride depends entirely on the VCF version you converge to.

Read that table as a recommendation, not just a fact. If you already run NSX, do not converge to 9.0.0. You will throw away your working NSX instance and let the Installer stand up a brand new one, which means re-creating segments, gateways, and DFW policy by hand. Converge to 9.0.1 or later instead, where existing NSX (without ELM) is carried through. When the Installer does deploy fresh NSX, you choose the model up front: a 3x NSX Manager HA cluster, or a single-node deployment, with overlay traffic on a management VMkernel or a VLAN-backed segment. For anything production, take the 3x cluster. The single node is a lab and edge convenience, not a production posture.

Step 3: Run the converge with the VCF Installer

With prerequisites cleared and components on the right versions, the actual converge is short.

1. Deploy the VCF Installer appliance. Since no VCF instance exists yet, you deploy the Installer (the replacement for Cloud Builder, no deployment-parameters spreadsheet required) into the environment to drive the conversion.
2. Download the VCF binaries. Pull the bits for the exact VCF version you are converging to. On slow links this is the longest single wait in the process, so kick it off early.
3. Run the deployment wizard. Point it at the existing components to reuse (vCenter, hosts, and any Aria or NSX you are carrying through), and provide deployment details for what is missing, such as SDDC Manager and NSX. The Installer validates, then deploys and configures the gaps to assemble the management domain.

You can run this interactively or feed a JSON specification file, which is the better choice if you want a repeatable, reviewed converge across multiple sites. When it finishes, your formerly standalone vSphere estate is a VCF management domain with platform-driven lifecycle and certificate management. From here, the next builds are additive: stand up workload domains or import existing ones from VCF Operations, the same way you would after a greenfield management domain bring-up.

What I’d Do

Pick your target version before you pick your change window. If you run NSX today, that single decision (9.0.1 or later, never 9.0.0) saves you a rebuild. Then treat the converge as two projects, not one: a remediation project that clears ELM, switches, DRS, and baselines over a comfortable couple of weeks, and a much shorter cutover that is mostly the Installer doing its job. Resist the urge to fix blockers live during the wizard. The teams that converge cleanly are the ones that walked in with a green assessment sheet and nothing left to discover. And put a 90-day reminder on the calendar the day you finish, because a converged instance starts in evaluation mode and needs its license applied.

What is the blocker in your environment you suspect will eat the most time, ELM, switch migration, or the ESX upgrade? That is the one to start on this week.

References

• Broadcom TechDocs: Converging Existing Virtual Infrastructure to a VCF or vSphere Foundation Platform
• VCF Blog: How to Converge a VMware vSphere Environment to VMware Cloud Foundation 9.0
• VCF Blog: Deployment Pathways for VMware Cloud Foundation 9

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts