Dr. Pranay Jha

You have a perfectly healthy vSphere cluster running vSAN and NSX. Management wants it under VCF fleet management so it gets the same lifecycle, certificate and password automation as everything else. The import workflow promises to do exactly that without a rebuild. It does, mostly. But the import is not passive: it changes live configuration on a running cluster, and a couple of those changes will catch you off guard if you have not read past the marketing. If you have not yet decided between this path and a clean rebuild, start with the VCF 9 adoption paths breakdown. This post assumes you have chosen import, and walks through what actually breaks.

What the import workflow actually does

Import lives in VCF Operations, not the VCF Installer. You go to Inventory → Detailed View, expand the VCF instance you want to add to, and choose Add Workload Domain → Import a vCenter. You hand over vCenter credentials and, if NSX is present, NSX Manager VIP plus the admin, root and audit passwords. The workflow runs discovery, prechecks, the import itself, and an enablement pass. This is distinct from the converge workflow, which is how you build your first VCF instance from brownfield. Import is for adding domains to a fleet that already exists.

One genuinely useful flexibility: with import, your vCenter and NSX Manager appliances can stay where they are, inside the domain being imported, or live in the management domain, or split across both. A freshly deployed workload domain does not give you that choice, its management components always sit in the management domain. Good to know if you have an existing topology you would rather not move.

Requirement 1: import does not mean version 9

Symptom: the import succeeds, the domain appears in the inventory tree, and Fleet Management shows it as version 5.1.1.0. You expected a VCF 9 domain.

Cause: import onboards the environment at the BOM version it discovers. A brownfield vSphere 8 with NSX-T 4.1 maps to a VCF 5.x workload domain. That is by design and it is actually the safer route, because you sidestep the awkward NSX 4 to NSX 9 jump that bites the convert path. The catch is purely one of expectations.

Fix: plan import and upgrade as two separate phases. After the first inventory collection completes, go to Fleet Management → Lifecycle, download the 9.0 binaries for vCenter, ESX and NSX through Binary Management (online or offline depot), apply any detected configuration updates, run prechecks, then Plan Upgrade. In the field the NSX is upgraded first without the host bits, then vCenter, then the ESX hosts. Budget the maintenance window for the upgrade, not just the import. And note a real-world wrinkle: some lab and brownfield imports hit a failed compatibility check that has to be manually acknowledged before the 9.0 upgrade will proceed, so do not assume an all-green precheck.

Requirement 2: the Distributed Firewall switches itself on

Symptom: after import, NSX is suddenly active on distributed virtual port groups that were never part of an overlay, and the Distributed Firewall is enforcing on production VMs that previously had no DFW in their path at all.

Cause: this is the one that surprises people. The import workflow automatically activates NSX on the distributed virtual port groups (DVPGs) in the imported cluster. Activating NSX on DVPGs also activates the DFW on all of them, and the firewall starts applying rules to your existing workloads immediately. The saving grace is that the default DFW ruleset is allow-all for Layer 2 and Layer 3, so traffic keeps flowing on day one. The risk is everything after day one: any later default-deny policy, any automation that touches the DFW, or any security team that assumes the firewall was always there now has a live enforcement point on workloads that were never designed around it. If you are fuzzy on how the DFW behaves in this release, the NSX in VCF 9 explainer covers the model.

Fix: treat this as a planned change, not a side effect. Tell the network and security owners before the import so the allow-all baseline is expected and documented. If a given cluster is not ready to live behind the DFW yet, you can deactivate NSX on the DVPGs after import using the NSX UI or the Transport Node Collection API.

# After import, confirm the Transport Node Collection that was created
GET https://<nsx-manager>/policy/api/v1/infra/host-transport-node-collections

# Deactivate NSX on the DVPGs by removing the host switch /
# transport node profile mapping for that collection, then re-check DFW state.
# Do this in a change window: it touches dataplane config on live hosts.

Requirement 3: Enhanced Linked Mode stops the import cold

Symptom: prechecks fail on the vCenter because it is part of an Enhanced Linked Mode (ELM) SSO domain with other vCenters.

Cause: vCenter instances with ELM are explicitly not supported for import. VCF wants a standalone SSO boundary per imported vCenter. This trips up almost every mature estate, because ELM is extremely common in environments that grew past a single vCenter.

Fix: break ELM before the import. If the vCenter has no existing NSX registrations, you can upgrade it to 9.0.x and then split it out of the linked SSO domain with the supported utility:

# Run from the vCenter appliance shell to break Enhanced Linked Mode
# without downtime to the running workloads.
cmsso-util break-elm -u administrator@vsphere.local

# Validate the vCenter is now standalone in the SSO topology
# before you start the VCF import prechecks.

One narrowing of this rule worth knowing: starting with VCF 9.0.1, vCenter instances without ELM that have existing NSX Local Managers in an NSX Federation are supported. If you are on Federation, only the Local Manager is imported, and you upgrade the federated environment separately.

Requirement 4: it is all clusters, or none

Symptom: you intended to bring in one tidy production cluster and leave a noisy lab cluster alone, but the workflow pulls in every cluster the vCenter manages.

Cause: partial import is not supported. All vSphere clusters under that vCenter are imported together as part of the single workload domain. There is no cluster picker.

Fix: this is a scoping decision you make before you touch the import wizard, not during it. If a vCenter contains clusters you do not want under VCF, move them to a different vCenter first, or accept that they come along and meet the supported-configuration bar too. Standalone hosts and single-host clusters are tolerated only if the same vCenter also has at least one cluster that meets the requirements, and you keep lifecycling those one-off hosts manually through the vSphere Client.

My take

If your vCenter is a grab-bag of dissimilar clusters, fix the vCenter boundaries first. Importing a messy vCenter just moves the mess into your fleet.

Requirement 5: the prechecks that fail most often

Symptom: the readiness prechecks throw a wall of failures on networking and lifecycle configuration that you assumed were fine because the cluster has run happily for years.

Cause and fix, item by item. These are the configurations VCF will not accept, and what to do about each:

• No vSphere Distributed Switch. A VDS 8.0 or later is mandatory. Standard switches and, specifically, Cisco virtual switches like the Nexus 1000V are not supported. Migrate to a VDS before import.
• DHCP-assigned VMkernel IPs. VMkernel addresses must be statically assigned. The one exception is NSX Host TEPs, which may use DHCP. Convert any DHCP vmk interfaces to static first.
• Shared vMotion network. A dedicated network for vMotion is required. A vMotion vmk sharing a network with management or other traffic will fail.
• Baseline-managed clusters. vSphere Lifecycle Manager images are required. Clusters still using baselines must be converted to images before the ESX 9.0 upgrade.
• Manual or partially automated DRS. DRS must be set to fully automated. This is a one-click change but it is a hard gate.
• VxRail-managed clusters. Clusters managed by Dell VxRail are not supported for this import path at all. Do not plan around it.

On storage, vSAN is the top-priority datastore VCF will select, followed by NFS v3, VMFS, NFS 4.1, iSCSI and then vVols. For vSAN OSA clusters, deduplication and compression must be either both on or both off (compression-only is also fine). And vVols, while technically in the priority list, is deprecated in version 9 and not worth building a new design around. If you are weighing vSAN layout decisions while you are in here, the vSAN ESA vs OSA storage design post is the companion read.

Requirement 6: Credentials, ESXi roots and Edge password resets

Symptom one: after import, password management of the imported ESXi hosts through the VCF Operations Password Management Console does not work, or the import flags missing host credentials.

Cause: SDDC Manager is missing the ESXi root credential entries for the imported hosts, so it cannot manage them.
Fix: use the documented workaround in Broadcom KB 388859 to create the missing ESXi root credential entries in SDDC Manager, which unblocks password management for the imported hosts.

Symptom two: your NSX Edge node passwords stop working after import.

Cause: if your existing NSX Manager is 9.0 or higher with one or more Edge clusters and you tick “Enable Edge cluster sync and import NSX Edge node VMs”, the import resets the Edge node credential passwords as it brings them into the VCF inventory. That reset also applies to nodes added later.
Fix: do not go hunting for the old passwords. Retrieve the new ones from the VCF credential store after the import. If there is no NSX present at all, the workflow deploys a three-node NSX Manager cluster for you, and a single-node Standard deployment is only offered when you import a vCenter that is already on 9.0.

What I’d Do

Import is the right tool when your brownfield already looks close to what VCF expects: VDS in place, static VMkernels, dedicated vMotion, fully automated DRS, image-based lifecycle, no ELM, no VxRail. In that case it is far less disruptive than a rebuild and you keep your data in place. When the environment is far from that bar, do not try to remediate everything live under import pressure. Remediate the networking and lifecycle prerequisites as their own project first, prove the DFW activation behaviour in a staging fleet, and only then run the import as a clean, boring change. The verdict: import rewards a tidy source environment and punishes a messy one. The work is in the preparation, not the wizard.

Have you run a brownfield import into a VCF 9 fleet yet, and did the DFW activation catch your security team off guard? Tell me how you handled the change window.

References

• Broadcom TechDocs: Import an Existing vCenter to Create a Workload Domain (VCF 9.0)
• VMware Cloud Foundation Blog: Deployment Pathways for VMware Cloud Foundation 9
• Tom Fojta: VCF 9 Importing Brownfield Environment (field walkthrough)

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