Creating a link aggregation group (LAG) on a vSphere distributed switch does not automatically move a host's physical NICs or a VM port group's traffic into it. The vSphere 8.0 documentation states that a newly created LAG has no physical NICs assigned and is unused in distributed port groups' teaming and failover order. Inspect those separate states before treating the LAG as a working traffic path. A22-D3
This is an inspection-only diagnostic for enhanced LACP on a vSphere 8.0 distributed switch. No uplink was moved, LAG activated, switch reconfigured or bandwidth test executed.
Three configurations must agree
The distributed switch holds the LAG definition, including its ports. When a LAG is created, a corresponding object is created on each connected host's proxy switch. Those local objects do not themselves attach physical cables or select the LAG for every workload. A22-D1
Each host needs its own physical-NIC mapping into its local LAG ports. On one host, one physical NIC connects to one LAG port. The same distributed LAG port can have NICs from different hosts mapped to it because each host has its own local instance.
The physical switch needs a separate LACP port channel for each participating host, with the correct connected NICs. Finally, the relevant distributed port group must be configured to use the LAG. An inventory object existing at one layer is not proof that all these layers agree.
The 8.0 guide requires distributed-switch version 6.5 or later and support for enhanced LACP. Record those prerequisites before interpreting the missing assignments. Its reference sequence is: create the LAG; place it in Standby in teaming/failover; assign physical NICs; then make it Active. This names the documented stages so an existing state can be compared with them; it is not a migration runbook or permission to change uplinks.
Inspect without migrating traffic
Prerequisites are the distributed-switch identity and version, intended LAG, affected host, VM port group and existing physical-switch mapping. Obtain authorised read access or current configuration exports. Do not enter a migration wizard simply to experiment with an uplink.
In the distributed switch's configuration, record the LAG definition and port count. Then inspect the physical NIC assignments for each affected host separately. Include the vmnic, LAG port and corresponding physical switch port/channel in the evidence.
Read the target port group's teaming and failover order. Determine whether the LAG is unused, standby or active, and retain any relevant effective override. “The switch has LACP configured” is too broad to establish which path this particular VM uses.
Use the network owner's existing port-channel evidence to verify the host mapping. Similar names on the two sides are not enough; the actual cable/port membership is what matters.
Worked comparison across two hosts
Consider this synthetic inventory:
| Observation | Host A | Host B |
|---|---|---|
| Local proxy object for LAG1 | Present | Present |
| NIC assigned to LAG1 port 0 | vmnic2 | None |
| NIC assigned to LAG1 port 1 | vmnic3 | None |
| Intended physical port channel | Recorded | Not established |
The shared LAG definition does not make Host B equivalent to Host A. Host B's empty assignment is sufficient to explain why the LAG object alone cannot carry its traffic. It does not prove that Host A's configuration is fully healthy; port-group selection and physical negotiation still need evidence.
Now suppose the relevant VM port group lists LAG1 as unused. Even on Host A, the presence of mapped NICs is not evidence that this group's traffic is using LAG1. The configuration layers answer different questions.
The diagnostic report should identify the first demonstrated mismatch rather than recommend an immediate move. Moving the only working uplink can disrupt the management connection needed to correct the configuration.
Separate missing use from failed negotiation
If NIC assignments and port-group selection are present, but existing LACP status shows a negotiation problem, the newly-created-default explanation is no longer sufficient. Compare the physical port channel, selected negotiation settings and actual host membership with the version-specific design.
The 8.0 guide requires the physical links participating in a host's LACP channel to align with its mapped NICs, and documents speed/duplex and hashing requirements. Use the physical-switch vendor's supported configuration alongside VMware's guidance. This article does not translate static EtherChannel examples into LACP settings. A22-D1
Nor does it promise that one transfer will consume the sum of all member-link speeds. The question here is whether the intended path has been configured for use, not a single-flow performance limit.
Acceptance and reversal boundaries
A complete diagnostic records the LAG definition, per-host NIC mappings, physical channel association and effective port-group use. Missing or contradictory evidence remains explicit.
For a later approved migration, proposed acceptance includes the intended host mappings, healthy negotiation and validated workload and management connectivity. A visible LAG name alone does not pass. No such migration or connectivity test was run here.
The official workflow includes several ordered changes to move traffic safely. Do not compress it into “make the LAG active”. A qualified plan must preserve independent management access, the previous NIC and port-group configuration, and a validated return path on both host and physical switch.
Read-only inspection needs no rollback. Its practical value is identifying exactly which configuration layer has not yet made the LAG usable.
Learning notes
- A LAG object is not an automatic physical-NIC assignment.
- Per-host mappings remain separate even on one distributed switch.
- Port-group use and physical negotiation are additional requirements.
References
- A22-D1: LACP Support on a vSphere Distributed Switch
- A22-D3: Configure a Link Aggregation Group to Handle the Traffic for Distributed Port Groups