Vmware Esxi

VMware ESXi Virtual Switches Explained: Standard and Distributed Switching

Learn how ESXi virtual switches connect VMs, VMkernel services, physical NICs, VLANs, and physical networks. Compare vSS and vDS with traffic flows and troubleshooting.

VMware ESXi is a bare-metal hypervisor: software installed directly on a physical server to host virtual machines (VMs). vSphere is the broader VMware virtualization platform and management ecosystem associated with ESXi. One of ESXi's key functions is providing software-based Ethernet switching between virtual machines, ESXi host services, and physical network adapters.

This lesson explains the two main switch types: the vSphere Standard Switch (vSS) and the vSphere Distributed Switch (vDS). It also covers port groups, VMkernel adapters, uplinks, VLANs, traffic flow, resiliency, security, administration, and troubleshooting.

Why ESXi Needs a Virtual Switch

A virtual machine has a virtual network adapter, called a vNIC. The vNIC cannot plug directly into a physical cable. Instead, it connects to a named VM port group, which is attached to an ESXi virtual switch. The virtual switch can then deliver frames to another virtual endpoint or send them through a physical NIC.

The virtual switch is therefore the connection point between virtual networking and physical Ethernet networking. It performs core Layer 2 functions such as receiving Ethernet frames, examining destination MAC addresses, and forwarding frames to the appropriate virtual port or uplink.

Switching does not always require the physical network. If two VMs are on the same ESXi host, the same virtual switch, and the same VLAN, their frames can remain inside the host. A physical uplink is not required for that local communication. Guest IP configuration and guest firewalls still determine Layer 3 and application reachability.

Virtual Switching Compared with a Physical Switch

A physical Ethernet switch provides physical ports. An ESXi virtual switch provides virtual ports. A vNIC or VMkernel adapter connects to a virtual port through a port group, much as a device connects to an access port on a physical switch.

Switches learn by observing the source MAC address of incoming frames. Conceptually, the switch records that a MAC address is reachable through a particular port. When a frame arrives, the switch uses its learned MAC-to-port information to forward the frame toward the destination. If the destination is unknown, the frame may be flooded within the relevant Layer 2 segment until the destination is learned.

ESXi virtual switching resembles physical switching, but it does not necessarily expose every feature of a physical switch, and it is managed through VMware configuration objects rather than identical physical-switch commands. The physical switch remains responsible for its own ports, VLAN handling, and upstream forwarding.

Core ESXi Virtual Networking Components

Virtual Switch

A virtual switch, often called a vSwitch, is the ESXi software switching construct that connects virtual endpoints and, when configured, physical uplinks.

Virtual Port and Port Group

A virtual port is a logical switch connection point. A port group is a named collection of virtual ports with shared settings. Its policies can include VLAN assignment, security behavior, traffic shaping, and NIC teaming or load-balancing behavior.

A VM port group is intended for VM adapters. A port group can also be used for a VMkernel adapter when the design and switch type support that configuration, but VM guest traffic and host-service traffic should be treated as distinct traffic classes.

Physical Uplink and vmnic

An uplink is the association between a virtual switch and an ESXi physical NIC. ESXi names physical Ethernet adapters with identifiers such as vmnic0 and vmnic1. Uplinks carry frames between the virtual switch and connected physical switches.

vNIC and VMkernel Adapter

A vNIC is a virtual network adapter installed in a guest VM. A VMkernel adapter is an IP-capable ESXi host networking endpoint. It is not a VM adapter and is used by host services such as management and vMotion.

VM Port Groups

A VM port group provides a named network attachment target for virtual machines. When you connect a VM's vNIC to a selected port group, the VM receives that port group's VLAN and policy behavior.

Important port-group concepts include:

• VLAN assignment: Identifies the Layer 2 segment that the port group belongs to.
• Security policy: Controls behaviors such as promiscuous mode, MAC address changes, and forged transmits.
• Traffic shaping: Can impose policy-based limits or bursts where supported.
• NIC teaming: Selects active, standby, or unused uplinks and determines how traffic is distributed.

VMs using the same port group can communicate locally when their VLAN and security configuration permit it. External connectivity requires a working physical uplink and a matching physical-switch path carrying the required network.

VMkernel Adapters and Host-Service Traffic

VMkernel adapters provide host IP networking. They have settings such as an IP address, subnet mask or prefix length, and routing behavior. Their traffic is different from ordinary guest VM traffic because it originates from ESXi services rather than from a guest operating system.

Depending on the vSphere release and environment, VMkernel adapters can carry:

Provisioning and replication-related services may also use VMkernel networking, depending on the version and configuration. Separate VMkernel adapters, VLANs, subnets, or physical paths can isolate traffic, reduce contention, improve performance, and provide resiliency.

A default gateway is generally a host-level TCP/IP stack routing setting. It is not an independently arbitrary gateway that can be assigned to every VMkernel adapter in every configuration. Additional routes or TCP/IP stacks may be needed for more complex designs.

How Uplinks Affect Connectivity

Physical NICs are assigned to a virtual switch as uplinks. Port groups on a standard switch normally use the switch's available uplinks, unless an explicit policy marks an uplink active, standby, or unused.

A virtual switch with no uplink can still provide host-only communication between attached virtual endpoints. However, it cannot provide access to a physical LAN, an external storage target, or another ESXi host through the physical network.

VLANs and Network Segmentation

A VLAN is a Layer 2 segmentation mechanism. A port group VLAN ID identifies which VLAN the attached traffic belongs to. 802.1Q is the Ethernet standard used to carry VLAN tags across a link.

For multiple tagged VLANs to cross an ESXi uplink, the connected physical-switch interface commonly needs to be configured as a trunk or equivalent VLAN-allowing link. The physical switch must permit every VLAN required by the port groups using that uplink.

• Management VLAN 10: Used by ESXi management VMkernel adapters.
• Virtual machine VLAN 20: Used by guest application traffic.
• vMotion VLAN 30: Used by migration VMkernel adapters.
• Storage VLAN 40: Used by iSCSI, NFS, or another IP storage design.

Tagged and untagged traffic must be designed consistently. An untagged or native VLAN on the physical switch must match the ESXi port-group behavior if untagged traffic is used. A VLAN mismatch can produce a connection that appears locally functional but fails when traffic leaves the host.

vSphere Standard Switch

A vSphere Standard Switch (vSS) is configured and managed independently on each ESXi host. Its port groups, VLANs, uplinks, and policies belong to that host's local configuration.

For workload mobility between hosts, comparable networking must be configured on every possible destination. For example, if two hosts each need a port group named Production with VLAN 100, both hosts require compatible port-group settings, working uplinks, and physical-switch paths that carry VLAN 100.

vSS is appropriate for small deployments, standalone hosts, labs, and environments where per-host configuration is acceptable. Its principal operational risk is configuration drift: one host may gradually differ from another, causing migration failures or inconsistent connectivity.

For a practical standard-switch workflow, see Create Standard Switches.

vSphere Distributed Switch

A vSphere Distributed Switch (vDS) is a centrally managed logical switch shared by multiple ESXi hosts in a vCenter inventory. Its distributed port groups provide centrally defined connection targets and policies.

Centralized vDS management helps apply consistent VLAN, security, teaming, and other supported policies across participating hosts. The hosts still have separate physical NICs, cables, and physical-switch ports. Central management does not remove the need to connect and validate each host's uplinks.

Verify supported vDS capabilities and licensing against the deployed vSphere version. Older materials may use the terms vNetwork Standard Switch and vNetwork Distributed Switch; current terminology is vSS and vDS.

For a focused overview, see Distributed Switches Explained.

Traffic Flow Scenarios

Example: Local VM-to-VM Communication

Two VMs on one ESXi host connect to the same VM port group and VLAN. The virtual switch can forward their frames internally. No physical uplink is needed solely for this path, although the VMs still need correct guest IP settings and firewall rules for the intended communication.

Example: VM Access to the Physical LAN

A VM uses a port group on VLAN 20. The virtual switch uses vmnic0, which connects to a physical switch that carries VLAN 20. The path is guest vNIC, port group, virtual switch, vmnic0, physical switch, and the LAN destination. The ESXi and physical-switch VLAN design must agree.

Example: Management and vMotion Separation

An ESXi host can use one VMkernel adapter for management on VLAN 10 and another for vMotion on VLAN 30. Separate VLANs and subnets distinguish host-service traffic. Separate uplinks or failover policies can provide additional isolation or resiliency when the physical design supports them.

Resiliency and Performance Basics

NIC teaming uses multiple uplinks for failover and, depending on policy, traffic distribution. Common conceptual states are active, standby, and unused. If an active link fails, traffic can move to a standby uplink.

Failover detection determines how a failure is recognized. Failback determines whether traffic automatically returns to the preferred uplink after recovery. Load-balancing policies determine how eligible traffic is distributed.

Multiple NICs improve availability and may distribute traffic from multiple flows, but they do not automatically double the bandwidth of one network flow. Link aggregation features also require compatible physical-switch configuration; mismatched aggregation settings can cause loss of connectivity or unstable forwarding.

High-volume or latency-sensitive traffic such as storage and vMotion may need separate VLANs, VMkernel adapters, uplinks, or physical paths. The correct choice depends on bandwidth, latency, failure domains, and the capabilities of the deployed vSphere release.

Security and Policy Boundaries

Port-group security settings commonly include:

• Promiscuous mode: Allows a virtual adapter to receive frames not addressed to its own MAC address.
• MAC address changes: Controls whether a guest can change the effective MAC address associated with its adapter.
• Forged transmits: Controls whether frames sent by a guest with a source MAC different from the configured address are accepted.

The normal posture is restrictive. Exceptions may be needed for nested virtualization, network monitoring, virtual appliances, or another specific workload. Apply the narrowest exception at the appropriate port-group scope and assess its security consequences first.

VLAN separation is not a substitute for correct security design. Isolation depends on consistent ESXi port-group settings, physical-switch VLAN configuration, routing controls, and appropriate guest security.

Administrative Workflow

1. Identify the required traffic classes, VLANs, subnets, gateways, bandwidth, and failure domains.
2. Create a vSS on each required host, or create a vDS in vCenter and add the participating hosts.
3. Attach the intended physical NICs, such as vmnic0, as uplinks.
4. Create VM port groups or distributed port groups with meaningful names and intended VLAN IDs.
5. Configure security, traffic-shaping, and teaming policies according to the design.
6. Create VMkernel adapters, assign their IP configuration, and enable the intended host services.
7. Connect each VM vNIC to the correct VM port group.
8. Configure the physical switch to carry the required VLANs and verify link and aggregation settings.
9. Validate adapter-to-port-group assignments, uplink status, VLAN consistency, IP reachability, and service configuration.

Interface names and menu labels vary between ESXi and vCenter releases. Use the labels displayed by the deployed version rather than assuming every release presents identical screens.

Validation Commands

These ESXi commands help inspect standard-switch and VMkernel state:

esxcli network nic list

Lists physical NIC names, link state, speed, and duplex.

esxcli network vswitch standard list

Reviews standard switches, uplinks, and port-group associations.

esxcli network ip interface list

Lists VMkernel interfaces and basic configuration.

esxcli network ip interface ipv4 get

Reviews IPv4 settings associated with VMkernel interfaces.

vmkping <destination-ip>

Tests IP connectivity from an ESXi VMkernel networking context.

vmkping -I vmkX <destination-ip>

Tests connectivity through a specified VMkernel adapter. For storage or migration testing, also validate the relevant VLAN, subnet, MTU, route, and service assignment.

Troubleshooting Common Problems

Local VM Communication Works, External Access Fails

• Check whether a physical uplink is attached and its link is up.
• Confirm that the physical switch port is enabled and connected to the expected network.
• Verify that the required VLAN is permitted on the physical-switch interface.
• Check the guest IP address, prefix or subnet mask, default gateway, and DNS settings.

Connectivity Is Lost After VM Migration

• Confirm that the destination host has an equivalent vSS port group, or that both hosts use the correct distributed port group.
• Compare VLAN IDs, uplink policies, and teaming settings on both hosts.
• Verify that the destination host's physical-switch connection carries the required VLAN.
• Consider a vDS when centralized consistency is appropriate.

vMotion or Storage VMkernel Traffic Cannot Reach Its Peer

• Inspect the VMkernel adapter's port-group connection and enabled service.
• Use vmkping and, when necessary, vmkping -I vmkX through the relevant adapter.
• Validate IP addressing, routing, VLAN, MTU, and uplink policy end to end.

Redundant Uplinks Do Not Fail Over

• Review which uplinks are active, standby, and unused.
• Verify that the standby path is cabled and carries the same required VLANs.
• Review physical link-state detection and upstream configuration.
• Check for mismatched aggregation settings between ESXi and the physical switch.

A Workload Requires Promiscuous Mode or MAC Exceptions

• Confirm the actual requirement, such as nested virtualization, monitoring, or a virtual appliance.
• Apply the smallest required exception at the appropriate port-group scope.
• Review the security impact before enabling the setting.

Key Exam and Design Notes

• A vSwitch is a software Layer 2 switching construct; it is not automatically a router or default gateway.
• A VM port group is the named attachment target for a VM vNIC and carries shared network policies.
• A VMkernel adapter is an ESXi host endpoint for management and infrastructure services.
• A vmnic is a physical ESXi NIC; an uplink connects that NIC to a virtual switch.
• Same-host, same-VLAN traffic may remain entirely inside ESXi.
• Cross-host or external traffic requires a valid physical uplink and physical-switch path.
• vSS configuration is host-local; vDS policy is centrally managed across participating hosts.
• Matching VLAN and physical-switch configuration is essential for connectivity.
• NIC teaming improves availability and may distribute multiple flows, but it does not automatically increase the bandwidth of one flow.
• Feature names, supported services, and licensing requirements can vary by vSphere release.

For broader study, see the VMware ESXi Online Course, Configure VLANs, Configure iSCSI Software Initiator, and Configure NFS Datastore lessons.