You move a VM from one host to another, and suddenly it can't ping anything. The network adapter shows activity, but traffic goes nowhere. I've seen this dozens of times. The fix is usually a VLAN ID mismatch between the port group and the physical switch trunk port.
Check the Port Group VLAN ID
- Open vSphere Client and go to Networking.
- Find the virtual switch your VM uses (standard or distributed).
- Right-click the port group your VM is connected to and choose Edit Settings.
- Look for VLAN ID. It's usually empty or set to 0 (no VLAN).
- Compare this to what your physical switch expects. If the physical trunk port allows VLAN 100, but your port group uses VLAN 200, traffic won't go through.
- Change the VLAN ID to match the physical switch configuration.
- Click OK.
After this change, the VM should get network back within a few seconds. No reboot needed.
Why This Happens
When you vMotion a VM, the virtual switch on the destination host needs to pass VLAN tags to the physical switch. If the port group VLAN ID doesn't match what the physical switch expects, the frames get dropped. The VM thinks it's on the right network, but the physical switch doesn't agree. This is the most common cause of post-vMotion network issues.
Sometimes it's the MTU. If your physical switch runs jumbo frames (MTU 9000) but the virtual switch uses standard 1500, you'll see packet drops for large frames. This shows up as slow file transfers or intermittent connectivity. Check the virtual switch MTU under Properties for standard switches, or in the distributed switch settings.
Less Common Variations
VLAN 4095 Misconfiguration
Some people set VLAN to 4095 on a port group thinking it passes all VLANs. That's for trunk ports inside the VM, not for normal VMs. If you set 4095 on a regular VM port group, the physical switch might get confused. Stick with the specific VLAN your VM needs.
Promiscuous Mode
If you need promiscuous mode (like for monitoring tools), you have to enable it on the port group. Without it, the VM can only see its own MAC address. This isn't directly a vMotion issue, but I've seen admins change port group settings and accidentally disable promiscuous mode. Check this under Security tab in the port group settings.
Distributed Switch vs Standard Switch
If you have a distributed switch, the VLAN ID is set at the port level, not the group. Right-click the VM, choose Edit Settings, go to network adapter, and click the dropdown to see the port settings. The VLAN ID shows there. It can be different per VM even in the same port group.
| Scenario | What to Check |
|---|---|
| Standard Switch | Port group VLAN ID |
| Distributed Switch | VM port VLAN ID |
| Both | Physical switch trunk VLAN allowed list |
Prevention for Next Time
The real fix is documentation. Write down every VLAN ID and MTU for every port group. When you create a new VM, check the port group settings before you power it on. If you're using a template, make sure the port group in the template matches the production network.
Also, test your vMotion. Move a test VM between hosts and run a continuous ping. If it drops more than one packet, you have a configuration problem. Don't wait until a production VM goes down.
One more thing: if you're changing VLAN IDs on a physical switch port that connects to an ESXi host, update the virtual switch port group first, then change the physical switch. Otherwise, you'll lose connectivity to all VMs on that host. I've done that once. Learned the hard way.
That's it. Fix the VLAN ID, and your VM will work after vMotion. Nothing fancy.