What Is a Standard Switch and Distributed Switch in VMware vSphere
When you set up VMware’s ESXi hypervisors and vCenter, networking between virtual machines (VMs) and hosts is handled by virtual switches. There are two main types of virtual switches in VMware environment:
- vSphere Standard Switch (VSS), also called “Standard Switch”
- vSphere Distributed Switch (vDS), or “Distributed Switch”
These virtual switches function like physical Ethernet switches, but they operate in software. They enable VMs, VMkernel services (like vMotion and IP storage), and host uplinks (physical NICs) to communicate with each other and the outside network.
Standard Switch (VSS)
Each ESXi host has its own standard switches. The configuration is stored on that host.
You create vSwitches locally on the host, add physical NICs (uplinks), create port groups, and set up VMkernel adapters.
This is part of what comes with ESXi. No extra centralized switch is required.
Distributed Switch (vDS / dvSwitch)
This was introduced to make it easier to manage networking across multiple ESXi hosts.
The configuration (port groups, uplinks, policies) is managed from vCenter and then sent to all hosts connected to that vDS.
Hosts get a “proxy switch” or “host proxy switch” that mirrors the vDS configuration locally. The data plane, which handles actual traffic forwarding, remains on the hosts, while the control plane is centralized via vCenter.
Key Features: Standard Switch vs. Distributed Switch
Below are the features supported in each. The text highlights what vDS adds over VSS, especially in relation to vSphere 8.0 and what is expected to change or stay the same in vSphere 9.0.
| Feature | Standard Switch (VSS) | Distributed Switch (vDS) |
|---|---|---|
| Management location | On each ESXi host individually. Admin must manually configure per host. | Centralized via vCenter. One place to view/configure the network for all hosts in a datacenter. |
| Creation of port groups | Must do on each host if all hosts need to be consistent. Names & VLAN tags must match manually. | Create distributed port groups once, with policies inherited to all member hosts automatically. |
| Uplink configuration (physical NICs) | Uplinks assigned per host separately. Teams / failover policies per host. | Uplink groups defined at the distributed switch, physical NICs on hosts mapped accordingly. Failover, load balancing etc. centrally configured. |
| VLAN support, traffic segmentation | vLAN, 802.1Q tagging, port groups, basic security policies are supported. | Same plus more advanced: Private VLANs (PVLANs), better monitoring etc. |
| Traffic shaping | Outbound (egress) shaping on port groups or vSwitch. Inbound is limited. | Both outbound and inbound shaping, more granular controls. Also policies like Network I/O Control (NIOC) to prioritize traffic. |
| Monitoring & diagnostics | Basic monitoring via host tools; limited visibility. | Enhanced: LLDP (Link Layer Discovery Protocol), NetFlow, Port Mirroring, network health tests etc. |
| Scalability & consistency | For small setups or few hosts, manageable. But with many hosts, tedious and error-prone. | Designed for scale. Ensures consistent network configuration across multiple hosts, simplifies management, reduces human error. |
| Licensing requirements | Included with base ESXi and no extra licensing needed. | Requires higher editions / licenses (Enterprise Plus or equivalent). May have features only available with certain license tiers. |
| Dependency on vCenter / availability | Doesn’t require vCenter for network switching to function; each host functions independently. | Management depends on vCenter. If vCenter is down, data plane still works, but you can’t change configurations from vCenter. |
How Standard vs Distributed Switches Operate
To understand the difference more technically, let’s look at how they work internally, including control plane, data plane, host proxy, and more.
Standard Switch (VSS)
Each ESXi host has its own switch instances. These have both data plane and control plane at the host level. All forwarding decisions, such as MAC learning and port mapping, along with port group policies and uplink assignments, are local.
When you need to keep configurations the same across hosts, like for vMotion, you have to manually create port groups and name them the same. You also need to assign the same VLAN IDs and uplinks. If there is a mismatch, it might cause traffic or vMotion to fail.
If a host fails or the network changes, you must log into each host and adjust the settings.
Distributed Switch (vDS)
Separation of Planes:
Management plane resides in vCenter. This is where you create, delete, or change settings, such as port groups, policies, and uplinks.
Data plane is still on ESXi hosts. Actual traffic forwarding, including packets, VLAN tagging, and switching, is done locally by the host.
Control plane enforces the configuration on hosts, which comes from vCenter, and handles updates and consistency checks. Hosts have a host proxy switch that follows the distributed switch configuration.
Consistency and Propagation: When you connect an ESXi host to a vDS, vCenter pushes the distributed switch configuration to that host. If you later add more hosts, they will receive the same configuration. If you change distributed port group policies, such as security, traffic shaping, or VLANs, those changes automatically apply to all hosts.
Policies and Advanced Features: vDS supports more advanced networking controls, including:
- Private VLANs
- Inbound traffic shaping
- Load-based teaming
- NIC load balancing across uplinks
- Network I/O control for prioritizing traffic types
- Link Layer Discovery Protocol (LLDP)
- Port mirroring
- Health checks
Migration and Upgrades: You can migrate VM networks from VSS to vDS. In newer vSphere versions, the process is safer and causes minimal disruption. vDS also has versions; for instance, each vDS version corresponds to certain capabilities based on vSphere releases. It is important to keep the vDS version compatible with ESXi hosts.
What’s New, What to Note in vSphere 8.0 and vSphere 9.0
While the main differences stay the same, the newer versions bring improvements, removals, and changes you should know about.
vSphere 8.0:
Networking updates in ESXi and vSphere 8 include support for newer high-speed NICs, better management of virtual network devices, and more efficient data path operations.
The documentation for vSphere 8.0 highlights managing both standard and distributed switches using the vSphere Networking guide. It also includes improvements to monitoring, traffic shaping, and more.
vSphere 9.0:
With the vSphere Foundations and vSphere Cloud Foundation 9.0 releases, VMware is combining some products and changing the licensing and product line packaging. For instance, separate vSphere “Standard/Enterprise Plus” editions will be replaced by broader platform SKUs.
Some features have been removed or deprecated. This includes NSX integration for certain legacy switches along with the removal or deprecation of older tools and features like Auto Deploy and Host Profiles. These changes may affect how networking and switch configuration are managed in some settings. If you’re using older networking tools with standard or distributed switch workflows, you should check for compatibility.
StarWind HCI & vSAN
There is also a stronger focus on automation, unified SDKs and APIs, such as OpenAPI 3.0, high-speed data paths, offload, and performance. These changes will especially help distributed switch implementations because central management, consistency, and policies matter more when scaling.
Differences Between vDS and VSS
To make it easy, here are differences shown through scenarios. This will help you decide when to use one option vs the other.
| Scenario & Requirement | VSS (Standard) is Enough When… | vDS (Distributed) is Better When… |
|---|---|---|
| Small setup, few hosts (1-5), simple networking | You don’t need central configs; local management; fewer VLANs; minimal changes. | Overkill-adds complexity & licensing cost without much benefit. |
| Hosts often being added or removed | Managing manually each host becomes tedious. | vDS makes adding new hosts easier: config is applied centrally. |
| Need advanced monitoring / NetFlow / LLDP | VSS has limited monitoring capabilities. | vDS provides richer diagnostics. |
| Ensuring consistency for vMotion, iSCSI, vSAN across hosts | You must manually ensure port groups and names/VLANs match across hosts. | vDS ensures consistency via centralized config. |
| Performing frequent changes (security policies, traffic shaping, etc) | Changes must be repeated per host → risk of error. | One change, propagated to all hosts quickly. |
| Licensing & vs. cost concerns | Use VSS if licensing costs, product SKUs do not allow vDS. | If you have enterprise licensing and large environment, vDS ROI is strong. |
How It Works: Data Plane, Host Proxy, Versioning etc.
Data / Control / Management Planes
Data Plane: This is where the actual network frames are processed, including VLAN tagging, VM to VM traffic, and VMkernel traffic. On VSS, both control and data are local. On vDS, the data plane remains on the hosts. When you send traffic, it does not need to pass through vCenter. vCenter manages commands but does not handle user traffic.
Control Plane: For vDS, this consists of the logic that keeps policies, port groups, and uplink configurations consistent and enforced across hosts. vCenter holds this information and distributes it to the hosts.
Management Plane: This is where administrators log in to configure the switch, including names and policies. For VSS, this is the host-level UI; for vDS, it is the vCenter UI.
Host Proxy / Hidden Standard Switch
For vDS, each host has a host proxy switch, which may be referred to as a proxy vSwitch or hidden standard switch on that host. This switch is not directly visible in all UIs, but its role is to implement the data plane according to the vDS configuration.
If VMKernel adapters or physical NICs are assigned to the vDS, the hosts perform the actual forwarding through their physical NICs and virtual ports that match the dvPortGroups.
Versioning of vDS
vDS has versions, such as version 7.0 or 8.0, which determine available capabilities. When upgrading your environment, including ESXi hosts and vCenter, you may also need to upgrade the distributed switch version to access newer features.
Upgrading vDS requires planning. Ensure hosts are compatible and that backups of configurations exist.
Best Practices and Things to do
- Always keep naming, such as port groups and VLANs, consistent when migrating from VSS to vDS.
- Ensure all ESXi hosts are compatible with the intended vDS version.
- Monitor the state of vCenter. Since vDS depends on vCenter for management, you cannot change configurations if vCenter is down, even though traffic continues to flow.
- Use versioned configurations and test them in a non-production environment first.
- Use monitoring tools available through vDS to spot misconfigurations and orphaned uplinks.
- Plan for license and SKU requirements when upgrading or using vDS in vSphere 9.0 or VCF.
Conclusion
Standard Switch (VSS) is simple and local. It is by default built into ESXi and works well for small setups with fewer hosts and minimal changes.
Distributed Switch (vDS) provides centralized management and includes features like monitoring, traffic shaping, and consistent port groups. It offers better scalability and is more appropriate for data centers or larger environments.
With vSphere 8.0 and 9.0, vDS continues to be the preferred choice for larger, modern virtual infrastructures. Newer versions improve performance, integration, and automation features, making vDS even more effective. However, it is important to consider licensing and compatibility.
Frequently Asked Questions
1. What is the difference between vSphere Standard Switch (vSS) and vSphere Distributed Switch (vDS)?
Ans: vSS is configured individually per ESXi host and its switch settings (port groups, uplinks, VLANs etc.) live locally. vDS is centrally managed via vCenter, and configurations are pushed across all member hosts, enabling consistency, advanced features (like inbound traffic shaping, NetFlow, port mirroring, etc.).
2. Do I need a special license to use vDS?
Ans: Yes, vDS (especially features like advanced monitoring, network I/O control etc.) typically requires higher-tier licensing (e.g. VMware Enterprise Plus or equivalent) in many vSphere versions. vSS comes included in most base licenses.
3. Can I migrate from Standard Switch to Distributed Switch without downtime?
Ans: Yes, with proper planning. VMware provides tools and workflows (via vCenter) for migrating VMs, VMkernel adapters, uplinks etc., from vSS to vDS with minimal or no VM downtime. But careful mapping of uplinks, port groups, and ensuring consistent configuration across hosts is needed.
4. What happens if vCenter is down when using a Distributed Switch?
Ans: The data plane (actual network traffic flow) continues to work on hosts even if vCenter is unavailable. However, you cannot make new configuration changes, propagate policy changes, or manage the distributed switch until vCenter is restored.
5. Which features are only available in vDS and not in vSS?
Ans: Some of the features unique to vDS include inbound traffic shaping, Private VLANs (PVLANs), LLDP, NetFlow, Port Mirroring, Network I/O Control, advanced load-based teaming, etc.
6. In what scenarios is vSS still a good choice?
Ans: For small setups (few hosts), environments with minimal changes, or where licensing for vDS is not available. Also when simplicity is preferred over advanced features. If you don’t need centralized control, complex monitoring, or uniformity across many hosts, vSS suffices.
7. Is configuration consistency critical between hosts when using vSS?
Ans: Yes. When using vSS, port groups, VLAN IDs, uplinks, naming must be manually kept consistent across hosts; otherwise features like vMotion or network connectivity can fail. vDS helps avoid this manual sync burden.
8. What is a host proxy switch in vDS?
Ans: It is the local representation or “proxy” on each ESXi host that implements the data plane for the vDS. Once you attach a host to a vDS, VMware creates this host-side component so that traffic, uplinks, VMkernel adapters etc. work according to the distributed switch’s centralized config.
9. How does versioning of vDS affect features and compatibility?
Ans: vDS has versions tied to vSphere releases. Some newer features (e.g. offloading, performance enhancements) are only available in newer versions of vDS. Hosts must be compatible; upgrading vDS version may be required to use latest features.
10. Are there any drawbacks or risks to using vDS?
Ans: Yes. Increased complexity, dependency on vCenter (for changes), licensing cost, potential for misconfiguration loss if vCenter fails or backups are not maintained. Also, initial setup & migration from vSS needs careful planning.
