A network engineer in 2026 spends a surprising amount of time on networks that have no physical cables. The server team's hypervisor has a virtual switch inside it that your VLANs terminate on. The cloud VPC is entirely virtual. The container platform has its own overlay. If you think the network stops at the physical switch port, you are missing half of where the packets actually go, and half of where the problems actually live.
This article covers hypervisors, virtual switching, and the virtualization concepts a network engineer needs, framed for people who know networking but not necessarily the compute side. It extends the Network Virtualization cluster guide.
The Hypervisor, From a Network Point of View
A hypervisor runs virtual machines on physical hardware. There are two types, and the distinction is worth knowing:
From the network's perspective, the important thing is not the VMs themselves but what sits between them and the physical NIC: a virtual switch. Every packet a VM sends hits that virtual switch first, and only some of them ever leave the physical server at all.
The Virtual Switch Is a Real Switch
Inside the hypervisor is a software switch (VMware vSwitch/vDS, the Linux bridge, Open vSwitch) that behaves like a physical access/distribution switch, with all the same concepts you already know:
That last row is the single most important thing for a network engineer to internalise. A large fraction of data centre traffic is east-west (server to server), and much of it between VMs on the same host never leaves the hypervisor. Your NetFlow, your SPAN, your ACLs on the physical switch, none of them see it. This is why virtual firewalls and hypervisor-level microsegmentation exist: to enforce policy on traffic the physical network never touches.
One important difference from a physical switch: a vSwitch typically does not run spanning tree and does not learn MACs the way a physical switch does. It knows exactly which MACs are behind each virtual port because it created those ports, so it does not need to learn or worry about loops in the same way. That is a feature (no STP complexity) and an occasional surprise (behaviour differs from a physical switch).
VM Mobility and Why Overlays Exist
The capability that reshaped data centre networking is live migration: moving a running VM from one physical host to another with no downtime (vMotion, live migration). For this to work, the VM must keep its IP and MAC after the move, which means the Layer 2 segment it lives on must exist on both the source and destination hosts.
In a traditional network, that means stretching VLANs across every host that might ever run the VM, which recreates all the large-flat-Layer-2 problems VXLAN was invented to solve. This is precisely why data centres moved to VXLAN overlays: the VM's segment (a VNI) can exist anywhere in the fabric without stretching physical VLANs, so the VM can migrate anywhere and keep its addressing. The overlay decouples the VM's network from the physical topology, exactly the decoupling this whole cluster is about.
Containers Are a Different Animal
VMs virtualize the hardware; containers virtualize the operating system. A container shares the host kernel and is far lighter, and its networking model is different again:
- Each container gets a virtual interface, usually connected to a bridge on the host (or an overlay).
- Container platforms (Kubernetes) run their own overlay network (Flannel, Calico, Cilium) that gives every container an IP and routes between them, often using VXLAN or similar encapsulation under the hood.
- Service discovery and load balancing happen at the platform layer, not the physical network. A "service" IP may not correspond to any single container.
For a network engineer, the practical reality is that container traffic is even further abstracted from the physical network than VM traffic. The physical network provides IP connectivity between hosts; everything above that (which container talks to which, and how) is the platform's overlay, which you may not directly control or even see. The virtualization fundamentals article covers the VM-vs-container distinction at the CCNA level; the takeaway here is that the network's job shrinks to "provide reliable IP transport between hosts" and the interesting L2/L3 decisions move into software.
What This Means for the Network Team
The practical consequences of all this virtualization for how you design and operate:
- Trunk to the hypervisor, do not access-port it. A physical port to an ESXi host carries many VLANs (many port groups). It is a trunk, and the VLAN allowed list must include everything the host runs.
- You cannot see east-west intra-host traffic from the physical network. If you need visibility or enforcement there, it has to happen in the hypervisor (virtual taps, distributed firewalls, hypervisor NetFlow).
- The MTU story matters more. Overlays (VXLAN in the hypervisor or container platform) add encapsulation overhead. If the physical underlay MTU is not raised, you get mysterious performance problems that look like application bugs.
- Coordination with the compute team is not optional. The network now extends into their hypervisor. A VLAN change, an MTU change, or a new port group is a joint operation. The old clean handoff at the switch port is gone.
FAQ
Why can't I see traffic between two VMs on the same host?
Because it never leaves the host. The virtual switch forwards it internally. To see or enforce policy on it, you need hypervisor-level tooling (a distributed virtual switch with monitoring, a virtual firewall), not the physical network.
Is a virtual switch a real switch?
Functionally yes for VLANs and forwarding, but it typically does not run spanning tree and knows its MAC-to-port mappings by construction rather than learning them. Treat it as an access/distribution layer implemented in software.
How should the physical port to a hypervisor be configured?
As a trunk (802.1Q) carrying all the VLANs the host's port groups use, usually with an allowed-VLAN list and often in an EtherChannel to the host's teamed NICs.
Do containers use VLANs?
Usually not directly. Container platforms run their own overlay (often VXLAN-based) and assign IPs from their own address space. The physical network provides host-to-host IP transport; the container networking lives above it.
Why does VM mobility need an overlay?
A migrating VM must keep its IP and MAC, so its Layer 2 segment must exist on the destination host. An overlay (VXLAN) lets that segment exist anywhere in the fabric without stretching physical VLANs everywhere.
Key Takeaways
- Every VM's traffic hits a virtual switch in the hypervisor first. It behaves like an access/distribution switch (port groups = VLANs, pNICs = trunk uplinks) but usually without spanning tree.
- East-west traffic between VMs on the same host never leaves the hypervisor, so the physical network cannot see or filter it. Enforcement there needs hypervisor-level tooling.
- VM live migration requires the L2 segment on both hosts, which is exactly why data centres adopted VXLAN overlays.
- Containers virtualize the OS, are lighter than VMs, and run their own platform overlay; the physical network shrinks to providing host-to-host IP transport.
- Practical rules: trunk to hypervisors, raise underlay MTU for overlays, accept the east-west visibility gap, and coordinate closely with the compute team, the network now extends into their kit.
Next: choosing the right segmentation layer, or the Network Virtualization cluster guide.
