VMware ESXi and vSphere Cluster Management
VMware vSphere Distributed Switches Explained
Learn how VMware vSphere Distributed Switches work, how they compare with Standard Switches, their advanced features, version compatibility, and troubleshooting practices.
A vSphere Distributed Switch (vDS) is a centrally managed virtual Layer 2 switch shared by multiple ESXi hosts. It provides one logical switching configuration for every host added to the switch. Instead of recreating equivalent virtual switches and port groups on each host, an administrator configures the distributed switch and its distributed port groups through vCenter Server.
Distributed switching is especially useful in clusters where virtual machines move between hosts with vMotion. Consistent port-group, VLAN, teaming, security, and traffic-policy settings help a virtual machine retain equivalent connectivity after migration.
What Is a vSphere Distributed Switch?
A vSphere Distributed Switch is a virtual Ethernet switch whose logical configuration spans multiple ESXi hosts. It operates primarily at Layer 2, forwarding Ethernet frames according to destination MAC addresses. VLAN configuration can further separate traffic into logical broadcast domains.
The vDS has two important parts:
- Management plane: vCenter Server creates and maintains the distributed switch, distributed port groups, policies, host membership, and uplink configuration.
- Data plane: Each ESXi host performs packet forwarding locally. vCenter Server is not required to forward every packet between a virtual machine and the physical network.
This distinction matters operationally: vCenter Server centrally distributes configuration, while the ESXi hosts continue switching traffic locally.
How Distributed Switching Works
A typical connection hierarchy is:
- An administrator creates a vDS in vCenter Server.
- ESXi hosts are added as participating hosts.
- Physical NICs on each host are assigned to distributed uplinks.
- Distributed port groups define shared connectivity and network policies.
- Virtual machine adapters or VMkernel adapters connect to the appropriate distributed port group.
- Each ESXi host forwards frames between virtual adapters, distributed uplinks, and the physical network.
An uplink is the physical NIC assignment that connects an ESXi host to the external Ethernet network. A distributed port group is a shared connection and policy object. It can provide connectivity for virtual machines or VMkernel adapters used for management, vMotion, storage, or other services.
For example, a production distributed port group might specify VLAN 120, an uplink failover policy, security settings, and outbound traffic shaping. A virtual machine attached to that port group receives the same logical network treatment on every participating host.
Why vDS Helps During vMotion
When a running virtual machine moves between ESXi hosts, its virtual network adapter must connect to an equivalent network on the destination host. If both hosts participate in the same vDS and expose the required distributed port group, the virtual machine can retain its VLAN assignment and relevant network policies.
This reduces host-by-host administration in clustered deployments. The administrator does not need to manually reproduce a production port group, teaming policy, and shaping configuration on every host. Consistency also reduces configuration drift, where two hosts gradually acquire different network settings.
A vDS does not remove all vMotion requirements. The destination host still needs compatible physical connectivity, an available uplink, correct VLAN trunking, and access to the distributed port group.
vSphere Standard Switch Compared with vSphere Distributed Switch
A vSphere Standard Switch (vSS) is configured independently on each ESXi host. A vSphere Distributed Switch (vDS) is configured centrally through vCenter Server and applied to its participating hosts.
| Capability | vSphere Standard Switch | vSphere Distributed Switch | Administrative significance |
|---|---|---|---|
| Configuration scope | One host at a time | Multiple hosts through one logical switch | vDS reduces repeated configuration |
| Management interface | ESXi host configuration or vCenter host networking | vCenter Server | vCenter is required for centralized vDS management |
| Multi-host policy consistency | Must be maintained manually | Shared distributed port-group policies | Helps prevent configuration drift |
| Layer 2 switching | Yes | Yes | Both forward Ethernet frames locally |
| VLAN support | Yes | Yes | Both can connect workloads to VLAN-backed networks |
| NIC teaming | Yes | Yes | Multiple physical adapters can provide redundancy or distribution |
| Outbound traffic shaping | Yes | Yes | Limits or controls outgoing traffic according to policy |
| Network I/O Control | No | Yes, subject to version and edition support | Allocates or prioritizes bandwidth among traffic classes |
| Port mirroring | No equivalent distributed feature | Yes | Copies selected traffic for monitoring |
| NetFlow | No | Yes | Exports flow metadata to a collector |
| PVLAN | No equivalent vDS capability | Yes | Provides additional Layer 2 isolation within a VLAN design |
| LACP | No | Yes, subject to vDS version and compatibility | Negotiates aggregated links with a compatible physical switch |
| LLDP | No equivalent vDS capability | Yes | Displays information about neighboring physical devices |
| Health Check | No | Yes | Detects selected VLAN and MTU mismatches |
Core vDS Capabilities
Distributed Port Groups and VLANs
Distributed port groups provide reusable network definitions. A port group can use an access-style VLAN, a VLAN trunk range, or another supported VLAN configuration. Virtual machines and VMkernel adapters connect to the port group rather than directly defining host-specific switch settings.
NIC Teaming and Uplink Redundancy
NIC teaming uses multiple physical adapters for redundancy and, depending on the load-balancing method, traffic distribution. A failover policy can determine which uplinks are active, standby, or unused. The physical switch ports must be configured consistently with the selected design.
Outbound Traffic Shaping
Outbound traffic shaping controls traffic leaving the virtual switch toward the physical network. It can limit peak or average transmission rates for a distributed port group. It does not automatically solve congestion everywhere, because inbound traffic and physical-switch queues require separate planning.
Consistent Network Policies
Security, teaming, failover, VLAN, shaping, filtering, and marking policies can be applied at the distributed port-group level. This gives workloads equivalent treatment when they run on different participating hosts.
Advanced vDS Features
| Feature | Primary purpose | Typical use case | Physical-network dependency or consideration |
|---|---|---|---|
| NIOC | Prioritizes or allocates bandwidth among traffic classes | Protects critical management, storage, or vMotion traffic when uplinks are busy | Shares and reservations must match the intended capacity and traffic design |
| NetFlow | Exports traffic-flow metadata | Analyzes communication patterns and bandwidth use | The collector must be reachable and correctly configured |
| Port mirroring | Copies selected traffic to a monitoring destination | Inspects application traffic or troubleshoots connectivity | Destination capacity and monitoring-appliance placement matter |
| PVLAN | Segments communication within a primary VLAN | Isolates guests while allowing selected community or promiscuous communication | Physical switches must support and agree with the PVLAN design |
| LACP | Negotiates dynamic link aggregation | Combines compatible host uplinks into an aggregated physical connection | Physical switch aggregation, VLANs, and hashing must align |
| LLDP | Discovers neighboring network devices | Confirms which physical switch and port connects to an ESXi uplink | Physical switches must advertise or accept LLDP as configured |
| Health Check | Identifies certain VLAN and MTU inconsistencies | Validates that virtual and physical network settings agree | It depends on accurate physical-switch configuration and supported checks |
| Load-based teaming | Selects or redistributes uplink use based on load | Balances virtual machine traffic more dynamically than static selection | Requires suitable uplink capacity and a compatible teaming design |
| Traffic filtering and marking | Permits, drops, classifies, or marks traffic | Applies security or quality-of-service policy to selected traffic | Marked traffic must be handled as intended by downstream devices |
Network I/O Control
Network I/O Control (NIOC) groups traffic into categories and applies shares, reservations, or limits according to the supported vSphere version. For example, an administrator can give important storage or vMotion traffic appropriate treatment when several services share the same physical uplinks. NIOC controls contention; it does not create additional bandwidth.
Monitoring and Visibility
Port mirroring copies selected frames to a monitoring destination. An enhanced mirroring configuration can support more sophisticated source and destination arrangements than basic monitoring. NetFlow exports metadata about flows, such as endpoints and traffic volume, to a collector. It generally provides visibility into flows rather than a full packet capture.
Segmentation and Physical Discovery
Private VLANs provide isolated, community, or promiscuous communication relationships within a primary VLAN. LLDP helps identify neighboring physical network devices and ports, which is useful when validating cabling and uplink topology.
Health Checks, Filtering, and Recovery
Network Health Check can expose an allowed-VLAN mismatch or an MTU inconsistency between the vDS and the physical network. Traffic filtering and marking can enforce policy or classify frames. Management network rollback and recovery can help restore prior management connectivity if a host network migration causes the management VMkernel path to fail, where the selected vSphere version supports it.
Distributed Switch Versions and Compatibility
A distributed switch version determines which capabilities are available and the minimum compatible vSphere release. Every participating ESXi host must support the selected version. Version selection should therefore be part of cluster planning, especially when hosts run different vSphere releases.
| Distributed switch version | Minimum compatible vSphere release | Notable introduced capabilities |
|---|---|---|
| 4.0 | vSphere 4.0 | Earlier distributed-switch feature set; many later functions are unavailable |
| 4.1.0 | vSphere 4.1 and later | Load-based teaming and Network I/O Control |
| 5.0.0 | vSphere 5.0 and later | User-defined network resource pools for NIOC, NetFlow, and port mirroring |
| 5.1.0 | vSphere 5.1 and later | Management network rollback and recovery, Network Health Check, enhanced port mirroring, and LACP |
| 5.5.0 | vSphere 5.5 and later | Traffic filtering and marking |
These are the historical distributed-switch versions presented for vCenter Server 5.5. A newer vCenter release may offer later vDS versions and additional capabilities. Do not choose a version solely because it is newest: verify host compatibility, upgrade paths, and the features required by the environment.
Practical Configuration Workflow
- Create the distributed switch in vCenter Server.
- Select a distributed switch version supported by every intended ESXi host.
- Add the ESXi hosts to the switch.
- Assign each host's physical NICs to distributed uplinks.
- Create distributed port groups for management, vMotion, production workloads, storage, or other traffic types.
- Configure VLAN IDs or ranges, teaming and failover, security, and outbound shaping policies.
- Configure optional NIOC resource pools, port-mirroring sessions, NetFlow collectors, LACP, LLDP, and Network Health Check as required.
- Migrate virtual machine and VMkernel networking cautiously. Management connectivity requires particular care.
- Validate physical-switch trunking, allowed VLANs, MTU, LACP, and link-discovery settings.
Operational Design Considerations
- Central administration: vCenter Server provides one place to define and audit multi-host network policy.
- Reduced drift: Shared port groups reduce differences that commonly arise when administrators configure hosts independently.
- Cluster provisioning: New hosts can receive established network policies after they are added and their physical NICs are mapped.
- Physical-switch coordination: VLAN trunking, jumbo frames, LACP, and LLDP require compatible physical-switch settings.
- Failure planning: Redundant uplinks help with adapter or link failures, but redundancy is effective only when the physical paths are genuinely independent and correctly configured.
- Version planning: The selected vDS version must be supported by all participating hosts and should fit the organization's upgrade strategy.
Worked Examples
Consistent VM Network During vMotion
Two ESXi hosts participate in the same vDS. Both hosts provide a distributed port group for a production VLAN. A virtual machine attached to that port group can move between the hosts while retaining the port group's VLAN and network policies, provided the destination host has working physical connectivity.
Centralized Cluster Networking
An administrator creates distributed port groups for management, vMotion, and production workloads. The administrator applies the policies once through vCenter Server rather than creating equivalent standard-switch port groups separately on every host.
Monitoring Application Traffic
A port-mirroring session copies traffic from a selected virtual machine port to a monitoring appliance connected through the configured destination port group. The source, destination, and monitoring appliance must all be selected correctly.
Bandwidth Prioritization
NIOC assigns appropriate shares or reservations to critical traffic when management, storage, vMotion, and virtual-machine traffic share host uplinks. The physical uplinks must still have enough total capacity for the workload.
Physical-Network Validation
A health check reports that a VLAN expected by a distributed port group is not consistently permitted on a physical switch uplink. Comparing the port-group VLAN configuration with the physical trunk configuration identifies the mismatch.
Dynamic Link Aggregation
Host uplinks and their corresponding physical-switch ports are configured as a compatible LACP aggregation group. The configuration must agree on member ports, VLAN trunking, aggregation mode, and other physical-switch requirements.
Troubleshooting vDS Connectivity
A VM Loses Connectivity After Moving Hosts
- Confirm that the destination host is attached to the same vDS.
- Confirm that the target distributed port group is available to the destination host.
- Verify that the destination physical switch ports permit the required VLAN.
- Check the host's uplink assignment and the distributed port group's failover policy.
Management Connectivity Is Lost During Migration
- Verify that the management VMkernel adapter was moved to the intended distributed port group.
- Check the VLAN ID, IP configuration, uplink mapping, and physical trunk.
- Use management network rollback and recovery capabilities where available.
- Use an out-of-band management path to regain access and correct the configuration.
LACP Uplinks Do Not Pass Traffic
- Verify that the physical switch uses a compatible LACP configuration.
- Confirm member links, aggregation settings, VLAN trunking, and hashing settings.
- Ensure that the selected distributed-switch version supports LACP.
Health Check Reports VLAN or MTU Problems
- Compare the distributed port-group VLAN settings with the physical-switch trunk configuration.
- Compare MTU settings on the vDS, VMkernel adapters, physical NIC paths, and physical switch ports.
- Confirm that every intermediate network device supports the intended MTU.
Monitoring Data Is Missing
- Verify the port-mirroring source and destination.
- Confirm that the monitoring appliance can receive the mirrored traffic.
- For NetFlow, verify the collector address, reachability, transport settings, and collector configuration.
Exam-Relevant Notes
- A vSS is configured independently on each ESXi host; a vDS is centrally managed through vCenter Server.
- ESXi hosts perform local data-plane forwarding; vCenter Server provides the distributed switch management plane.
- Distributed port groups are shared policy and connectivity objects for virtual machines and VMkernel adapters.
- vDS version affects both feature availability and minimum compatible vSphere release.
- LACP requires coordination with a compatible physical switch.
- Network Health Check is useful for detecting selected VLAN and MTU mismatches, but it does not replace physical-network validation.
- Management networking should be migrated cautiously, with rollback planning and out-of-band access.
Summary
A vSphere Distributed Switch is a multi-host virtual Layer 2 switch managed centrally by vCenter Server. ESXi hosts forward frames locally, while vCenter Server maintains common switch and distributed port-group configuration. Compared with independently configured standard switches, a vDS simplifies clustered networking, improves policy consistency, and supports features such as NIOC, NetFlow, port mirroring, PVLANs, LACP, LLDP, health checks, load-based teaming, traffic filtering, and recovery controls. Its benefits depend on compatible ESXi versions and correctly configured physical switching.
For foundational study, review the VMware ESXi online course, basic ESXi configuration, and adding an ESXi host to vCenter Server inventory.