VMware ESXi vSwitch: Port Groups, VLAN IDs and Teaming

Virtual switches (vSwitches) are the software layer that connects VMs to each other and to the physical network, and almost every virtualization connectivity problem traces back to one of three concepts misunderstood: the difference between a vSwitch and a port group, the three VLAN tagging modes, or uplink teaming. This guide explains how ESXi vSwitches, port groups, VLAN IDs and physical uplinks fit together, with the values you actually enter when creating a port group.

vSwitch, Port Group, Uplink - the Model

A vSwitch is a software Layer-2 switch: VMs plug into its virtual ports, and one or more physical NICs (uplinks) connect it to the outside. Unlike a physical switch it does not learn MACs for unknown destinations - frames for MACs outside the host are simply sent to the uplink. The default vSwitch0 is created at install.

A port group is a named slice of a vSwitch with its own policy (security, shaping, teaming) and its own VLAN ID. VMs attach to a port group, not to the vSwitch directly. Two kinds exist:

• VM port groups - for virtual machine NICs.
• VMkernel port groups - for VMkernel interfaces used by management, vMotion, storage (iSCSI/NFS), vSAN.

The mental model that prevents most mistakes: the vSwitch is the switch chassis, the port group is the VLAN on a group of switch ports, and the uplink is the trunk to the physical network. A port group carries policy; a vSwitch carries capacity. You cannot put two port groups with different VLAN IDs on the same untagged physical port and expect mixing to work at the vSwitch level - the tagging duty belongs to either the vSwitch (VST) or the physical switch (EST), never both.

Documented scale limits worth keeping in mind: a standard vSwitch supports up to 32 physical uplinks and 4096 VLANs per host, and its port count is a fixed allocation (8 to 1024, default 128) rather than elastic - so a busy host with many isolated networks can genuinely exhaust ports on a standard switch, which is one of the practical reasons large deployments move to a distributed switch.

Standard vSwitch versus Distributed Switch

If the host is standalone, a vSS with two uplinks is perfectly adequate. As soon as several hosts must present identical networking, the vDS removes an entire class of "it works on host 3 but not host 7" incidents.

VLAN IDs and the Three Tagging Modes

When creating a port group you enter a VLAN ID, whose meaning depends on the tagging mode:

• VST - Virtual Switch Tagging (VLAN 1-4094): the vSwitch tags/untags frames on behalf of the VM. The most common mode: assign VLAN 100 to a port group and all its VMs are on VLAN 100, with the uplink carrying tagged frames to the physical switch.
• EST - External Switch Tagging (VLAN 0): no tagging at the vSwitch; the physical switch port does the tagging (used e.g. with dedicated storage switch ports where the uplink is an untagged access port).
• VGT - Virtual Guest Tagging (VLAN 4095): trunk mode - the vSwitch passes all VLANs through untouched and the guest OS does its own tagging (used for nested virtualization or guest firewalls that need multiple VLANs).

The classic misconfiguration is entering 4095 when you meant a specific VLAN (guest sees no traffic because it never tags) or 0 when the physical port expects tagged frames.

A second trap is subtler: with EST (VLAN 0) every VM on that port group lands in whatever VLAN the physical switch port is assigned to, so sharing one access uplink between two VM port groups silently merges them into one broadcast domain. If you need two isolated segments on the same uplink, you need VST and a trunk - not two VLAN 0 port groups.

For nested workloads that need VGT, remember that the guest is now responsible for tagging, and the physical trunk must carry every VLAN the guest will use. The switch side of that work is exactly what the Open vSwitch VLAN article and the Linux 802.1Q tagging guide demonstrate on a real bridge and interface.

Uplinks and Teaming

Assign two or more physical NICs to a vSwitch for redundancy. On standard switches, teaming defaults to load balancing based on the virtual port ID with failover: if an uplink dies, its port groups fail over to a surviving uplink. For best practice:

• Connect the uplinks to separate physical switches (not the same one) so switch failure does not take the host down.
• Keep management, VM traffic and storage on separate VLANs - and ideally separate vSwitches/uplinks for storage.
• Use a distributed switch (vDS, Enterprise Plus) when consistent policies across many hosts matter; vDS is configured at vCenter level instead of per host.

The load-balancing policy is where most "my VM cannot saturate the link" complaints originate. The available options differ in what they hash on:

Two warnings that save hours. First, IP hash requires the physical switch to be configured as an EtherChannel (static LAG), not as LACP - mismatching the two produces a LAG that never comes up or one that flaps. LACP in ESXi is only available on a distributed switch, as a LAG bound to the uplink port group. Second, none of these policies give a single TCP flow more than one uplink's bandwidth; aggregation helps across many flows, which is the normal case for a hypervisor but rarely what a benchmarking exercise measures. Linux-side equivalents of the same hashing problem are covered in the systemd-networkd VLAN/bond/bridge configuration guide.

Uplink failure detection defaults to link status only. Beacon probing can detect a failed switch that still presents link, but it requires at least three uplinks and a compatible physical switch, and it does not work with IP hash - so it is usually left off.

VMkernel Adapters and Traffic Separation

A VMkernel adapter is the host's own IP identity on the network, and each one exists for exactly one purpose:

esxcli network ip interface list
esxcli network ip interface ipv4 get
esxcli network ip route ipv4 list

• Management - vCenter connectivity and the host client. Losing it means losing the host, so it deserves its own port group and never shares a VLAN with untrusted guest traffic.
• vMotion - bulk memory transfer. Wants bandwidth and a low-latency path; ideally a dedicated VLAN, and on 10 GbE or faster, its own uplink.
• Storage (iSCSI/NFS) - latency sensitive. iSCSI benefits from a dedicated vSwitch, jumbo frames (MTU 9000 on vSwitch, VMkernel adapter and the physical switch) and separate uplinks; use multipathing with independent paths rather than one fat LAG.
• vSAN - needs both bandwidth and consistency; mixing it with vMotion on the same uplink is a common cause of unstable resync.

Jumbo frames are all-or-nothing: set the MTU to 9000 on the vSwitch, the VMkernel adapter and every physical switch port along the path including the storage array. A path where one hop still runs 1500 causes silent iSCSI timeouts and path failovers that look like array problems rather than MTU problems.

Security and Traffic-Shaping Policy

Every port group inherits three security settings from the vSwitch, and the defaults differ between switch types in a way that surprises people:

• Promiscuous mode - Reject by default. Required for a guest running an IDS/sniffer, and required on the port group of any VM that must see all traffic in its VLAN.
• MAC address changes - Accept by default on a standard switch, Reject on a distributed switch. Controls whether a guest may change the MAC the vSwitch presents upward (a spoofing vector).
• Forged transmits - Accept by default on a standard switch, Reject on a distributed switch. Controls whether a guest may send frames with a source MAC other than its own - this is what breaks nested hypervisors unless you deliberately accept it.

That difference is why a VM that worked on a vSS starts dropping traffic after migration to a vDS: the migration silently flipped MAC address changes and forged transmits from Accept to Reject. Traffic shaping on a standard switch is egress-only (average bandwidth, peak bandwidth and burst size per port group), while a vDS can shape ingress as well.

Verifying Connectivity

Check from the host: esxcli network vswitch standard list (vSS), esxcli network ip interface list, and esxcli network vm list for VM port connections. Confirm the physical switch port carrying the uplink is configured for the matching VLAN (trunk with the right allowed list, or access for EST) - the switch side of that configuration is exactly what our Arista EOS VLAN guide, Open vSwitch VLAN article and Linux 802.1Q tagging guide demonstrate on real switch CLI.

esxcli network vswitch standard list
esxcli network vswitch standard portgroup list
esxcli network vswitch standard policy failover get -v vSwitch0
esxcli network vswitch standard policy security get -v vSwitch0
esxcli network nic list
esxcli network vm list
esxcli network diag ping -H 10.10.10.1 -I vmk0
esxcli network vswitch dvs vmware list          # distributed switch view

The portgroup list output is the fastest way to catch the three classic errors at once: a VM sitting on VLAN 0 when it should be tagged, two uplinks that accidentally point at the same physical switch, and a port group with no active uplink at all after a NIC swap.

Common Failures and Their Cause

• VM has no network, host does: the port group VLAN is wrong for the physical switch port (tagged vs untagged mismatch), or the port group is on a vSwitch whose uplinks are all down.
• VM loses network after migration: the destination host has no port group with that name/VLAN, or the vDS flipped security defaults to Reject while the guest relies on forged transmits.
• Only one uplink carries traffic: the load-balancing policy is originating virtual port ID (expected for a single VM) rather than a failure - test with two VMs before assuming a broken LAG.
• iSCSI path keeps failing over: MTU mismatch somewhere on the path, or all paths landing on the same uplink because of the hashing policy.
• vMotion fails or crawls: vMotion VMkernel on the management VLAN with no dedicated bandwidth, or the destination host is missing a matching vMotion port group.

Build the habit of reading the host side and the physical switch side together: nearly every ESXi networking incident is a single mismatched value between a port group and a switch port, and each side looks perfectly correct on its own.

原文链接：https://www.nakivo.com/blog/esxi-network-concepts/