2.1.a Hypervisor type 1 and 2

A hypervisor is the software layer that lets virtual machines share physical hardware.

For ENCOR, know the difference between Type 1 and Type 2 hypervisors, but do not stop at the definition. Know what that difference means for performance, operations, and troubleshooting.

Type 1 hypervisor

A Type 1 hypervisor runs directly on the physical server hardware.

Physical server
Type 1 hypervisor
VM 1
VM 2
VM 3

There is no general-purpose desktop OS underneath it. This is why Type 1 is often called bare metal.

Type 1 hypervisors are common in data centers because they are built for production workloads. The hypervisor owns the hardware directly, manages CPU and memory scheduling, and connects VMs to virtual switches and physical uplinks.

Common examples include VMware ESXi, Microsoft Hyper-V when installed as the virtualization platform, and KVM-based platforms.

Type 2 hypervisor

A Type 2 hypervisor runs as an application on an existing operating system.

Laptop or desktop hardware
Host operating system
Type 2 hypervisor application
VM 1
VM 2

This is common for labs. If you have used VirtualBox, VMware Workstation/Fusion, UTM, or similar tools, you have seen the Type 2 model.

Type 2 is convenient because you can run VMs on your laptop. The tradeoff is that the host OS is still in the path. That can add overhead and another layer of networking settings.

Side-by-side

What the network sees

The physical network usually does not care whether the server is Type 1 or Type 2. It sees frames arriving on a switchport.

What changes is where you troubleshoot before the packet reaches that switchport.

For Type 1:

VM
vSwitch/port group -> host uplink -> physical switch

For Type 2:

VM
hypervisor vNIC → host OS → physical NIC → physical switch

That host OS layer matters in labs. NAT mode, bridged mode, host-only mode, Wi-Fi restrictions, local firewalls, and OS routing can change what the VM can reach.

Lab: classify the hypervisor and predict the failure point

Scenario A

A company runs thirty production Linux servers on a rack-mounted host. The host boots directly into a virtualization platform. VMs connect to distributed port groups and the host uplinks are 25G trunks.

Answer:

Hypervisor type: Type 1
Likely network checks: port group VLAN, host uplink, physical trunk, distributed switch policy

Scenario B

A learner runs two IOSv routers and one Linux VM on a laptop. The laptop runs macOS or Windows. The hypervisor has NAT, bridged, and host-only network modes.

Answer:

Hypervisor type: Type 2
Likely network checks: VM network mode, host OS firewall, bridge/NAT settings, laptop NIC

Scenario C

A VM cannot ping the default gateway. The physical switch trunk allows VLAN 40. The VM is connected to a port group for VLAN 30.

Answer:

The physical trunk may be fine. The VM is attached to the wrong virtual network.

Code-style verification checklist

Use this as a runbook when a virtual lab behaves strangely.

Inside the VM

• show ip interface brief or ip addr
• ping default gateway
• arp -n

Physical switch

• show interfaces trunk
• show mac address-table on host uplink
• show vlan brief

Hypervisor

• VM powered on and vNIC connected
• Correct port group / VLAN
• Host uplink selected

Exam traps

• Type 1 does not mean “cloud” and Type 2 does not mean “small.” The difference is where the hypervisor runs.
• A Type 2 lab can fail because of the host OS even when router configs are correct.
• A Type 1 host can still have network mistakes in port groups, uplinks, security policy, or VLAN tagging.
• The physical switch sees traffic after the virtual switching layer has already made forwarding/tagging decisions.

Quick check

1. What makes a hypervisor Type 1?
2. Why is Type 2 common in labs?
3. What extra network layer can affect Type 2 VM connectivity?
4. If the physical trunk allows the VLAN but the VM is on the wrong port group, where is the problem?
5. Why does a network engineer still care about hypervisor settings?