2.1Device virtualization (hypervisors, VMs, and virtual switching)

The virtualization domain is only 10% of ENCOR, but modern enterprise networks—SD-Access and SD-WAN controllers, branch virtual routers, lab environments—all ride on virtualization. What matters for a network engineer is not memorizing "what a hypervisor is," but being able to trace a VM's traffic with the same precision as physical traffic. Beyond the physical server NIC lies an invisible L2 world called the virtual switch, and a single mistake in VLAN tag handling silences the VM. This section organizes the selection criteria for type 1 vs. type 2, VM resource allocation, and virtual-switch connectivity and tagging, from the standpoint of design selection and fault isolation.

2.1.1The two hypervisor forms

• A type 1 hypervisor (bare metal) is installed directly on the physical hardware and controls that hardware itself (VMware ESXi, KVM, Microsoft Hyper-V, etc.). With no general-purpose OS in between, it has lower overhead, higher performance, and greater stability, and a smaller attack surface. It is used for production data centers and as the platform for running virtual routers/firewalls at a branch.
• A type 2 hypervisor (hosted) runs as an application on top of a host OS such as Windows or macOS (Oracle VirtualBox, VMware Workstation, etc.). Because it goes through the host OS scheduler and drivers, it has higher overhead and is not suited to production, but it lets you stand up a test environment easily on a local PC, so it is used for study labs and developer workstations.
• The decision axes are performance, isolation, and operations. The basic split: type 1 for virtual appliances forwarding production traffic (virtual routers, virtual firewalls, controller VMs); type 2 for certification study or feature validation. Note that this is not a matter of generations—"type 2 is newer" or "type 1 is older"—but of distance from the hardware.

2.1.2VMs and resource allocation

• A VM (virtual machine) is a unit in which an independent guest OS runs on a set of vCPU, memory, virtual disk, and vNIC (virtual NIC) resources assigned by the hypervisor. Because each VM carries its own OS kernel, isolation is strong, at the cost of higher memory/disk consumption. By contrast, a container is OS-level virtualization sharing the host kernel—lightweight but with weaker isolation than a VM. Both are used, according to fit, in network function virtualization.
• A VM carrying a data plane, such as a virtual router or virtual firewall, has different requirements from a general business VM. Packet processing consumes CPU continuously, so vCPU oversubscription or memory swapping surfaces as reduced throughput and jitter in latency. Honor the vendor-recommended vCPU/memory reservations, and consider NIC offload or dedicated assignment.
• VMs can be handled flexibly with snapshots and live migration, but from a network standpoint this presupposes that the destination can still reach the same VLAN/subnet. If the destination host's uplink does not permit that VLAN, the VM loses connectivity the moment it moves—a classic case where what looks like "server-side work" actually hinges on switch-side configuration.

2.1.3Virtual switching and external connectivity

• A virtual switch (vSwitch) is a software L2 switch inside the hypervisor that connects VMs to each other and to the outside. A VM's vNIC attaches to a port group (VMware) or a bridge (KVM/Open vSwitch), and a physical NIC serves as the uplink bridging to the external physical switch. Note that traffic between VMs in the same VLAN on the same host never traverses the physical switch, so physical-side SPAN or ACLs can neither see nor control it.
• In the standard design where VMs in multiple VLANs share one host, the physical switch uplink port is set to switchport mode trunk and the required VLANs are permitted with switchport trunk allowed vlan. On the virtual switch side, each port group is assigned a VLAN ID and the tag is stripped before the VM (VST, Virtual Switch Tagging), so the guest OS receives untagged frames—the usual arrangement.
• A virtual switch is not a full equivalent of a physical switch. It generally does not participate in STP (it neither forwards nor generates BPDUs), and many implementations know MAC addresses from VM configuration rather than learning them. So never assume STP will rescue you from a "virtual switch loop"; uplink redundancy must be secured through the teaming/NIC-bonding method (and matching physical-side configuration).

At a branch site, you deploy three new VMs on a type 1 hypervisor: two in VLAN 10 (the existing business segment) and one in VLAN 20 (a newly created monitoring segment). After the rollout, the two VMs in VLAN 10 reach each other and the gateway, but the monitoring VM in VLAN 20 reaches neither a physical server in the same VLAN nor its default gateway. Jumping to "the monitoring VM's OS is misconfigured" and reinstalling it is a poor isolation sequence. First, be clear about what the working VLAN 10 proves and what it does not. Two VMs in VLAN 10 talking to each other could simply be hairpinning inside the virtual switch on the same host, which proves nothing about the uplink. But since they also reach the gateway, you do know that the physical NIC link and the trunk uplink itself are alive. Next, the fact that only VLAN 20 fails is a per-VLAN isolation clue: suspect that VLAN 20 is being dropped somewhere along the tag path. There are two candidates: (1) the VLAN ID assigned to the virtual switch port group is wrong (e.g., 200 where 20 was intended, or unset so frames are treated as untagged), or (2) the physical switch uplink permits only VLAN 10 under switchport trunk allowed vlan, and the newly created VLAN 20 was never added. In practice (2) is overwhelmingly common—forgetting to update the uplink when a new VLAN is introduced is the classic cause. The fastest check is show interfaces trunk on the physical side to see whether 20 appears in the allowed and active VLAN lists; if it does not, add it with switchport trunk allowed vlan add 20 (typing allowed vlan 20 would wipe out the existing 10, so always using add is the professional habit). Also confirm with show vlan brief that the VLAN actually exists on the physical switch. The essence of this domain is not "a VM problem belongs to the server team," but suspecting both sides equally along the axis of whether the tag can cross the boundary between physical and virtual.

2.1.4Section summary

• Type 1 (bare metal) sits directly on hardware with low overhead—suited to production and virtual appliances; type 2 (hosted) is an app on a host OS—suited to validation and study
• A VM isolates strongly with its own guest OS, and for data-plane VMs vCPU oversubscription surfaces as degraded throughput/jitter; a container shares the kernel—lightweight but less isolated
• A virtual switch hosts VM vNICs and bridges to the physical world via an uplink; same-host, same-VLAN traffic never leaves the host and the vSwitch normally does not join STP. For VM connectivity failures, check both the port group VLAN ID and the uplink's allowed VLANs