Home lab networking for VMware: VLANs, vSwitches, and physical setup

You can build an ESXi host with a mini PC and 32 GB of RAM, plug it into an unmanaged switch, and start VMs. That works. But the moment you want to practice vMotion, segment traffic, run a nested vCenter, or reproduce something from work, the network layer is where the lab falls apart. This article covers the physical switch, VLAN design, vSwitch configuration, and NIC teaming decisions that make a home lab behave like something closer to a real environment.

The physical layer: managed switch and cabling

An unmanaged switch will carry traffic, but it cannot do 802.1Q VLAN tagging. That means no trunk ports, no traffic separation, and no way to practice the most common enterprise networking pattern in vSphere. You need a managed switch.

For a lab, the TP-Link TL-SG108E is an 8-port gigabit managed switch around $30 that supports 802.1Q VLANs, port mirroring, and IGMP snooping. It draws about 4 watts and has no fan. If you want something closer to enterprise gear, a used HP ProCurve 2530-8G runs $40 to $60 on eBay and gives you a real CLI. Either one works for a one- or two-host lab.

If your hosts have 10GbE ports, like a Minisforum MS-01 with SFP+, you will need a 10G switch or direct-attach copper (DAC) cables. A used Mikrotik CRS305 with four SFP+ ports runs about $130 and supports 802.1Q. For a two-node lab, skip the switch entirely and connect the hosts back to back with a 10G SFP+ DAC cable for about $12. That gives you a dedicated 10G link for vMotion and storage replication without buying a switch.

The switch-port mode is the part that matters. The port connecting to your ESXi host needs to be a trunk carrying all the VLANs you plan to use. On a Cisco switch, that looks like this:

interface GigabitEthernet0/1
 description ESXi-HOST-1-UPLINK
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30,40
 spanning-tree portfast trunk

Note: some Cisco platforms only support 802.1Q and do not recognize switchport trunk encapsulation dot1q. If the command is not available, skip it.

On a web-managed switch like the TL-SG108E, make the ESXi uplink a tagged member of each VLAN you want it to carry. The terminology differs by vendor: Cisco says trunk, TP-Link says tagged, the 802.1Q standard says the egress frames carry the VLAN tag in the header. They all mean the same thing. If you intentionally use an untagged/native management VLAN, set the port's PVID to that VLAN and leave that VLAN untagged on the ESXi uplink. In most VMware labs, tagging management on the ESXi port group is cleaner and avoids PVID confusion.

Pick one model for management and stick with it: either tag management as VLAN 10 on the ESXi port group and trunk/tag VLAN 10 on the switch, or leave management untagged/native on both sides. Do not set VLAN 10 on the ESXi port group while the switch sends management untagged, or you will lose access to the host on the next reboot.

On Cisco, use spanning-tree portfast trunk on the ESXi-facing trunk. On other switches, look for an STP edge-port or port-fast setting. Without it, the switch port goes through the listening and learning phases of spanning tree, which takes about 30 seconds, during which your ESXi host has no network connectivity. In production this is often paired with BPDU Guard; in a lab, the main point is avoiding that 30-second STP delay on host uplinks.

VLAN design for a home lab

You do not need ten VLANs. A functional lab uses four to five:

This is enough to practice every major vSphere networking scenario without making the switch config unwieldy. You can merge VLAN 20 into VLAN 10 for a minimal one-host setup, but separating vMotion onto its own subnet is what lets you observe the traffic and understand the failover behavior.

Standard vSwitch vs distributed switch

ESXi has two virtual switch types. The standard vSwitch (VSS) is configured per host and works with every license tier including free ESXi. The distributed switch (vDS) is configured once in vCenter and pushed to all member hosts.

Start with a standard vSwitch in a home lab because it works without vCenter and does not depend on Enterprise Plus licensing. For a one- or two-host lab, you will not feel its limitations.

The vDS becomes worth using at three or more hosts, or when you want to practice the exact configuration model used in production environments. A vDS gives you centralized port group management, private VLANs, network I/O control, and LACP support. The tradeoff is licensing: vSphere Distributed Switch requires Enterprise Plus-level entitlement or higher. In the current Broadcom packaging, that means vSphere Enterprise Plus at about $150/core/year, VVF at about $135 to $190/core/year, or VCF at about $350/core/year. vSphere Standard at $50/core/year does not include it. For context on how those tiers break down, the Broadcom licensing breakdown covers the full pricing structure.

If you are running a 60-day vSphere evaluation, you get all features including vDS. After the evaluation expires, an existing vDS may continue carrying traffic, but you should not count on being able to manage or change vDS-backed networking until the environment has a vDS-capable license. Do not build your only management path on an eval-only vDS.

Port groups: separating traffic types

A port group is a named entry point on a vSwitch that has its own VLAN, security, and teaming policy. Each traffic type gets its own port group. On a standard vSwitch with the four VLANs above, you would create:

Port Group VLAN ID Purpose
Mgmt-VMkernel 10 ESXi management, vCenter communication
vMotion-VMkernel 20 vMotion traffic
VM-Network 30 Virtual machine networking
iSCSI-VMkernel 40 iSCSI storage traffic (if applicable)

The ESXi management VMkernel adapter (vmk0) sits on Mgmt-VMkernel. You add a second VMkernel adapter (vmk1) on vMotion-VMkernel and tag it for vMotion. The iSCSI adapter goes on its own VMkernel if you are using IP-based shared storage. VM traffic goes through the VM-Network port group, which VM NICs attach to.

To create a port group from the ESXi shell:

esxcli network vswitch standard portgroup add \
  --portgroup-name="vMotion-VMkernel" --vswitch-name=vSwitch0

esxcli network vswitch standard portgroup set \
  --portgroup-name="vMotion-VMkernel" --vlan-id=20

To create the VMkernel adapter for vMotion:

esxcli network ip interface add \
  --interface-name=vmk1 --portgroup-name="vMotion-VMkernel"

esxcli network ip interface ipv4 set \
  --interface-name=vmk1 --type=static \
  --ip=192.168.20.10 --netmask=255.255.255.0

esxcli network ip interface tag add \
  --interface-name=vmk1 --tagname=VMotion

The last command tags vmk1 as a vMotion-capable adapter. Without it, vMotion will not use that interface. Do not add a default gateway to every VMkernel adapter. For a simple lab, keep vMotion and iSCSI on non-routed subnets. If you need routed vMotion, use the vMotion TCP/IP stack intentionally rather than dumping a gateway on vmk1.

Leave MTU at 1500 unless you are deliberately testing jumbo frames. If you set 9000 for iSCSI or vMotion, set it consistently on the physical switch, vSwitch, port group or VMkernel path, and storage endpoint, then verify with vmkping -d -s 8972 <target-ip>.

VLAN tagging modes

VMware supports three VLAN tagging models: EST, VST, and VGT. Most labs use one of them and never think about it, but knowing the difference matters when something is not tagging correctly.

Virtual Switch Tagging (VST) is the default approach. The physical switch port is a trunk. You assign a VLAN ID to the port group, and the vSwitch strips the 802.1Q tag before handing the frame to the VM. The VM sees untagged traffic. This is how 95 percent of vSphere environments operate.

External Switch Tagging (EST) means the physical switch port is an access port assigned to one VLAN. No VLAN ID is set on the port group (or it is set to 0). The VM and the vSwitch never see a tag. This is what happens if you plug an ESXi host into an unmanaged switch or an access port. It works, but you cannot carry multiple VLANs over a single uplink.

Virtual Guest Tagging (VGT) passes the 802.1Q tag through to the guest OS, which must handle VLAN tagging internally. The port group VLAN ID is set to 4095 (trunk all). This is used for nested labs where the guest is itself an ESXi host that needs to see tagged traffic. VLAN IDs 1 through 4094 identify tagged VLANs. VLAN ID 0 means the port group sends and receives untagged traffic. VLAN ID 4095 is the special trunk or all-VLANs setting used for VGT.

For the nested VCF lab setup, you will encounter VGT because the nested ESXi host needs to receive tagged frames to distribute across its own virtual port groups.

NIC teaming and failover with limited uplinks

Most mini PCs and budget lab hosts have one or two physical NICs. This is the constraint that shapes your teaming configuration.

With a single NIC, all traffic shares one uplink. You separate traffic logically using VLANs and port groups, but physically everything traverses the same cable. This is fine for learning. vMotion will compete with management traffic during migrations, but on a gigabit link in a lab that is not a practical problem.

With two NICs, you have options. The common configuration for a two-NIC host is to put both adapters on the same vSwitch and set the teaming policy to active/standby. Management traffic uses vmnic0 as active with vmnic1 as standby. vMotion uses vmnic1 as active with vmnic0 as standby. This way each traffic type has a failover path without needing active/active teaming, which on a standard vSwitch does not aggregate bandwidth for a single flow and does not require switch-side configuration under the default originating-port-ID policy.

To configure failover order from the shell:

esxcli network vswitch standard portgroup policy failover set \
  --portgroup-name="Mgmt-VMkernel" \
  --active-uplinks=vmnic0 --standby-uplinks=vmnic1

esxcli network vswitch standard portgroup policy failover set \
  --portgroup-name="vMotion-VMkernel" \
  --active-uplinks=vmnic1 --standby-uplinks=vmnic0

With PowerCLI, you can do the same thing across multiple hosts:

$vmhost = Get-VMHost "esxi-01.lab.local"

# On a fresh host, vSwitch0 usually already exists. Use Get-VirtualSwitch
# unless you intentionally removed the default networking.
$vsw = Get-VirtualSwitch -VMHost $vmhost -Name vSwitch0

# Management port group, vmnic0 active
$pgMgmt = New-VirtualPortGroup -VirtualSwitch $vsw -Name "Mgmt-VMkernel" -VLanId 10
Get-VirtualPortGroup -Name "Mgmt-VMkernel" -VMHost $vmhost |
  Get-NicTeamingPolicy | Set-NicTeamingPolicy -MakeActive vmnic0 -MakeStandby vmnic1

# vMotion port group, vmnic1 active
$pgVmotion = New-VirtualPortGroup -VirtualSwitch $vsw -Name "vMotion-VMkernel" -VLanId 20
$vmk = New-VMHostNetworkAdapter -VMHost $vmhost `
  -PortGroup "vMotion-VMkernel" `
  -VMotionEnabled $true `
  -IP "192.168.20.10" `
  -SubnetMask "255.255.255.0"

The default load balancing policy on a standard vSwitch is "route based on originating virtual port ID." This distributes VMs across uplinks by assigning each VM to a physical NIC based on its virtual port number. It does not aggregate bandwidth for a single VM, and it does not require switch-side configuration. "Route based on IP hash" can spread multiple flows across uplinks, but a single flow still normally lands on one physical link. On a standard vSwitch, IP hash requires a static EtherChannel or static port channel on the physical switch, not LACP. LACP is only available with a vSphere Distributed Switch, and the TL-SG108E does not support LACP on all firmware versions.

Security policies: promiscuous mode and nested labs

Every port group has three security policy settings. In a standard configuration, all three are set to Reject:

For a normal lab with VMs running web servers and databases, leave these at Reject. That is the secure default and the behavior you want to understand.

For a nested lab, where your VMs are themselves ESXi hosts running their own virtual machines, you need all three set to Accept on the port group hosting the nested ESXi. The nested host generates traffic with MAC addresses it assigned to its own VMs, and the outer vSwitch will drop those frames unless forged transmits and MAC address changes are accepted. Promiscuous mode must be accepted so the nested host can see traffic for its virtual machines.

esxcli network vswitch standard portgroup policy security set \
  --portgroup-name="Nested-ESXi" \
  --promiscuous-mode=yes \
  --mac-changes=yes \
  --forged-transmits=yes

This is the same configuration change described in the home lab hardware guide, which covers the physical host side. The networking article covers the port group side.

Verifying your configuration

Once everything is configured, verify the host can reach its gateways and that traffic is hitting the right VLANs.

# List all vSwitches, port groups, and uplinks
esxcfg-vswitch -l

# Show VMkernel adapters and their services
esxcli network ip interface list

# Test management network connectivity
vmkping -I vmk0 192.168.10.1

# Test vMotion network connectivity
vmkping -I vmk1 192.168.20.20

The esxcfg-vswitch -l output shows you the mapping between physical NICs, vSwitches, port groups, and VLAN IDs in one table. If a VM cannot reach the network, this is the first thing to check. The second is whether the physical switch port is actually carrying the VLAN ID assigned to that port group. A common cause of ESXi hosts disconnecting from vCenter is a misconfigured management network or a switch port that lost its trunk configuration after a reboot.

For a two-host lab where you want to verify vMotion is using the right network, run vmkping -I vmk1 <target-vMotion-IP> from each host. If that fails, vMotion will fail at around 10 percent with a network connectivity error. The VMkernel adapter must be tagged for vMotion and on the correct port group with the correct VLAN for the migration traffic to flow.

Stay ahead of the VMware changes

We're publishing detailed licensing breakdowns, comparison guides, migration walkthroughs, and cost calculators. Get them in your inbox.