VSS or VDS? A Decision Guide for vSphere Production Networking

The Decision You Are Actually Making

Choosing between the vSphere Standard Switch (VSS) and the vSphere Distributed Switch (VDS) is rarely about raw throughput. It is a decision about licensing, cluster scale, and whether you need centralized network policy. If you run a single ESXi host with no vCenter Server, VSS is the only supported option. If you operate a multi-host cluster with vCenter and require consistent port policies, private VLANs, or port mirroring, VDS is the supported path—provided you hold the necessary licensing.

Constraints That Narrow the Choice

Four constraints usually decide the question before any performance testing begins:

• vCenter dependency. VDS configuration lives in vCenter Server. Without a licensed vCenter instance, you cannot create or manage a VDS.
• Licensing tier. VSS ships with every ESXi edition. VDS requires vCenter Server and typically an Enterprise Plus license or an Advanced Networking add-on.
• Cluster homogeneity. All hosts joining a VDS should run compatible vSphere versions. A version mismatch can block host addition or cause configuration drift.
• Feature requirements. Private VLANs, distributed port mirroring, and network-aware vSphere DRS are VDS-only capabilities.

VSS vs. VDS at a Glance

Decision factor	vSphere Standard Switch (VSS)	vSphere Distributed Switch (VDS)
Licensing	Included with all ESXi editions	Requires vCenter Server; typically Enterprise Plus or Advanced Networking
Configuration scope	Per-host, manual	Centralized in vCenter, shared across cluster hosts
NIC teaming and failover	Configured independently on each host	Defined once at the port group level, inherited by member hosts
Private VLANs	Not supported	Supported
Port mirroring	Not supported	Supported
vSphere DRS integration	Basic	Network-aware DRS
Migration path	Manual or Migration Wizard	Native vCenter workflow

Trade-offs in Practice

VSS wins on simplicity and independence. There is no vCenter dependency, no extra license cost, and the configuration is entirely local to each host. The cost is operational: in a cluster of ten hosts, you must manually replicate every port group, VLAN ID, and teaming policy. One host can easily drift out of alignment, creating hard-to-diagnose connectivity gaps.

VDS wins on consistency and features. A port group created once in vCenter is available to every host added to the switch. This eliminates drift and enables advanced capabilities such as private VLANs and distributed port mirroring. The trade-offs are licensing cost, a hard dependency on vCenter Server for configuration changes, and a small management-plane overhead. For most workloads the data-plane performance difference is negligible, though VDS adds a modest amount of control-plane work that can affect host boot time under heavy load.

Implementing and Validating a VDS

The following example assumes a small production cluster with vCenter Server, Enterprise Plus licensing, and two ESXi hosts running the same vSphere version. The goal is a VDS with a shared port group and verified uplink failover.

Create the Switch and Add Hosts

In the vSphere Client, navigate to your datacenter, right-click, and select Distributed Switch > New Distributed Switch. Choose a switch version that matches your hosts. After creation, edit the switch and add both ESXi hosts, assigning one physical NIC from each host as an uplink.

If you prefer PowerCLI, run the following from a management workstation with the PowerCLI module installed. You need vCenter Administrator or equivalent network privileges. Exact cmdlet parameters vary by PowerCLI version, so verify against your module documentation.

Connect-VIServer -Server vcenter.prod.local

$datacenter = Get-Datacenter -Name "Datacenter-Prod"
$vds = New-VDSwitch -Name "VDS-Prod" -Location $datacenter

$hosts = Get-VMHost -Name "esxi01.prod.local","esxi02.prod.local"
Add-VDSwitchVMHost -VDSwitch $vds -VMHost $hosts

$pg = $vds | New-VDPortGroup -Name "App-Tier" -NumPorts 120

Replace vcenter.prod.local, Datacenter-Prod, and the hostnames with your actual inventory names.

Configure Port Group Teaming

Select the new port group and edit its teaming and failover policy. A common production choice is Route based on physical NIC load with both uplinks active and one standby failover order. Because the policy is defined at the port group level, both hosts inherit it automatically.

Validate Uplink Failover

To confirm the configuration works, disable one physical uplink on a host—either by unplugging the cable or by setting the adapter to disconnected in the host's networking UI. Check that the remaining uplink carries traffic and that virtual machines on that host maintain network connectivity. The vSphere Client should show the failed adapter as down and the standby adapter as active.

Optional: Port Mirroring and Throughput Check

If you licensed the feature, enable port mirroring on the VDS port group and direct traffic to a monitoring VM. Use a packet capture tool such as tcpdump on the monitoring VM to confirm that mirrored frames appear only on the intended destination. For a performance sanity check, run an iperf test between two VMs on separate hosts connected to the VDS and compare the result to a similar test on VSS. Expect comparable throughput for standard workloads.

Limitations and Rollback

VDS is not a drop-in replacement for every environment. It requires vCenter Server, so standalone hosts cannot participate. Upgrading from VSS to VDS can temporarily disrupt VMkernel traffic—the host interfaces used for management, vMotion, and storage—if uplink groups are not pre-configured before migration. If a host runs a different vSphere version, adding it to the VDS may fail.

If the new switch causes problems, roll back by moving VM network adapters back to a VSS port group, removing the hosts from the VDS, and deleting the distributed switch. Because this changes network state, schedule the rollback during a maintenance window and verify VM connectivity after each step.

Practical Verification Checklist

1. Confirm both hosts show identical port group settings in the vSphere Client.
2. Disable one uplink and verify the remaining uplink carries traffic without VM downtime.
3. Check that VMkernel adapters remain reachable after the change.
4. If using port mirroring, confirm the monitoring VM receives only the intended mirrored traffic.