LACP is being used for VM network traffic.
The LACP configuration unexpectedly went down, resulting in all VMs becoming inaccessible.
Upon reviewing the vCenter logs, a VDS reconfiguration event was observed. The default VDS configuration includes 4 uplinks, but the logs indicate that only 3 uplinks remained, suggesting a possible change or misconfiguration.
2022-06-27T14:25:36.031+08:00 error vpxd[06460] [Originator@6876 sub=MoDVSwitch opID=l2e8d27a-781841-auto-gr9u-h5:70293023-1c] [MoDVSwitch::ReconfigureInt] reset the default uplink teaming policy active list to correspond to the new uplink names :[(string) [--> "Uplink 1",--> "Uplink 2",--> "Uplink 3"--> ]]2022-06-27T06:25:36.156Z cpu42:2100976 opID=dea16a1b)Team.cswitch: TeamVSLACPLAGEventCB:9072: [nsx@6876 comp="nsx-esx" subcomp="vswitch"]Received event LAG DESTROY, LAG /0, link UNKNOWN, uplink /0x0, link UNKNOWN
There is a behavioral change introduced in vCenter 7.0 Update 3, compared to vCenter 6.7. This change affects how uplink deletions are handled when LAG (Link Aggregation Group) is in use. Specifically, when a user deletes an uplink in vCenter 7.0, the system first destroys the LAG on the host side and then recreates it, which can temporarily disrupt connectivity.
Behavior Matrix:
vCenter 7.0 + ESXi 6.7: Behavior change is present.
vCenter 6.7 + ESXi 6.7: No behavior change — LAG remains intact during uplink changes.
vCenter 7.0 + ESXi 7.0: Behavior change is present.
As a result of this behavior, the VM's may lose connectivity.
Workaround: