Detailed procedure:
Workaround:
If the network adapters are currently used as uplinks for vmkernel port groups such as the management vmkernel, the network adapter may need to be "walked" over one adapter at a time to avoid losing connection to the management vmkernel.
Note: If there are other vmnics that can be used in the LAG, that would be easiest and fastest. If the current adapters must be moved to LAG, be aware that this process will take time and will require configuration at the same time on the physical switch ports. VMware highly recommends that the host be in Maintenance Mode during this process as well.
Here are the basic steps for walking currently used adapters over to the LAG adapter group.
Note: This is a sample. The actual adapters and vmnic numbers may be different for each environment:
VMware supports Link Aggregation Control Protocol (LACP) on vSphere Distributed Switch (VDS) only.
Note: Link Aggregation Control Protocol (LACP) can only be configured through the vSphere Web Client.
Note: These policies are configured for LAG. The LAG load balancing policies always override any individual Distributed Port group if it uses the LAG.
Basic LACP (LACPv1) is only supported on vSphere versions 6.5 or below. Upgrading ESXi to 7.0 may result in the physical switch disabling the LAG ports on ESXi hosts using Basic LACP.
For more information on Enhanced LACP in vSphere, see --> Converting to Enhanced LACP Support on a vSphere Distributed Switch- "Source vCenter Server has instance(s) of Distributed Virtual Switch at unsupported lacpApiVersion"
Impact/Risks:
Minimal chance of network interruption, provided that the vCenter server has a connection to the hosts that is independent of the DVS. This is especially true for enabling LACP on a vSphere Distributed Switch (vDS) because the Distributed Switch is owned by the vCenter Server and the hosts alone cannot make changes to the vDS if connection to vCenter is lost.
VMware recommends to perform these actions during a maintenance window.
Enabling LACP can greatly complicate vCenter or host management recovery in production down scenarios, because the LACP connection may need to be broken to move back to a Standard Switch if necessary (since LACP is not supported on a Standard Switch).
Also, for Support Case situations, when LACP is configured, any network troubleshooting will typically require not only support from VMware by Broadcom, but also collaboration on the same call with the customer personnel who manage and can access and modify physical switch configurations. Because both these groups are typically in high demand, this tends to elongate the length of time for support calls considerably.
Since a distributed switch is required, the ephemeral port groups are generally used for recovery purposes when there is a need to provision ports directly on a host, bypassing vCenter Server. Ephemeral port groups are recommended for the vCenter Server VM and the host management vmkernels. For more information, see --> Static (non-ephemeral) or ephemeral port binding on a vSphere Distributed Switch.
Note: For more information, see the vSphere Networking section --> About vSphere Networking. This guide contains definitive information. If there is a discrepancy between the guide and the article, assume the guide is correct.