VMware ESXi and vSphere Cluster Management
VMware ESXi Standard vSwitch Load Balancing Policies
Learn how VMware ESXi standard vSwitches select physical uplinks, compare four load-balancing policies, configure inheritance and overrides, and troubleshoot IP hash and failover behavior.
VMware ESXi standard virtual switches (vSS) connect virtual machines and VMkernel services to physical networks. A standard vSwitch can use one or more physical NICs, also called uplink adapters, to provide external connectivity.
This lesson explains how a standard vSwitch selects an uplink for outbound traffic. It covers originating virtual port ID, source MAC hash, IP hash, and explicit failover order, along with configuration scope, physical-switch dependencies, and validation.
What vSwitch Load Balancing Controls
A teaming and load-balancing policy controls which physical uplink an ESXi host uses for outbound traffic. The policy applies after a virtual machine sends traffic through its virtual NIC and port group.
Load balancing and failover are related but different:
- Load balancing selects uplinks for normal traffic forwarding.
- Failover moves traffic to another eligible uplink when the selected or preferred uplink is unavailable according to the configured failure-detection conditions.
These policies apply to VMware standard virtual switches. A distributed virtual switch has additional management and policy capabilities, but it is outside the scope of this lesson.
Key Networking Terms
- ESXi: The VMware hypervisor that provides virtual networking through virtual switches and physical uplinks.
- Physical NIC (pNIC): A network adapter installed in the ESXi host.
- Uplink adapter: A pNIC assigned to a virtual switch and connected to the physical network.
- Standard virtual switch (vSS): A host-local virtual switch that connects virtual machines or VMkernel services to physical networks.
- Port group: A vSwitch connection grouping with shared network and policy settings for attached virtual machines or services.
- Active adapter: An uplink eligible for normal traffic forwarding.
- Failover detection: The criteria ESXi uses to determine whether an uplink remains usable.
How Traffic Reaches a Physical Uplink
A virtual machine sends traffic through a virtual NIC. That virtual NIC is connected to a port group, and the port group is connected to a standard vSwitch. The vSwitch then selects one of its active physical uplinks for outbound forwarding.
Uplinks have an ordered role in the teaming configuration. They can be active, standby, or unused. Active uplinks are eligible for normal forwarding; standby uplinks are generally reserved for failover; unused uplinks are not used by the policy.
The selected load-balancing method determines the input used to choose among eligible uplinks. It does not necessarily make every packet use a different adapter. Most methods create a stable mapping so that a workload or flow continues using the selected uplink until conditions change.
The Four Standard vSwitch Load-Balancing Policies
Originating Virtual Port ID
With originating virtual port ID, ESXi uses the virtual switch port assigned to the workload as the selection input. A virtual machine's assigned virtual port maps to one physical uplink, and traffic from that port normally continues through that uplink.
This is the normal default policy for a standard vSwitch. The mapping is stable for the assigned virtual port rather than being recalculated independently for every packet.
This policy is a suitable general-purpose choice when simple, broadly compatible distribution across multiple active uplinks is desired. It requires no special link-aggregation configuration on the physical switch.
Source MAC Hash
Source MAC hash selects an uplink using the source MAC address of the virtual machine's virtual NIC. The same source MAC generally maps consistently to the same uplink while the team and relevant conditions remain unchanged.
It differs from originating virtual port ID because the selection input is the virtual NIC's MAC address, not the virtual switch port assigned to the workload. Multiple source MAC addresses can map across available uplinks, although the distribution depends on the hash and the number of workloads.
MAC-based mapping may be chosen when administrators want uplink selection to be derived from VM virtual NIC identities. Like originating virtual port ID, it does not require EtherChannel on the physical switch.
IP Hash
IP hash uses source and destination IP address information to select an uplink for outbound packets. Different IP flows can therefore use different uplinks. For example, one VM communicating with several destination IP addresses may use more than one uplink because each flow has different IP endpoints.
IP hash requires the physical switch ports connected to the participating ESXi uplinks to be configured as the required EtherChannel or static link-aggregation group. The switch-side aggregation must match the ESXi uplink design.
Explicit Failover Order
Explicit failover order uses the highest-priority active uplink that meets the configured failover-detection conditions. The active-adapter order therefore expresses a preference rather than a distribution strategy.
Normal outbound traffic uses the preferred uplink. If that adapter becomes unavailable or fails detection, ESXi moves traffic to the next eligible, lower-priority adapter. This policy prioritizes a preferred path instead of spreading normal traffic across active uplinks.
Policy Comparison
| Policy | Uplink selection basis | Default status | Traffic-distribution behavior | Physical-switch requirement | Typical use case |
|---|---|---|---|---|---|
| Originating virtual port ID | Virtual switch port identifier | Normal standard vSwitch default | Stable port-to-uplink mapping; different ports can use different uplinks | No special aggregation required | General-purpose VM networks and broadly compatible distribution |
| Source MAC hash | Source MAC address of the virtual NIC | Not the default | Stable MAC-to-uplink mapping; distribution depends on source MACs | No special aggregation required | MAC-based workload mapping |
| IP hash | Source and destination IP address information | Not the default | Different IP flows can use different uplinks; one VM may use multiple uplinks for different destinations | Required EtherChannel or static link aggregation, matching ESXi | IP-flow distribution when the physical switch is designed for it |
| Explicit failover order | Ordered active uplinks and failover status | Not the default | Uses the preferred eligible uplink; moves down the order after failure | No special aggregation required | Preferred-uplink designs and controlled failover |
Choosing a Policy
| Requirement | Recommended consideration | Reason |
|---|---|---|
| Use a standard, compatible default for ordinary VM networks | Choose originating virtual port ID | It is the normal default and does not require special switch configuration. |
| Base mapping on VM virtual NIC identity | Consider source MAC hash | The source MAC address, rather than the assigned virtual port, determines the mapping. |
| Allow separate IP flows to select different uplinks | Use IP hash only after validating EtherChannel or static link aggregation | Both ESXi and the physical switch must be configured as a compatible aggregation design. |
| Prefer one adapter and use another only after failure | Choose explicit failover order | Active-uplink order is used as a priority list instead of distributing normal traffic. |
| Investigate unequal uplink utilization | Evaluate the selected policy and its mapping inputs | Stable mappings can legitimately leave some uplinks busier than others. |
Configuration Scope and Inheritance
A teaming and failover policy can be configured at two levels:
| Configuration location | Affected workloads | Precedence | Appropriate use |
|---|---|---|---|
| Standard vSwitch | Port groups that inherit the vSwitch policy | Default for inheriting port groups | Set a broad host-level behavior for many networks. |
| Port group | Only workloads connected to that port group | Takes precedence over the vSwitch setting | Create an intentional exception for a specific network or workload group. |
Inheritance means that a port group uses the vSwitch-level teaming and failover settings unless the port group defines its own override. An administrator might use the default originating virtual port ID policy on the vSwitch while assigning a different policy to one port group.
Before changing a policy, verify whether the target port group is inheriting its settings. If a port group has a local override, changing the parent vSwitch will not change that port group's behavior.
Configure a Standard vSwitch in the vSphere Web Client
- Open the intended ESXi host in the vSphere Web Client.
- Go to the host's networking management view.
- Select the relevant standard virtual switch.
- Open the virtual switch settings editor.
- Open Teaming and failover.
- Choose the desired method under Load Balancing.
- Review the active-uplink order and relevant failover-detection settings.
- Save the configuration.
The exact labels can vary slightly between vSphere versions, but the workflow remains centered on the host networking view, the standard vSwitch settings, and the Teaming and failover section.
Configure a Port-Group Override
- Open the target port group's settings.
- Locate its Teaming and failover policy.
- Check whether the port group is inheriting from the parent vSwitch.
- Disable inheritance only when a port-group-specific policy is required.
- Choose the required load-balancing method and save the change.
- Confirm that the override is intentional and document it.
The port-group setting takes precedence over the vSwitch-level setting. If the port group should follow the parent default, remove or correct the local override rather than repeatedly changing the vSwitch policy.
IP Hash and EtherChannel Configuration Dependency
Before selecting IP hash, identify the physical switch ports connected to the ESXi uplinks that will participate in the team. Configure those ports as the required EtherChannel or static link-aggregation group, and ensure the aggregation design matches the uplinks used by the standard vSwitch.
- Configure the relevant physical switch ports as the intended EtherChannel or link-aggregation group.
- Ensure the aggregation group includes and matches the ESXi uplinks participating in the vSwitch team.
- Only then select IP hash on the associated standard vSwitch or port group.
Do not assume that configuring aggregation on only one side is sufficient. ESXi and the physical switch must agree on the topology and participating links.
Validation and Operational Considerations
- Verify that every intended physical uplink has link connectivity and the expected active, standby, or unused role.
- Confirm that the selected policy is configured at the correct scope and that port groups are not unexpectedly overriding it.
- After applying a change, test VM network connectivity and review uplink state.
- For IP hash, validate the physical-switch EtherChannel configuration before and after the change.
- Review active-uplink order and failover-detection settings when traffic moves unexpectedly.
- Document vSwitch defaults and all port-group overrides so that future administrators can explain differences between networks.
These policies primarily control outbound traffic selection from the ESXi host. Inbound traffic is influenced by the upstream physical switching environment and its forwarding decisions; it is not controlled solely by the ESXi outbound load-balancing choice.
Troubleshooting Common Symptoms
Connectivity Becomes Unreliable After Selecting IP Hash
Likely causes include an EtherChannel that is not configured on the physical switch, an aggregation configuration that does not match the ESXi uplinks, or enabling IP hash before completing the switch-side configuration.
- Confirm that the physical-switch ports are members of the intended EtherChannel.
- Verify that the switch-side design matches the ESXi uplink team.
- If the required aggregation cannot be provided, return to a non-IP-hash policy.
A Port Group Does Not Use the Parent vSwitch Policy
The port group probably has a local Teaming and failover override.
- Inspect the port-group policy and inheritance state.
- Remove or adjust the override if the port group should follow the vSwitch default.
Traffic Uses One Preferred Uplink Instead of Appearing Balanced
Explicit failover order may be selected, or the active-adapter order may intentionally prioritize one uplink.
- Confirm the selected load-balancing method.
- Review the active-uplink order.
- Use a distribution-oriented policy if preferred-uplink behavior is not intended.
An Expected Uplink Is Not Carrying Traffic
The adapter may not be marked active, failover detection may have marked it unusable, or the selected policy may map current traffic to another uplink.
- Check the adapter role and physical link state.
- Review failover-detection status.
- Evaluate the policy's mapping behavior before treating unequal utilization as a fault.
Exam-Relevant Notes
- Originating virtual port ID is the normal default policy for a standard vSwitch.
- Source MAC hash uses the source MAC address of the VM's virtual NIC.
- IP hash uses source and destination IP information and requires matching physical-switch EtherChannel or static link aggregation.
- Explicit failover order prioritizes the highest-priority eligible active uplink instead of spreading normal traffic.
- A port-group-level policy overrides the vSwitch-level policy.
- Load balancing selects outbound uplinks; it does not by itself control inbound traffic distribution.
Summary
A standard vSwitch load-balancing policy determines how ESXi selects physical uplinks for outbound VM traffic. Originating virtual port ID is the usual compatible default. Source MAC hash bases selection on the virtual NIC's MAC address. IP hash can distribute different IP flows across uplinks but requires correctly matched EtherChannel or static link aggregation on the physical switch. Explicit failover order uses a preferred uplink and moves down the order only when failure detection makes that uplink unavailable.
Always check the policy's configuration scope, active-uplink order, failover settings, and physical-switch requirements before changing production networking. For related study, see Switch Load Balancing Policies.