Cloned virtual machine is unable to connect its virtual network adapter (vNIC) to the network

Products

VMware vCenter Server

Issue/Introduction

Attempts to manually check the "Connected" box for the network adapter within the VM settings, the vSphere Client immediately rejects the action and returns the following error:

"Failed to connect virtual device ethernet0"

Environment

vCenter 8.0U3

Cause

The root cause of this failure is a network topology mismatch. The cloned VM attempts to bind to its original portgroup, which is either unavailable, misconfigured, or entirely absent on the destination ESXi host where the clone is deployed.

A review of the vmware.log reveals the exact point of failure. The hypervisor is physically unable to bind the VM's virtual network adapter (Ethernet0) to the requested virtual switch portgroup, which forces the vNIC into a disconnected state:

The Portgroup Binding Failure:

YYYY-MM-DDTHH:MM:SS.sssZ In(05) vmx - VMXNET3 user: failed to connect 'Ethernet0' to vSwitch portgroup '#####-#####'.
YYYY-MM-DDTHH:MM:SS.sssZ In(05) vmx - [msg.device.badconnect] Failed to connect virtual device 'Ethernet0'.

The Manual Retry: Seven minutes later, the logs record the customer's manual attempt to toggle the connection back on via the vSphere Client (Receiving Ethernet.SetStartConnected request and Ethernet.ConnectionControl request). The hypervisor attempts the connection again but hits the exact same [msg.device.badconnect] error because the underlying network mismatch is not resolved."

Resolution

To resolve a msg.device.badconnect error caused by cloning/migration, the following workflow is required:

Verify Host Networking: Ensure the specific ESXi host computing the VM actually has access to the assigned portgroup.
Reassign the Network Adapter: Right-click the VM, select Edit Settings, and change the Network Adapter's dropdown assignment to a valid, available network portgroup on the current host.
Check for Port Exhaustion (If applicable): If the portgroup is present but still fails, ensure the portgroup is set to Ephemeral binding or has a sufficient number of static ports available for new VMs."

Additional Information

The virtual machine was created by cloning the datastore from a snapshot and moving the files to a new datastore. The vmx file was registered and on power on answered "I copied the vm".

Other KB Articles for this error	What distinguishes each from this KB
KB 317802	NSX-T VIF Duplication: The failure here is caused by a duplicate NSX logical switch port ID (`ethernetN.externalId`) left behind in the cloned `.vmx` file. It is an NSX-specific configuration collision, rather than the destination host physically lacking the requested vSphere portgroup.
KB 427426	Stale dvFilters: The root cause is a stale third-party security or networking filter (like an old antivirus or legacy NSX filter) remaining in the host's I/O chain. The host actively blocks the connection due to a corrupted filter state, not because of a network topology mismatch.
KB 313749	NSX VIB Upgrade Failure: The vNIC fails to connect because the ESXi host itself has an incomplete or failed NSX VIB installation/upgrade. The network exists, but the host's software components required to interact with the NSX overlay are broken.
KB 382338	ESXi 7.0 Memory Leak Bug: This is an actual software defect in ESXi 7.0 (a memory leak in the `pktlist` portset data) that prevents vNICs from binding to Standard vSwitches. Your KB outlines expected, by-design hypervisor protection, whereas this KB documents a hypervisor crash/bug requiring a patch.