VMware ESXi and vSphere Cluster Management
VMware vSphere Distributed Switches Explained
Learn how VMware vSphere Distributed Switches work, how they compare with Standard Switches, and how features such as NIOC, LACP, NetFlow, and Health Check support clustered ESXi networking.
A vSphere Distributed Switch (vDS) is a logical Layer 2 virtual switch managed centrally by vCenter Server. Unlike a host-local switch, one vDS can span multiple associated ESXi hosts. Its main purpose is to provide consistent virtual network configuration across a cluster.
Virtual machines and VMkernel adapters connect to distributed port groups. When a virtual machine moves between hosts with vMotion, it can retain the same port-group assignment, VLAN configuration, and applicable network policies, provided the destination host has the required vDS membership and physical connectivity.
What a vSphere Distributed Switch Does
A vDS separates the logical design of a virtual network from the individual ESXi hosts that implement it. vCenter Server stores and administers the distributed-switch configuration. Each participating host then implements the relevant switching behavior locally through its ESXi networking stack.
The vDS performs Layer 2 frame forwarding. It connects virtual machines and VMkernel adapters to physical networks through host uplinks and physical NICs.
Important vDS terms
- Distributed port: A logical switch port used by a connected endpoint.
- Distributed port group: A logical network and policy container to which virtual machines or VMkernel adapters connect.
- Uplink: A logical vDS connection mapped to a physical NIC on an ESXi host.
- Physical NIC, or pNIC: A host network adapter that connects virtual networking to the physical network.
- VLAN: A Layer 2 segmentation mechanism commonly assigned through port-group configuration.
How Distributed Switching Works
An administrator creates the vDS and its distributed port groups in vCenter Server. The configuration can include VLAN settings, teaming and failover policies, security policies, MTU, traffic shaping, and other features supported by the selected vDS version.
When an ESXi host is added to the vDS, its physical NICs can be mapped to the switch's logical uplinks. The host supplies the local forwarding implementation and physical connectivity, while vCenter Server provides the centralized configuration model.
A typical path for virtual-machine traffic is:
- A virtual machine connects its virtual adapter to a distributed port.
- The distributed port belongs to a distributed port group.
- The port group applies network settings such as VLAN and teaming policies.
- The vDS forwards the Layer 2 frame through an appropriate host uplink.
- The host's physical NIC sends the frame to the physical switch.
Every host must have suitable physical NIC mappings. Centralized configuration does not automatically provide physical connectivity to a host that lacks the required NICs, cabling, trunk configuration, or VLAN access.
Distributed Switch versus Standard Switch
A vSphere Standard Switch (vSS) is a host-local virtual switch. It is configured separately on each ESXi host. If a cluster needs the same virtual network on four hosts, an administrator must create and maintain equivalent Standard Switch and port-group settings on each host.
A vDS is managed as a shared logical switch through vCenter Server. Its distributed port groups provide a common configuration model across associated hosts. This reduces repetitive per-host work and makes policy changes easier to apply consistently.
Core Networking Capabilities
VLAN-backed distributed port groups
A distributed port group can represent a virtual network associated with a VLAN or another supported VLAN model. VLAN segmentation separates Layer 2 traffic domains. The physical switch ports connected to ESXi hosts must carry the required VLANs.
Uplinks and physical NIC connectivity
Each host maps one or more pNICs to vDS uplinks. Uplinks connect virtual switching to the physical network. A port group can use these uplinks according to its teaming and failover policy.
NIC teaming and failover
NIC teaming uses multiple physical NICs for redundancy, load distribution, or both. Failover policies determine which uplinks are active, standby, or unused. The policy must match the physical-switch design and the traffic requirements.
Load-based teaming, where supported, can move traffic between uplinks based on measured load rather than relying only on a static allocation. It is useful when traffic patterns change over time.
Outbound traffic shaping
Outbound traffic shaping controls traffic leaving a virtual port or port group. Depending on the configuration, it can limit or smooth the rate of outgoing traffic. It does not replace adequate uplink capacity or correct physical-network design.
Consistent policy application
Security, teaming, failover, VLAN, MTU, and shaping policies can be associated with distributed port groups. An administrator can change a shared policy in vCenter Server and then verify that all connected hosts receive the intended configuration.
Operational Value in Clusters and Migrations
Identical networking is important for vMotion, which migrates a running virtual machine between ESXi hosts. If the destination host does not provide the same required virtual network, VLAN reachability, and uplink path, the migration may fail or the workload may lose connectivity.
For example, a four-host cluster can use one distributed port group for a production VLAN. Each host joins the vDS and maps appropriate pNICs to its uplinks. A virtual machine moved to another host remains connected to the same logical port group instead of requiring a separately created equivalent network.
Centralized management also helps with cluster-wide changes. An administrator can update a distributed port group's teaming policy or security setting once, then validate the result across all connected hosts.
Advanced vDS Features
Network I/O Control
Network I/O Control (NIOC) allocates and prioritizes bandwidth among traffic classes. These can include virtual-machine traffic, management, vMotion, storage, and other system traffic. Shares, reservations, and limits can help provide predictable access to constrained uplink bandwidth.
Network resource pools provide logical bandwidth allocation categories used by NIOC. Applicable vSphere versions can support user-defined pools.
Monitoring and visibility
- Port mirroring: Copies selected traffic to a monitoring or analysis destination, such as a packet-analysis appliance.
- Enhanced port mirroring: Provides additional mirroring capabilities where supported by the vDS version and environment.
- NetFlow: Exports traffic-flow metadata for visibility and analysis. It generally describes flows rather than replacing a full packet capture.
- LLDP: Provides Layer 2 neighbor information or advertisement support, helping administrators identify connected physical devices and port relationships.
Health and isolation features
- Network Health Check: Helps detect VLAN and MTU mismatches between the vDS and physical network.
- Private VLAN (PVLAN): Supports secondary VLAN isolation models within a primary VLAN design.
- Traffic filtering and marking: Applies policy-based handling to traffic according to defined criteria and marking behavior.
Link aggregation and recovery
Link Aggregation Control Protocol (LACP) negotiates aggregated links between ESXi hosts and compatible physical switches. LACP must be intentionally configured on both sides, and the physical ports must belong to the correct aggregation group.
Management network rollback and recovery capabilities are safeguards for changes that could otherwise disconnect host management. They are especially important when migrating VMkernel management networking.
Distributed Switch Version and Feature Evolution
A distributed switch has a version level. That level affects minimum compatible vSphere releases and the functionality available to the switch. The version must be selected with both host compatibility and feature requirements in mind.
The practical planning rule is to choose the highest switch version that is compatible with all required ESXi hosts and supports the features the environment needs. Do not upgrade the switch version solely for convenience if older hosts must remain attached.
Design and Administration Considerations
- Plan distributed port groups, VLAN IDs, uplinks, MTU, teaming, failover, security, and traffic-shaping policies before migrating hosts.
- Coordinate VLAN trunking, LACP, MTU, and physical port configuration with network administrators.
- Use consistent uplink names and mappings across hosts where possible. Consistency makes operations and troubleshooting easier.
- Confirm that every host has the required pNICs and that each pNIC is mapped to the intended vDS uplink.
- Migrate VMkernel and virtual-machine networking in a controlled order.
- Validate connectivity, VLAN reachability, redundancy, and vMotion behavior after each significant change.
High-level vDS deployment workflow
- Create a distributed switch in vCenter Server.
- Choose a distributed-switch version compatible with the environment and required features.
- Create distributed port groups and assign VLAN or PVLAN settings.
- Add ESXi hosts to the switch.
- Map each host's physical NICs to the intended vDS uplinks.
- Configure teaming, failover, MTU, traffic shaping, and security policies as needed.
- Migrate virtual-machine and VMkernel networking in a controlled order.
- Validate host connectivity, VLAN reachability, redundancy, and migration behavior.
Physical network prerequisites
- Required VLANs are permitted on the physical switch ports connected to ESXi hosts.
- Physical-switch ports use the expected trunking model.
- MTU settings are consistent end to end when jumbo frames are required.
- LACP is configured on both the physical switch and vDS only when it is intentionally used.
- Each host has redundant uplinks when availability requirements call for redundancy.
Management network migration safeguards
Management migration deserves special care because an incorrect change can disconnect host management access.
- Confirm a working management path before changing VMkernel management connectivity.
- Use a direct console or out-of-band access path when possible.
- Use rollback or recovery protections supported by the selected vDS version.
- Validate physical-NIC-to-uplink mappings before committing the migration.
Advanced Feature Use Cases
Troubleshooting Common Problems
Virtual machines lose connectivity after moving to another host
Likely causes:
- The destination host is not attached to the correct vDS or distributed port group.
- Required VLANs are not allowed on the destination host's physical-switch uplinks.
- Physical NIC uplink mappings differ from the intended design.
Checks: Verify vDS host membership, the virtual machine's distributed port group and VLAN assignment, physical-switch trunk configuration, and host uplink status.
Management access is lost during migration from a Standard Switch
Likely causes: An incorrect VMkernel migration sequence, incorrect pNIC or uplink mapping, or a management VLAN missing from the new physical path.
Checks: Use direct console or out-of-band access, validate management VLAN reachability and uplink mapping, and use applicable rollback or recovery mechanisms.
LACP does not pass traffic as expected
Likely causes: LACP is enabled on only one side, aggregation settings do not match, or incorrect physical ports are assigned to the link-aggregation group.
Checks: Compare LACP mode and configuration on both sides, confirm the participating host NICs, and review physical-switch LAG status.
Packet loss or poor performance occurs under load
Likely causes: Insufficient uplink capacity, an unsuitable teaming policy, inappropriate NIOC shares or limits, or an MTU mismatch.
Checks: Review uplink utilization and failover state, inspect NIOC traffic-class allocation, check end-to-end MTU, and confirm that the load-balancing policy suits the traffic pattern.
Health Check reports VLAN or MTU issues
Likely causes: A VLAN is absent from a physical trunk, native VLAN assumptions differ, or the physical network does not support the configured MTU.
Checks: Compare distributed port-group VLAN settings with switch-port trunks, confirm native VLAN behavior where relevant, and validate MTU across host NICs, physical switches, and destination networks.
Exam-Relevant Notes
- The primary distinction is centralized vCenter Server management and multi-host scope, not a different Layer 2 forwarding function.
- Both vSS and vDS support common functions such as Layer 2 forwarding, VLANs, NIC teaming, and outbound traffic shaping.
- A vDS requires vCenter Server, while a Standard Switch is configured independently on each ESXi host.
- vMotion depends on compatible networking at the destination host, including port-group availability, VLAN reachability, and uplink connectivity.
- LACP requires compatible configuration on the vDS and physical switch.
- Network Health Check helps identify VLAN and MTU mismatches; it does not fix the physical network automatically.
- Switch-version selection must account for both minimum compatible vSphere releases and required features.
Summary
A vSphere Distributed Switch is a vCenter-managed logical Layer 2 switch that can span multiple ESXi hosts. Distributed port groups provide reusable network and policy definitions, while host pNICs supply the physical uplinks. Compared with a Standard Switch, a vDS reduces repetitive per-host configuration and supports advanced capabilities such as NIOC, NetFlow, port mirroring, Health Check, PVLAN, LACP, LLDP, traffic filtering and marking, and management-network recovery features.
Successful deployment still depends on host-specific NIC mappings and a correctly configured physical network. Plan the design, select a compatible vDS version, coordinate VLAN, MTU, trunking, and aggregation settings, and migrate management networking cautiously. For a related overview, see Distributed Switches Explained.