Original VM Loses Network Connectivity When Storage Copied VM is Powered On

Products

• VMware NSX
• VMware vSphere ESXi

Issue/Introduction

• An active virtual machine experiences an immediate loss of network connectivity when a copied instance of the same VM is powered on within the same vCenter inventory and stretched cluster.
• The copied VM originates from a storage-level snapshot LUN mounted as a new datastore.
• During the registration of the copied VM, the vCenter "I copied it" workflow is executed, successfully generating a new MAC address and UUID for the copy and VM registration processes complete without error.

Cause

• The network disconnection is caused by a duplicate Virtual Interface (VIF) ID conflict. This behavior exclusively occurs when a VM is copied at the storage level, bypassing native vSphere cloning mechanisms.
• While the "I copied it" routine regenerates the MAC address and UUID, it does not strip or regenerate the ethernetN.externalId parameter contained within the storage snapshot's .vmx file.
• When the copied VM is powered on, the networking stack detects a duplicate port conflict and disconnects the original VM's network interface.

Resolution

This is a condition that may occur in a VMware NSX environment.

Workaround

1. Locate the copied VM's .vmx file on the newly mounted datastore prior to registering the virtual machine.

2. Open the .vmx file in a text editor and manually remove the ethernetN.externalId parameter.

3. Save the changes to the .vmx file.

4. Register the copied VM within the vCenter inventory.

5. Power on the copied VM to force the networking stack to allocate a new, unique VIF ID during the initialization phase.

Additional Information

In an NSX-T environment cloned VMs are unable to connect to the network