You finish building a VM. The operating system installs cleanly, it boots, the login screen looks perfect. Then you try to ping the gateway and nothing comes back. No updates, no remote login, no traffic at all. The VM is completely healthy. The cable it is plugged into is the problem, except there is no cable. There is a virtual switch, a port group and a VLAN setting, and one of them is wrong. This is the most common first-week mystery in VMware, and once you can picture the path a packet takes, you will solve it in two minutes instead of two hours.
Think of an office. Computers plug into wall jacks, the jacks run back to a switch in a cupboard, and that switch has one fat cable going up to the building network. VMware rebuilds that whole picture in software. The switch in the cupboard becomes a virtual switch living inside ESXi. The wall jacks become a port group. The fat cable to the building becomes an uplink, which is a real physical network card on the host. Nothing here is exotic. It is the office network you already understand, drawn in software instead of copper.
What a virtual switch actually is
A virtual switch (vSwitch) is software inside ESXi that moves network traffic between VMs and out to the physical network, exactly like a hardware switch moves frames between ports. A VM has a virtual NIC (from Part 5), and that NIC connects to the vSwitch. If two VMs on the same host sit on the same vSwitch and the same VLAN, their traffic never even touches a physical cable; the vSwitch passes it across internally, which is why VM-to-VM traffic on one host is so fast.
To reach anything outside the host, the vSwitch needs uplinks. An uplink is a physical NIC on the server, named like vmnic0 or vmnic1, wired into a real switch in the rack. Give a vSwitch two uplinks instead of one and you get redundancy: if a cable or a switch port dies, traffic keeps flowing on the other. One detail that surprises beginners is that uplinks are not where you set an IP address for your VMs. The vSwitch is a layer-2 device; it just forwards frames. The IP addresses live inside the guests and on VMkernel ports, not on the switch itself.
Port groups: the labelled jacks
You never plug a VM straight into a vSwitch. You plug it into a port group, which is a named bundle of ports that all share the same settings. The most important setting is the VLAN ID, but a port group also carries security and NIC-teaming policy. When you build a VM and the wizard asks which network to connect to, that dropdown is a list of port groups. A fresh ESXi host ships with one called VM Network, which is why so many lab VMs end up there by default.
Two kinds of port group
There are two flavours and it helps to keep them apart. A VM port group is for your virtual machines. A VMkernel port is for the host own traffic: management (how vCenter talks to the host), vMotion, vSAN and so on. The VMkernel port is the one place on the switch that does hold an IP address, because the host itself needs to be reachable. As a fresher you mostly create and pick VM port groups, but knowing the VMkernel port exists explains why the host has IPs while your VM networks do not.
Standard switch or distributed switch
There are two types of vSwitch and the difference matters more than tutorials let on. A vSphere Standard Switch (vSS) belongs to a single host. If you have eight hosts and you want the same Web port group on all of them, you create it eight times, by hand, and you had better type the name identically every time. A vSphere Distributed Switch (vDS) is configured once at the vCenter level and pushed out to every host in the cluster, so the port groups are guaranteed to match. The vDS needs a specific vSphere licence edition; the standard switch is always available.
Here is the real-world specific that bites people. A standard switch does not synchronise across hosts, and port group names are matched as exact, case-sensitive text. If Host A has a port group called Prod-VLAN10 and Host B has Prod_VLAN10 (an underscore instead of a hyphen, or a stray capital letter), the two are different networks as far as vSphere is concerned. The VM runs fine, until the day it vMotions or restarts on the other host, and then it lands on a port group that does not exist there and loses its network. Nothing looks broken in the VM. The fault is a typo made weeks earlier on a different host. Distributed switches exist largely to kill this exact class of bug.
| Standard switch (vSS) | Distributed switch (vDS) | |
|---|---|---|
| Managed where | On each host, separately | Once, in vCenter |
| Consistency across hosts | Your responsibility, by hand | Guaranteed automatically |
| Licence | Always included | Needs a higher edition |
| Best fit | One or two hosts, labs | Real multi-host clusters |
VLANs: one wire, many separate networks
A VLAN lets one physical network carry several separate networks that cannot see each other, the way one office corridor can hold many private conversations at once. Each VLAN has a number. Traffic gets a small tag stamped on it saying which VLAN it belongs to, and switches use that tag to keep VLAN 10 apart from VLAN 20 even though they ride the same cable. In VMware the usual way to do this is called VST, Virtual Switch Tagging, which means the vSwitch does the tagging for you based on the port group VLAN ID.
What the VLAN ID number means
The single VLAN ID field on a port group has three meanings depending on the number you type, and this is worth memorising because it comes up constantly. 0 (or blank) means no tagging: the vSwitch adds nothing and assumes the physical switch handles VLANs, which is called External Switch Tagging. A number from 1 to 4094 is VST: the vSwitch tags all traffic from that port group with that VLAN, and your physical switch port must be a trunk that allows it. 4095 is the special one: it passes every VLAN tag straight through to the guest, so the VM itself decides, which is Virtual Guest Tagging and is rare in normal use.
Worked example: three networks, two cables
A host has two 10 GbE physical NICs, vmnic0 and vmnic1. You need three separate networks: management on VLAN 10, vMotion on VLAN 20, and your VMs on VLAN 30. A beginner instinct is to ask for six cables, two per network. You do not need them.
Put both uplinks on one vSwitch and make the physical switch ports trunks that allow VLANs 10, 20 and 30. Then create three port groups (or VMkernel ports), one per VLAN ID. All three networks now ride the same two cables, the VLAN tags keep them apart, and because there are two uplinks you still have full redundancy if a cable fails. Two cables, three isolated networks, no loss of resilience. That is the everyday payoff of VLANs.
Real interview question
What is a port group, and what does the VLAN ID on it do?
Strong answer: a port group is a named set of virtual switch ports that share the same policy, and VMs connect to a port group rather than to the switch directly. The VLAN ID on the port group decides VLAN tagging: 0 or blank means no tagging (the physical switch handles it), 1 to 4094 means the vSwitch tags that traffic and the uplink must trunk that VLAN, and 4095 passes all tags through to the guest. Adding that VST needs trunked physical ports, and that standard switch port groups must be named identically across hosts, turns a textbook answer into one that sounds like you have actually done it.
Try it yourself
You can do this in a free home lab with VMware Workstation, a nested ESXi host, or VMware’s browser-based Hands-on Labs (HOL), which need nothing installed. On an ESXi host, open the networking section and create a new standard switch port group called Test-Web, leaving the VLAN ID at 0 for now.
Attach a test VM to Test-Web and confirm it can reach the network. Now change the port group VLAN ID to a number your physical or nested switch does not allow, and watch the VM go silent even though its link still shows connected. Change it back to 0 and it returns. How to check you got it right: you have just reproduced, on purpose, the single most common network ticket you will ever receive, and you know exactly which setting caused it.
FAQ
What is the difference between a virtual switch and a physical switch?
Functionally very little: both forward network frames between ports. The virtual switch runs in software inside ESXi and connects VMs to each other and, through uplinks, to the physical switch in the rack. The physical switch is the hardware box those uplinks plug into. They work together, one inside the host and one outside it.
What exactly is a port group?
It is a named group of virtual switch ports that all share the same configuration, especially the VLAN ID and security and teaming policy. VMs connect to a port group, not to the switch directly, so the port group is where you apply network settings to many VMs at once.
Standard or distributed switch, which should I use?
For a single host or a lab, the standard switch is fine and always available. For a real cluster of several hosts, the distributed switch is worth it because it keeps every host configured identically and removes the typo-driven outages that standard switches invite. The catch is that the distributed switch needs a higher vSphere licence edition.
Why did my VM lose its network after a vMotion?
The most common cause with standard switches is that the destination host has a port group with a slightly different name or VLAN ID, so the migrated VM lands on a network that is not really the same. Check that the port group name matches exactly, character for character, on both hosts, and that the VLAN ID is identical.
Do I set an IP address on the virtual switch?
No. The vSwitch just forwards frames and holds no IP for your VMs. IP addresses live inside the guest operating systems, and the host own IPs live on VMkernel ports. If you are hunting for where to type an IP for a VM, it is inside the VM, not on the switch.
Where to go next
You can now trace a packet from a VM all the way to the physical switch and name every stop on the way. Next we look at templates, clones and snapshots, the tools that stop you building every VM by hand. When you are ready to go much further than the basics, the advanced NSX material on this site covers software-defined networking, microsegmentation and the network virtualization that sits above everything here; treat it as stage-two reading once these foundations feel solid.
References
- Sample configuration of Virtual Switch VLAN Tagging (VST), Broadcom
- VLAN configuration on virtual switches, physical switches and VMs, Broadcom
- Port group mismatch across ESXi hosts results in network unavailability, Broadcom
About The Author
DrJha