Skip to content
Log in Sign up My account

2.1 Device Virtualization

Blueprint 2.1: Describe device virtualization technologies

  • 2.1.a Hypervisor type 1 and 2
  • 2.1.b Virtual machine
  • 2.1.c Virtual switching

This is a describe objective. You will not configure a hypervisor on the exam, but you must know what each layer does, which products fit which hypervisor type, how a VM reaches the physical network, and what the physical switch port facing a virtualization host should look like. That last point is where network engineers meet virtualization every day, and the exam likes it.

Why virtualize

A physical server used to run one operating system and one application. Most of its CPU and memory sat idle. Virtualization inserts a software layer, the hypervisor, that carves one physical server into several isolated virtual machines (VMs), each with its own operating system.

Benefit What it means in practice
Consolidation Fewer physical servers, less power, cooling and rack space
Isolation A crash or compromise in one VM does not affect the others
Fast provisioning A new server is a template clone, not a purchase order
Mobility A running VM can move between hosts (VMware vMotion, Hyper-V Live Migration) for maintenance or load balancing
Snapshots Save the full VM state before a change and roll back if it fails
Hardware independence The guest sees standard virtual hardware, so it runs on any host with the same hypervisor

The same idea applied to network functions is Network Functions Virtualization (NFV): routers, firewalls and WAN optimizers run as VMs instead of dedicated appliances. Cisco examples are the Catalyst 8000v router, the Secure Firewall Threat Defense Virtual and the ASAv. Cisco's Enterprise NFV Infrastructure Software (NFVIS) is a Linux-based hosting platform that runs those virtual network functions (VNFs) on a branch x86 box.

2.1.a Hypervisor type 1 and type 2

graph TB
  subgraph T1 ["Type 1, bare metal"]
    direction TB
    A1["VM: Windows"] --- H1["Hypervisor<br/>ESXi, Hyper-V, KVM"]
    A2["VM: Linux"] --- H1
    A3["VM: C8000v"] --- H1
    H1 --- HW1["Server hardware<br/>CPU, RAM, NICs, disk"]
  end
  subgraph T2 ["Type 2, hosted"]
    direction TB
    B1["VM: Linux"] --- H2["Hypervisor application<br/>VirtualBox, Workstation"]
    B2["VM: CML"] --- H2
    H2 --- OS["Host OS<br/>Windows, macOS, Linux"]
    OS --- HW2["Laptop hardware"]
  end
Type 1 (bare metal, native) Type 2 (hosted)
Runs on Directly on the hardware As an application inside a general-purpose OS
Performance High, little overhead Lower, every VM request also passes through the host OS
Typical use Data centre, production servers, branch NFV Labs, testing, desktop use
Management Central (vCenter, SCVMM, OpenStack) Local GUI on the PC
Failure domain Hypervisor only Hypervisor plus the host OS (a Windows update reboot takes every VM down)
Examples VMware ESXi, Microsoft Hyper-V, KVM, Xen, Cisco NFVIS (KVM based) Oracle VirtualBox, VMware Workstation, VMware Fusion, Parallels Desktop

A few product details trip people up:

  • Hyper-V is type 1 even when you enable it on Windows. Once the role is enabled, the hypervisor loads first and the Windows instance you log in to becomes a privileged partition running on top of it.
  • KVM is a Linux kernel module. It turns the Linux kernel itself into the hypervisor, so it is classed as type 1 even though a full Linux OS is present. Cisco NFVIS and CML both use KVM underneath.
  • VMware Workstation and VirtualBox are type 2. They are what most candidates use to run CML or EVE-NG on a laptop, which is why nested virtualization (a hypervisor inside a VM) must be enabled for those labs.

Exam trap

The exam defines the types by where the hypervisor runs, not by the vendor or the size of the deployment. "Runs on top of a host operating system" means type 2. "Installed directly on the server hardware" means type 1. Do not pick type 2 for Hyper-V just because it is enabled from inside Windows.

2.1.b The virtual machine

A VM is a set of files plus a running process that the hypervisor schedules. The guest OS believes it owns real hardware.

Virtual component Backed by
vCPU Time slices of physical CPU cores, scheduled by the hypervisor
vRAM A share of physical memory (can be overcommitted)
Virtual disk A file on a datastore, for example VMDK on VMware, VHDX on Hyper-V, QCOW2 on KVM
vNIC A virtual network adapter with its own MAC address, connected to a virtual switch port
Configuration file Describes the virtual hardware, for example the VMX file on VMware

Because a VM is files, it can be copied, cloned from a template, exported as an OVA/OVF package and moved between hosts. Network appliances ship this way: the Catalyst 8000v is distributed as an OVA for ESXi and a QCOW2 image for KVM.

VMs vs containers

The exam lists VMs, but you should be able to contrast them with containers because the comparison is a common distractor.

graph TB
  subgraph VMS ["Virtual machines"]
    direction TB
    V1["App"] --- G1["Guest OS"]
    V2["App"] --- G2["Guest OS"]
    G1 --- HV["Hypervisor"]
    G2 --- HV
    HV --- HWA["Hardware"]
  end
  subgraph CTR ["Containers"]
    direction TB
    C1["App + libs"] --- CE["Container engine"]
    C2["App + libs"] --- CE
    CE --- HOS["Host OS kernel"]
    HOS --- HWB["Hardware"]
  end
Virtual machine Container
Isolation unit Full guest OS with its own kernel Process with its own namespaces, sharing the host kernel
Size Gigabytes Megabytes
Boot time Tens of seconds to minutes Seconds or less
Different OS from host Yes (Windows VM on a Linux KVM host) No, a container uses the host kernel
Cisco example Catalyst 8000v on ESXi Guest Shell and application hosting on Catalyst 9000 (IOx)

Exam trap

Containers do not have their own kernel. If a question asks which technology lets you run a Windows server and a Linux server side by side on one host, the answer is a hypervisor with VMs, not containers.

2.1.c Virtual switching

Every vNIC plugs into a port on a virtual switch (vSwitch) that lives inside the hypervisor. The vSwitch forwards frames between VMs on the same host in software and sends everything else out through the host's physical NICs, which are the vSwitch uplinks.

graph TB
  subgraph HOST ["ESXi host"]
    VM1["VM web<br/>VLAN 10"] --- PG10["Port group WEB<br/>VLAN 10"]
    VM2["VM app<br/>VLAN 10"] --- PG10
    VM3["VM db<br/>VLAN 20"] --- PG20["Port group DB<br/>VLAN 20"]
    PG10 --- VS["vSwitch0"]
    PG20 --- VS
    VS --- U1["vmnic0"]
    VS --- U2["vmnic1"]
  end
  U1 -- "802.1Q trunk 10,20" --- SW1["ACC1"]
  U2 -- "802.1Q trunk 10,20" --- SW2["ACC2"]

Key behaviours:

  • Local switching. Two VMs in the same port group and VLAN on the same host talk through the vSwitch only. The frames never reach the physical switch, so a SPAN session on the access switch will not see them.
  • Port groups. A port group is a set of vSwitch ports that share a policy, most importantly a VLAN ID. It is roughly the virtual equivalent of a set of access ports in one VLAN.
  • MAC learning. The hypervisor already knows every vNIC MAC address because it assigned them, so a standard vSwitch does not need to learn MAC addresses by flooding the way a physical switch does.
  • No STP. A VMware standard vSwitch does not run spanning tree and does not send BPDUs. It prevents loops by never forwarding a frame received on one uplink back out another uplink.

VLAN tagging modes

Mode Who tags Port group VLAN setting (VMware) Physical switch port
Virtual Switch Tagging (VST) The vSwitch adds and removes the tag 1 to 4094 802.1Q trunk
External Switch Tagging (EST) The physical switch, nothing is tagged on the host link 0 (none) Access port
Virtual Guest Tagging (VGT) The guest OS inside the VM tags its own frames 4095 on a standard vSwitch (trunk all) 802.1Q trunk

VST is the normal design: one trunk per uplink, many VLANs, and the VM never sees a tag.

Types of virtual switch

Virtual switch Scope Notes
VMware vSphere Standard Switch One host Configured on each host separately
VMware vSphere Distributed Switch (VDS) Many hosts, managed from vCenter One configuration for the cluster, supports LACP, NetFlow and port mirroring
Hyper-V Virtual Switch One host External, internal and private switch types
Linux bridge One Linux host Kernel bridging, used by KVM and by CML internally
Open vSwitch (OVS) One host, often orchestrated by an SDN controller Supports OpenFlow and overlays such as VXLAN

A distributed switch matters for mobility. When a VM moves with vMotion, its port and policy (VLAN, security, counters) move with it, because the switch spans all hosts.

NIC teaming and the physical switch

A host normally has two or more uplinks to two access switches for redundancy. The teaming policy on the vSwitch decides how VMs use them, and it must match the physical switch configuration.

vSwitch load balancing Physical switch must be
Route based on originating virtual port (VMware default) Independent trunks, no EtherChannel
Route based on source MAC hash Independent trunks, no EtherChannel
Route based on IP hash (standard vSwitch) Static EtherChannel (channel-group N mode on), all uplinks to one switch or one logical switch such as StackWise Virtual
LACP (Distributed Switch only) LACP EtherChannel (mode active or passive)

With the default policy each VM is pinned to one uplink, so its MAC address only ever appears on one switch port. That is why no EtherChannel is needed and why configuring one breaks things: the switch hashes return traffic across both links, and the vSwitch drops frames that arrive on an uplink it did not expect.

Exam trap

A VMware standard vSwitch cannot negotiate LACP. If a scenario puts LACP (mode active) on the switch side and the host uses a standard vSwitch with IP hash, the bundle will not form. Use mode on for a standard vSwitch, or move to a Distributed Switch for LACP.

The access switch port facing a host

Because the vSwitch does not run STP, the switch port facing it should behave like an edge port, but it is also a trunk. On IOS XE:

interface GigabitEthernet1/0/10
 description ESXI-01 vmnic0
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30
 switchport nonegotiate
 spanning-tree portfast edge trunk   ! older syntax: spanning-tree portfast trunk
 spanning-tree bpduguard enable

PortFast on a trunk lets the port forward immediately after a host reboot or uplink flap instead of waiting through listening and learning. BPDU Guard still protects the network if someone bridges two vNICs inside a VM and a real BPDU appears.

Verify:

ACC1# show interfaces GigabitEthernet1/0/10 trunk
ACC1# show spanning-tree interface GigabitEthernet1/0/10 portfast
ACC1# show mac address-table interface GigabitEthernet1/0/10

The MAC table on the host-facing port shows one entry per VM vNIC (plus the host's own VMkernel interfaces), each in its VLAN. Seeing many MACs on one port is normal here, which is also why port security with a low maximum is a bad idea on a hypervisor uplink.

Hardware assists you may see named

Term What it does
SR-IOV Splits one physical NIC into many virtual functions that are handed directly to VMs, bypassing the vSwitch for near line-rate performance
PCI passthrough Gives a whole physical NIC to one VM
DPDK A user-space packet processing library that speeds up software forwarding, used by virtual routers and OVS

The trade-off is always the same: the closer the VM gets to the hardware, the faster it is and the less the hypervisor can do for it (vMotion and vSwitch features are limited with SR-IOV and passthrough).

Lab: a virtual switch you can see

Topology: ACC1 (IOSvL2) trunked to an Ubuntu node named HV1 that plays the role of a KVM host. Two Linux network namespaces on HV1 play the role of VMs. You build the Linux bridge that a hypervisor would build for you.

graph LR
  subgraph HV1 ["HV1 Ubuntu, acts as KVM host"]
    VMA["ns vmA<br/>10.10.10.21/24"] --- BR["br10<br/>Linux bridge"]
    VMB["ns vmB<br/>10.10.10.22/24"] --- BR
    BR --- E10["ens3.10"]
  end
  E10 -- "ens3, 802.1Q trunk VLAN 10" --- ACC1["ACC1 Gi0/2"]
  ACC1 --- SVI["Vlan10 10.10.10.1/24"]
  1. On ACC1, create VLAN 10, an SVI 10.10.10.1/24, and make Gi0/2 a trunk with PortFast edge trunk and BPDU Guard.

    vlan 10
    interface Vlan10
     ip address 10.10.10.1 255.255.255.0
     no shutdown
    interface GigabitEthernet0/2
     switchport trunk encapsulation dot1q
     switchport mode trunk
     switchport trunk allowed vlan 10
     spanning-tree portfast edge trunk
     spanning-tree bpduguard enable
    
  2. On HV1, create the VLAN subinterface, the bridge and two "VMs". Adjust ens3 to the interface name on your node.

    sudo ip link add link ens3 name ens3.10 type vlan id 10
    sudo ip link add br10 type bridge
    sudo ip link set ens3.10 master br10
    for vm in vmA vmB; do
      sudo ip netns add $vm
      sudo ip link add veth-$vm type veth peer name eth0 netns $vm
      sudo ip link set veth-$vm master br10
      sudo ip link set veth-$vm up
    done
    sudo ip netns exec vmA ip addr add 10.10.10.21/24 dev eth0
    sudo ip netns exec vmB ip addr add 10.10.10.22/24 dev eth0
    sudo ip netns exec vmA ip link set eth0 up
    sudo ip netns exec vmB ip link set eth0 up
    sudo ip link set ens3 up; sudo ip link set ens3.10 up; sudo ip link set br10 up
    
  3. Ping between the two VMs, then from each VM to the SVI.

    sudo ip netns exec vmA ping -c 3 10.10.10.22
    sudo ip netns exec vmA ping -c 3 10.10.10.1
    
  4. Check where frames were switched.

    bridge fdb show br br10 | grep -v permanent
    
    ACC1# show mac address-table vlan 10
    

Expected result: both pings succeed. The bridge forwarding table on HV1 lists both VM MAC addresses on their veth ports and the SVI MAC on ens3.10. ACC1 learns the VM MAC addresses on Gi0/2 only from the VM-to-SVI ping. Clear the MAC table, ping only vmA to vmB, and confirm ACC1 learns nothing: that traffic was switched entirely inside the host.

  1. Break it: remove VLAN 10 from the trunk allowed list on ACC1. VM-to-VM pings still work, VM-to-gateway pings fail. This is the classic "VMs on the same host can talk but cannot reach the gateway" ticket.

Quick check

Two VMs on different hosts sit in the same port group with VLAN 30. The VMs on host A can ping each other, but cannot reach the VM on host B. What should you check first?

The physical path between the hosts. Traffic between hosts leaves on an uplink, so VLAN 30 must be allowed on the trunks from both hosts to the access switches and across any inter-switch links. Local traffic works because it never leaves host A.

Why is EtherChannel not configured on switch ports facing an ESXi host that uses the default teaming policy?

The default policy (route based on originating virtual port) pins each VM to one uplink. The host does not treat the uplinks as a bundle, so a switch-side EtherChannel would hash return traffic onto links the vSwitch does not expect for that VM.

Which hypervisor type is VMware Workstation running on a Windows laptop, and why?

Type 2. It is an application installed on a general-purpose host operating system, and every VM depends on that host OS.

References

  • VMware vSphere Networking documentation: search "vSphere Networking" on docs.vmware.com or techdocs.broadcom.com
  • Cisco Enterprise NFV Infrastructure Software (NFVIS): search "NFVIS configuration guide" on cisco.com
  • Cisco Catalyst 8000V Edge Software installation and configuration guides: search "Catalyst 8000V installation guide" on cisco.com
  • Cisco Live On-Demand Library: search "NFV" and "virtualization"
  • Diagram library: E12 Type 1 vs type 2 hypervisors