VMware ESXi and vSphere Cluster Management

VMware vSphere Standard Switch (vSS) Explained

Learn how the VMware vSphere Standard Switch connects VMs and VMkernel services to physical networks using port groups, VLANs, uplinks, teaming, and policies.

A vSphere Standard Switch (vSS), commonly called a vSwitch, is a software-based Layer 2 Ethernet switch that runs inside one ESXi host. It connects virtual machines, ESXi host services, and physical network adapters.

Layer 2 is the Ethernet switching layer. It forwards frames using MAC addresses, which are hardware-style addresses assigned to network interfaces. Like a physical switch, a vSS receives Ethernet frames, learns or uses MAC-address information, and forwards frames toward the appropriate logical or physical port.

What a vSphere Standard Switch Does

ESXi normally creates a default standard switch during installation. Administrators can use that switch or create additional vSS instances for different network designs.

A vSS is local to an individual ESXi host. It provides forwarding between:

  • Virtual machine virtual network adapters, called vNICs.
  • VMkernel adapters, such as vmk0, used by ESXi services.
  • Physical NICs, commonly named vmnic0, vmnic1, and so on, when those NICs are assigned as uplinks.

A standard switch is not a physical appliance and does not automatically create connectivity outside the host. External connectivity requires a suitable uplink, a live physical path, and compatible physical-switch configuration.

Host-Scoped Management

Each vSS is configured and maintained independently on its ESXi host. A cluster does not automatically synchronize standard-switch settings merely because its hosts are members of the same cluster.

For workloads that can run on multiple hosts, administrators commonly recreate equivalent settings on every relevant host. These settings may include:

  • Port group names.
  • VLAN IDs.
  • Uplink assignments.
  • Active, standby, and unused uplink order.
  • Security and traffic-shaping policies.

This host-local model differs conceptually from a vSphere Distributed Switch (vDS), which uses a separately managed switching model designed to provide centralized configuration across multiple ESXi hosts.

vSS and vDS Conceptual Comparison

Configuration scope: A vSS is configured per ESXi host; a vDS is managed across participating hosts.

Configuration consistency: vSS consistency must be maintained manually; a vDS is intended to distribute configuration centrally.

Management approach: vSS settings are maintained on each host; vDS settings are managed through the vSphere control plane.

Introductory use case: A vSS is suitable for foundational host networking and smaller designs; a vDS is useful when centralized, multi-host network management is required.

Core vSS Components

The components form a path from a workload or ESXi service to an Ethernet network.

vSphere Standard Switch: Connects to switch ports, port groups, VMkernel adapters, VM vNICs, and physical uplinks. Its primary role is Layer 2 forwarding. A typical example is vSwitch0.

VM network port group: Connects to VM vNICs. It supplies a name and shared settings such as VLAN, teaming, security, and shaping. An example is Production-VM-Network.

VMkernel port group: Connects to VMkernel adapters rather than guest vNICs. It defines the network used by services such as management or vMotion.

Virtual machine vNIC: Connects a guest operating system to a VM network port group.

VMkernel adapter: Connects an ESXi service interface, such as vmk0, to a VMkernel port group.

Physical NIC/uplink: Connects the vSS to the external physical network. Examples include vmnic0 and vmnic1.

Ports and Port Groups

A switch port is a logical connection point on the vSS. Virtual NICs, VMkernel adapters, and uplinks consume these logical connections.

A port group is a named logical definition applied to a collection of virtual switch ports. It allows attached adapters to share settings. The port group name is the network selection shown when attaching a VM network adapter in the vSphere Client.

Port groups are commonly divided into two types:

  • VM network port groups are selected by guest virtual machines.
  • VMkernel port groups are selected by ESXi VMkernel adapters and host services.

Traffic Paths and Connectivity

VM-to-VM Traffic on One Host

When two VMs are attached to compatible ports on the same vSS and are on the same Layer 2 network, the vSS can switch their traffic internally. Their frames do not need to leave the ESXi host through a physical uplink.

For example, two VMs on Production-VM-Network, using the same VLAN and IP subnet, can communicate locally even if the physical uplink is unavailable. This does not provide access to external devices; it only keeps eligible local traffic inside the host.

Traffic Between Hosts

When VMs on different ESXi hosts communicate, traffic normally leaves the source host through a vSS uplink, crosses the physical switching infrastructure, and enters the destination host through its uplink. The physical network must provide a path between the hosts, and the required VLAN must be available on both paths.

VM-to-Physical Network Traffic

Traffic from a VM to a physical server, router, storage system, or other device exits through a vmnic uplink. The physical switch ports, VLAN handling, IP addressing, routing, and any guest firewall rules must all be correct.

VMkernel Traffic

VMkernel services use VMkernel adapters and VMkernel port groups. Management, vMotion, storage, and Fault Tolerance logging traffic follow the same general pattern: the VMkernel adapter connects to a port group, the vSS forwards the traffic, and an uplink carries it externally when the destination is outside the host.

Same-host VM-to-VM traffic: Source and destination are VMs on one host. It uses a VM port group and does not necessarily require a physical uplink. The relevant port group, VLAN, and guest IP settings must match.

VM-to-VM traffic across hosts: Source and destination are VMs on different hosts. It uses VM port groups and requires working uplinks, physical switching, and compatible VLAN transport.

VM-to-physical network traffic: A VM communicates with an external device. It uses a VM port group and requires an uplink, physical switch path, VLAN handling, and correct IP configuration.

ESXi management: An ESXi VMkernel adapter communicates with management systems. It uses a VMkernel port group and normally requires an uplink and management VLAN path.

vMotion: VMkernel adapters on source and destination hosts exchange migration traffic. The vMotion service, addressing, VLAN path, and MTU must be correct.

iSCSI or NFS storage: VMkernel networking reaches storage targets or servers. The storage service, VLAN, routing or switching path, and storage-side configuration must align.

Fault Tolerance logging: VMkernel networking carries FT logging traffic between hosts. The FT service, port group, VLAN, uplinks, and end-to-end path must be available.

VM Network Port Groups

A VM port group is the network presented to guest virtual NICs. When adding or editing a VM adapter, the administrator selects a port group by name.

For example:

Port group: Production-VM-Network
VLAN ID:    120
Uplinks:    vmnic0, vmnic1

If a VM may migrate or be moved to another ESXi host, the destination host should provide a port group with the same intended name and compatible VLAN, uplink, teaming, security, and shaping settings. A matching name alone does not guarantee matching connectivity.

VMkernel Port Groups and Services

VMkernel port groups connect VMkernel adapters, not guest vNICs. A design can use separate VMkernel adapters and port groups for different services:

  • Management: ESXi host management and administration.
  • vMotion: Live migration traffic between ESXi hosts.
  • IP storage: iSCSI and NFS connectivity.
  • Fault Tolerance logging: State and logging traffic used by Fault Tolerance.

Service traffic can be separated with distinct VMkernel adapters, VLANs, port groups, and physical uplinks. Separation may improve security, performance predictability, troubleshooting, or availability, depending on the design.

Physical Uplinks

A physical NIC becomes a vSS uplink when it is assigned to the switch. The uplink carries traffic between virtual networking on the ESXi host and the external physical network.

No external connectivity exists for a port group unless a suitable uplink and physical network path are available. Local same-host switching can still work without that external path.

Physical switch requirements typically include:

  • A connected and operational switch port.
  • The VLANs required by the port groups.
  • Access-style handling when one VLAN is intentionally presented to an uplink.
  • Trunk-style transport when multiple VLANs must share the uplink.
  • Compatible speed, duplex, MTU, teaming, and link-failure behavior.

VLAN Support

A VLAN is a Layer 2 segmentation mechanism identified by a VLAN ID. VLANs allow multiple logically separate Ethernet networks to use shared switching infrastructure.

In a typical ESXi design, the VM or VMkernel port group contains the VLAN identification. The vSS sends traffic through its uplink, and the physical switch port must handle that VLAN correctly.

For example, a VM port group configured with VLAN 120 requires the physical path to carry VLAN 120 to the destination network. If the physical switch port does not permit that VLAN, the VM may appear connected while failing to reach its gateway or other devices.

VLAN configuration must align end-to-end: port group, uplink, physical switch port, inter-switch links, destination segment, and routing where applicable.

NIC Teaming and Failover

Multiple physical uplinks can be assigned to a vSS for redundancy and, depending on the selected policy, traffic distribution. A common configuration uses one active uplink and one standby uplink.

When the active uplink or its path fails, the vSS can move traffic to the standby uplink according to its failover policy. Active-active designs may distribute traffic across multiple uplinks, but the selected behavior must be compatible with the physical switch design.

Teaming and failover settings can be configured at the vSS level. A port group can also override inherited settings when a particular workload or service needs a different uplink arrangement.

Example:
Management port group
  Active:  vmnic0
  Standby: vmnic1

Production VM port group
  Active:  vmnic1
  Standby: vmnic0

Redundancy requires more than two cables. Both physical switch ports must be connected to suitable networks, carry the required VLANs, and provide an upstream path that supports the chosen teaming behavior.

Traffic Shaping

Outbound traffic shaping constrains traffic transmitted from a vSS or port group. Common controls include:

  • Average bandwidth: The long-term target rate.
  • Peak bandwidth: The maximum permitted rate during bursts.
  • Burst size: The amount of traffic that may temporarily exceed the average rate.

Shaping can be useful for limiting a noncritical workload or controlling egress traffic. Outbound shaping does not automatically solve congestion elsewhere and does not, by itself, control every inbound traffic condition.

Security Policies

Security policies can be applied at the switch or port-group level. The effective setting may be inherited from the vSS or overridden on a specific port group.

  • Promiscuous mode: Allows a connected guest to receive frames beyond those addressed to its own MAC address. It may be required for some packet-capture or monitoring appliances, but it increases exposure and should be narrowly scoped.
  • MAC address changes: Controls whether a guest can change the effective MAC address recognized by the virtual switch.
  • Forged transmits: Controls traffic transmitted with a source MAC address different from the MAC assigned to the virtual adapter.

Changing restrictive defaults may be necessary for packet capture, nested virtualization, firewalls, load balancers, or other nonstandard workloads. Enable exceptions only on the required port group and understand the security implications.

Discovery Protocol Support

Cisco Discovery Protocol (CDP) can provide neighbor information on supported physical network connections. This information can help identify the physical switch, connected switch port, and uplink mapping.

CDP is useful when checking cabling and troubleshooting an unexpected vmnic-to-switch-port relationship. It does not replace correct VLAN, teaming, or physical-switch configuration, and it is not universal across every switch vendor. Use the discovery method supported by the physical network environment.

Capacity and Scaling

The following figures are historical vSS capacity values:

Standard-switch ports per host: Up to 4,096. This represents the total standard-switch port capacity associated with an ESXi host.

Active ports per host: Up to 1,016. These are ports currently active for connected or assigned networking functions.

Port groups per standard switch: Up to 512. These are named logical groups of ports with shared settings.

These figures can vary by ESXi or vSphere version, edition, hardware, and other supported configuration details. Validate limits against the VMware documentation for the exact release being deployed before designing at scale.

Conceptual Topology

A simple host layout might contain one vSS, separate VM and VMkernel port groups, and two physical uplinks:

ESXi host
├── vSphere Standard Switch
│   ├── Production-VM-Network (VLAN 120)
│   │   ├── VM-1 vNIC
│   │   └── VM-2 vNIC
│   ├── Management (VLAN 110)
│   │   └── vmk0
│   └── vMotion (VLAN 130)
│       └── vmk1
├── vmnic0 uplink
└── vmnic1 uplink
        │
        └── Physical Ethernet switch

In this example, management and guest traffic use separate logical port groups while sharing the vSS and possibly sharing physical uplinks. A design that requires stronger separation can use different uplinks or physical networks.

Administration Workflow

  1. Create a vSS on the ESXi host, or use the default switch created during installation.
  2. Assign one or more physical vmnic adapters as uplinks.
  3. Create a VM port group and set its VLAN ID.
  4. Create a VMkernel port group for each required host-service network.
  5. Create or attach VMkernel adapters and enable applicable services such as management, vMotion, storage, or Fault Tolerance logging.
  6. Configure uplink teaming and failover order at the vSS level, or override it for a port group when appropriate.
  7. Set security and outbound shaping policies only when the design or workload requires them.
  8. Verify physical-switch VLANs, uplink paths, IP addressing, gateways, MTU, and service reachability.

Use consistent naming, such as Production-VM-Network, Management, and vMotion. Consistency makes multi-host comparisons and troubleshooting much easier, but administrators must still compare the actual VLAN, uplink, and policy values.

Illustrative ESXi CLI Concepts

Command syntax and available options can differ between ESXi releases. Verify commands against the target release before use, and avoid changing management networking remotely unless you have an alternate access method.

esxcli network vswitch standard list
esxcli network vswitch standard uplink list
esxcli network vswitch standard portgroup list
esxcli network ip interface list
esxcli network nic list
vmkping -I vmk1 <destination-address>

The esxcli network vswitch standard command family is used to inspect and manage standard switches, uplinks, and port groups. The esxcli network ip interface commands inspect VMkernel interfaces. esxcli network nic list identifies physical NICs and link state. Use vmkping with the appropriate VMkernel source when validating vMotion, storage, or another VMkernel path.

Practical Examples

Default Management and VM Layout

One vSS can contain a management VMkernel port group with vmk0 and a separate VM network port group for guest vNICs. Both can use the same physical uplinks while remaining logically distinct through port-group settings and VLANs.

Dedicated vMotion Network

Create a dedicated VMkernel adapter and port group named vMotion, assign VLAN 130, and use preferred or dedicated uplinks if the design requires separation from production VM traffic.

Redundant VM Uplinks

Assign vmnic0 and vmnic1 to the VM network. Configure one as active and the other as standby, or use a supported active-active policy. Confirm that both physical switch ports carry the required VLANs.

Troubleshooting Common Problems

Local VM Communication Works, External Communication Fails

Likely causes include a missing or down uplink, no physical path, a VLAN mismatch, incorrect guest addressing, or a guest firewall.

  • Confirm the VM port group and VLAN ID.
  • Check vmnic link state and vSS uplink assignment.
  • Validate the physical switch port and VLAN transport.
  • Test the guest IP configuration and default gateway.

Connectivity Is Lost After Moving a VM to Another Host

The destination may lack the port group, may use a different VLAN or policy under the same name, or may have uplinks connected to the wrong physical network.

  • Compare port group names, VLAN IDs, security settings, and teaming policies.
  • Confirm VLAN availability and physical connectivity for every participating host.

vMotion or Storage Traffic Fails While VM Networking Works

Check that the VMkernel adapter exists, has correct addressing, is attached to the correct VMkernel port group, and has the required service enabled. Validate the VMkernel VLAN, uplink path, and MTU end-to-end. Use VMkernel-aware testing such as vmkping.

Uplink Redundancy Does Not Work

Review active, standby, and unused assignments, link state, cabling, VLAN availability, and the compatibility between the selected teaming policy and physical switching design.

A Monitoring or Nested Workload Misses Frames

Verify that the workload is on the correct port group and that its requirements justify changes to promiscuous mode, MAC address changes, or forged transmits. Prefer a dedicated, narrowly scoped port group for exceptions.

Exam-Relevant Notes

  • A vSS is a host-local software Layer 2 switch.
  • A port group is a named collection of ports sharing settings; it is not the same thing as the vSS itself.
  • VM port groups serve guest vNICs, while VMkernel port groups serve ESXi VMkernel adapters.
  • Same-host VM traffic may remain inside the vSS without using a physical uplink.
  • External and cross-host traffic require suitable uplinks and correctly configured physical networks.
  • VLAN settings must align between ESXi and the physical switching path.
  • Standard-switch configuration is not automatically synchronized across hosts.
  • Teaming, shaping, security, and VLAN settings can affect a port group’s effective behavior.

For a focused reference to this topic, see Standard Switch Explained.