Cluster Creation Fails in VMware Cloud Foundation with Errors 'ESXIS_NOT_FOUND', 'DUPLICATE_VMNIC

Products

VMware SDDC Manager / VCF Installer VMware Cloud Foundation

Issue/Introduction

When attempting to provision a custom cluster using the automated VMware Cloud Foundation (VCF) workflow or direct API Explorer (POST /v1/clusters) payload submissions, the deployment fails during the initial validation or logical provisioning phases. The architecture frequently relies on a consolidated networking design (e.g., sharing uplink adapters across management and storage/production workloads).

Depending on the operational phase, administrators will encounter one or more of the following errors:

Phase 1 - Storage Validation: Failed to submit new add cluster configuration: Failed to validate cluster spec for [hostname] with errors [FIBRE_CHANNEL_DATASTORE_NOT_PRESENT_IN_HOST]
Phase 2 - Workload Domain Add: No suitable hosts available to add a cluster. Hosts must be unassigned, commissioned with at least two physical NICs and the same storage type as the cluster, and the ESXi version must be compatible with the lowest ESXi version present in the domain.
Phase 3 - Logical Network Object Provisioning: The SDDC Manager task log shows a failure during Distributed Switch configuration with internal vCenter faults indicating an inability to create the Distributed Port Group.
Phase 4 - Host Networking Migration: The process halts with error string: Message: Failed to add host [hostname] to DVS [dvs_name]. Cause: Cannot skip 2 ESXi Host(s) as only 0 ESXi host(s) would remain and the minimum is 2. The domainmanager.log records a corresponding VSPHERE_ADD_HOST_TO_DVS_FAILED error.

Environment

VMware Cloud Foundation (VCF) 5.x

VMware SDDC Manager

Cause

1. Storage Signature Mismatch

For clusters utilizing Fibre Channel (FC) or external VMFS storage profiles, SDDC Manager registers the exact storage volume label and UUID signature during the initial host commissioning process. If an administrator renames the datastore directly on the ESXi host using the vSphere Client after the host has been successfully commissioned, the internal platform inventory tracking signature breaks.

2. Database Synchronization & UI Caching

When deployment workflows fail mid-execution, incomplete rows can remain inside the internal PostgreSQL platform tables (such as orphaned clusters with null domain properties). If these rows are manually purged during backend remediation without fully clearing the local browser cache and restarting service daemons, a transaction state mismatch occurs. The SDDC Manager UI attempts to process cached, invalid host specs against refreshed tables, resulting in false verification rejections.

3. Managed Object Namespace Collision

Inside the VMware vCenter database model, both the Distributed Virtual Switch (VmwareDistributedVirtualSwitch) and the Distributed Port Group (DistributedVirtualPortgroup) inherit structural properties from the same parent network entity class layer. If an API payload assigns the exact same string value to both the switch name (name under vdsSpecs) and the port group name (name under portGroupSpecs), vCenter flags a unique name violation constraint and rejects object instantiation.

4. Adapter Interface Uplink Locking

SDDC Manager requires uninhibited, exclusive control over any physical network adapter (vmnic) assigned to a new Virtual Distributed Switch layout. If the primary target adapters (such as vmnic0 or vmnic1) are actively claimed by the host's default local standard switch (vSwitch0), the automated network migration manager is prevented from detaching the physical uplink interfaces.

The generic error “Cannot skip hosts...” triggers because all hosts in the target deployment list fail their link migration health checks simultaneously, reducing the valid pool below the minimum threshold required for cluster initialization.

Resolution

Important: The DB edits can be destructive if done incorrectly. Take a snapshot of the SDDC Manager. Ref KB: Taking and restoring snapshots of the SDDC Manager appliance

Follow the sequential operational steps below to clean up environment variables, structure the deployment blueprint, and execute the cluster build out cleanly.

Step 1: Standardize Storage and Commission Settings

Ensure all local ESXi volume naming conventions are entirely finalized prior to beginning host commissioning.
If a datastore rename is mandatory, the ESXi host must be cleanly decommissioned from SDDC Manager, have its volume relabeled via vCenter, and then be fully recommissioned to allow the inventory engine to register the new system signature properties accurately.
Verify that the hosts are provisioned according to VCF baseline constraints: a minimum of two physical NIC ports (minimum 10 Gbps) must be present, with one port configured on a standard switch limited to the management port group, and the remaining target interfaces left free.

Step 2: Clear Corrupted Database Rows and Microservice Cache

Open an SSH terminal session to the SDDC Manager appliance as root.
Access the embedded platform database to check for lingering unassigned cluster references:
```
psql -h localhost -U postgres -d platform
```

Locate any orphaned rows throwing null constraints or referencing past failed deployment names, then execute a targeted deletion using the explicit object ID:

SELECT id, name FROM cluster WHERE id NOT IN (SELECT cluster_id FROM cluster_and_domain);
DELETE FROM cluster WHERE id = 'YOUR_ORPHANED_CLUSTER_ID';
\q

Cycle the core framework microservices back-to-back to force the application layers to rebuild their active memory pools without the stale data structures:
```
systemctl restart commonsvcs
systemctl restart domainmanager
```

Step 3: Enforce Namespace Polling Separation rules

Review and modify the payload schema block to ensure strict naming separation between the distributed switch containers and their associated port group items.

Incorrect (Collision):

"vdsSpecs": [
  {
    "name": "network_example",
    "portGroupSpecs": [
      { "name": "network_example", "transportType": "MANAGEMENT" }
    ]
  }
]

Correct (Unique Namespaces):

"vdsSpecs": [
  {
    "name": "vds_example",
    "portGroupSpecs": [
      { "name": "pg_example", "transportType": "MANAGEMENT" }
    ]
  }
]

Step 4: Disconnect Active Uplink Locks and Consolidate Layouts

To configure a streamlined architecture that passes validation rules without throwing duplicate interface faults, consolidate the deployment payload into a 2-switch blueprint. Collapse standalone high-speed infrastructure elements down so they run natively as virtual portgroup profiles directly on the principal production virtual distributed switch backbone.

Log directly into the ESXi host console or vSphere Client for the target deployment nodes.
Navigate to Configure > Networking > Virtual Switches.
Edit the settings for the default standard switch (vSwitch0) and remove/disconnect the target interface adapter (e.g., vmnic0) to free up the physical hardware channel for incoming VCF network orchestration.
Open a clean Incognito Window in your browser, log back into the SDDC Manager UI dashboard, and navigate to Developer Center > API Explorer.
Paste the final consolidated 2-switch payload structure with unique naming strings into the text input area of POST /v1/clusters and click EXECUTE.

The deployment engine will process the request cleanly, output a status of 201 Created, and successfully begin running the task automation inside the main SDDC Manager task dashboard!