Virtual networking: virtual switches, port groups and VLANs
In short: Each VM has a virtual network card connected to a virtual switch inside the hypervisor. Port groups apply settings such as VLAN IDs, and physical uplinks carry the traffic to real switches, usually on 802.1Q trunks. Consistent, well-separated virtual networking is essential for performance, migration and security.
The building blocks
Inside a virtualisation host there is a complete small network. Each VM has one or more virtual NICs (vNICs). These plug into a virtual switch, which is software in the hypervisor that forwards frames between VMs and out to the physical network through uplinks (the host's real network cards).
A port group (VMware term; Hyper-V and Proxmox use VLAN settings on the switch or adapter) is a named set of ports with the same policy, most importantly the VLAN ID. You connect a VM to "Staff-VLAN20" rather than configuring the VLAN inside every guest.
VLANs and trunks
To carry many VLANs over a few cables, the host uplinks connect to physical switch ports configured as 802.1Q trunks. The virtual switch adds or removes VLAN tags as traffic enters and leaves. The VLANs you need must be allowed on both the physical trunk and the virtual switch; a mismatch is the most common reason a new VM "has no network". See VLANs and trunks for the switch side.
! Physical switch port facing a virtualisation host (Cisco IOS)
interface GigabitEthernet1/0/10
description ESX01-vmnic0
switchport mode trunk
switchport trunk allowed vlan 10,20,30,100
spanning-tree portfast trunk
On Proxmox, enabling "VLAN aware" on a Linux bridge allows each VM's interface to set a VLAN tag. On Hyper-V, you can set the VLAN on the VM's network adapter with Set-VMNetworkAdapterVlan -VMName web01 -Access -VlanId 20.
Design: separate traffic types
| Traffic | Purpose | Design tip |
|---|---|---|
| Management | Host and hypervisor administration | Own VLAN, reachable only from admin networks |
| VM traffic | Workloads talking to users and each other | One port group per VLAN or security zone |
| Live migration | Moving running VMs between hosts | Isolated, high bandwidth, often unencrypted by default |
| Storage | iSCSI or NFS datastores | Isolated VLAN, jumbo frames end to end |
Use at least two uplinks per virtual switch connected to different physical switches, with NIC teaming for failover and load sharing.
Network modes and security settings
Desktop hypervisors offer simple modes: bridged (the VM appears on your real LAN), NAT (VMs share the host's address) and host-only or internal (VMs talk only to the host or each other). Host-only is ideal for isolated security labs.
Virtual switches include security policies you should know:
- Promiscuous mode: lets a VM see all traffic on the port group. Keep it off except for monitoring appliances such as an IDS.
- MAC address changes and forged transmits: control whether a VM may change or spoof its MAC. Reject unless an application (some clusters, nested labs) needs it.
- Port mirroring: copies traffic to a monitoring VM for analysis.
Tip: keep port group names identical on every host in a cluster. If "VLAN20-Staff" exists on one host but is spelt differently on another, live migration fails or the VM loses connectivity after moving.
Practice
A new VM on VLAN 30 cannot reach its gateway, but VMs on VLAN 20 work. What should you check?
Why should live migration traffic be on its own network?
Which desktop hypervisor network mode suits a malware analysis lab?
Key takeaways
- VMs use vNICs connected to virtual switches with physical uplinks.
- Port groups apply VLAN IDs and policies to sets of VM ports.
- Host uplinks connect to 802.1Q trunks; allowed VLANs must match both sides.
- Separate management, VM, migration and storage traffic.
- Reject promiscuous mode, MAC changes and forged transmits unless required.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.