Understanding Hypervisors

Lesson purpose

A hypervisor is the control layer that makes shared hardware usable by multiple virtual machines. It presents virtual processors, memory, storage, and networking, then schedules and mediates requests against finite physical capacity. This lesson moves beyond the idea that a hypervisor simply starts a VM. Students should leave able to explain where the hypervisor sits, how Type 1 and Type 2 architectures differ, and which responsibilities affect performance, isolation, availability, and platform selection.

Learning objectives

By the end of the lesson, students should be able to:

• Place the hypervisor between physical hardware and guest software.
• Explain the hypervisor’s roles as presenter, scheduler, isolator, and mediator.
• Distinguish Type 1 and Type 2 hypervisors by their dependency chains and common use cases.
• Trace CPU, memory, storage, network, and device requests through the control layer.
• Explain why fair sharing is not always equal sharing.
• Compare platform families by requirements rather than popularity alone.

1. The hypervisor as a resource arbiter

The hypervisor sits below virtual machines and above the physical resources. At the highest level it is an arbiter: it decides which workload can use which capacity, when the work can run, and what boundaries apply. It also presents a virtual environment, supports virtual networks, and may participate in clustering and high availability.

The layer has four practical responsibilities:

• Present: expose virtual processors, memory, disks, adapters, firmware, and device interfaces.
• Schedule: allocate finite processor, memory, and I/O capacity across competing workloads.
• Isolate: keep one guest from reading or changing another guest’s memory, devices, or execution context.
• Mediate: control the path between a virtual device and the physical resource that performs the work.

Without a hypervisor, multiple operating systems would try to control the same hardware directly. Disk requests, memory calls, and device ownership would collide. The hypervisor turns that conflict into an explicit control problem.

2. The architecture layers

The basic stack is physical hardware, hypervisor, virtual machines, and guest software. Physical processors, memory, controllers, storage, and adapters supply real capacity. The hypervisor converts that capacity into managed virtual resources. Each VM receives an isolated hardware view. The guest operating system and applications operate within that VM boundary.

Management tools are not automatically the hypervisor. A console or API may configure the platform, but the hypervisor performs the low-level scheduling, mapping, and enforcement. This distinction helps during troubleshooting: a management connection can fail while the VMs continue running, and a healthy console does not prove that storage or CPU latency is acceptable.

3. Type 1 and Type 2 hypervisors

Type 1 hypervisors run directly on the server platform as the primary virtualization layer. A privileged management partition or service environment may provide drivers and administration, but guest execution does not depend on a general-purpose desktop operating system. Type 1 architectures fit dedicated servers, centralized operations, clustering, and production workload control. Microsoft Hyper-V is a Type 1 architecture even though its root or parent partition uses Windows services.

Type 2 hypervisors run as applications inside an existing operating system. They reuse the host OS’s drivers and desktop services. VirtualBox and desktop VMware products are common examples. Type 2 is convenient for development, testing, training, and labs because a student can install the platform alongside normal desktop software. The tradeoff is an added dependency: host OS health, updates, device drivers, and resource use affect the VM environment.

The correct choice follows the workload and operating model. A production cluster and a one-student lab may run similar guests but justify different architectures. Type 2 is not automatically poor quality; it simply optimizes for a different failure boundary and management context.

4. How the hypervisor controls resources

CPU scheduling

A vCPU is the processor context presented to a guest. A pCPU is a physical execution resource. The scheduler chooses which vCPU runs, where it runs, and for how long. Assigning eight vCPUs does not create eight dedicated physical cores. Too many vCPUs can increase scheduling delay, so size from application demand and validate with utilization and latency evidence.

Memory mapping

The guest sees a configured amount of memory, while the hypervisor maps guest pages to physical memory and protects the address space. Configured, consumed, reserved, and physically resident memory are different measurements. A guest can report enough RAM while the host experiences pressure from many active VMs. Reclamation, ballooning, swapping, or other optimization mechanisms may preserve operation while degrading performance.

Device virtualization

Devices may be emulated, exposed through paravirtualized drivers, or assigned more directly to one VM. Emulation maximizes compatibility. Paravirtualization uses a guest-aware interface to reduce overhead. Direct assignment can improve performance but may reduce portability, sharing, or mobility. Students should treat this as a tradeoff, not a ranking.

Storage and networking

For storage, the guest sees a virtual disk while files, logical volumes, or shared storage hold the actual blocks. Multiple guests can queue against one datastore, so separate virtual disks do not guarantee separate physical performance. For networking, a virtual NIC connects to a software switch and then to an uplink or another guest. Two VMs on one host may communicate without a physical switch port. Host-only, NAT, bridged, and isolated networks create different reachability and security boundaries.

5. Policy, availability, and platform families

Fair sharing is not always equal sharing. Limits cap maximum use. Reservations protect a minimum amount where the platform supports them. Shares or weights express relative priority during contention. Monitoring verifies that the policy produces the intended service level. Policy decides how scarcity is handled; it does not create new capacity.

Availability extends control beyond one host. Health detection can identify failure. Restart can place a VM on surviving capacity. Mobility supports maintenance and load management. Shared storage, networking, quorum, and available capacity must support recovery. High availability can restart a VM after a host failure, but it does not replace backup, application resilience, or a restore test.

Platform families implement the same jobs differently. ESXi is a dedicated enterprise platform in the VMware ecosystem. Hyper-V combines a Type 1 architecture with a Windows root partition and VMBus services. KVM and Xen provide open virtualization foundations used in Linux and cloud platforms. VirtualBox, Workstation, and Fusion support desktop labs and development. Product packaging and licensing change, so begin with architecture, workload support, operations, security, and economics.

Classroom application

Give students four scenarios and require a specific concept, not the generic answer “hypervisor”:

1. A server boots into the virtualization platform: Type 1.
2. A student installs a hypervisor inside a desktop OS: Type 2.
3. Two guests compete for processor execution: CPU scheduling.
4. One guest must not read another guest’s memory: isolation.

Then have students choose a platform for a production cluster and for a laptop-based development lab. Their explanation should include guest support, hardware, lifecycle, monitoring, backup, security, staffing, and cost. Finish by tracing a guest storage request through the virtual disk, hypervisor policy, backing datastore, and returned result.

Common misconceptions

• A hypervisor is not merely a VM launcher or management console.
• Type 1 does not mean that no privileged management partition exists.
• Type 2 does not mean “unsafe” or “unusable”; it means the host OS is part of the dependency chain.
• More vCPUs do not guarantee more performance.
• Equal resource allocation can be unfair when workloads have different business priorities.
• A cluster can improve restart and mobility without providing backup or application-level resilience.
• Product names are not architecture decisions. Requirements should eliminate unsuitable platforms before price comparisons.

Lesson summary

The hypervisor presents virtual resources, schedules competing demand, isolates guests, and mediates access to hardware. Type 1 makes virtualization the host platform; Type 2 depends on an existing host operating system. CPU, memory, device, storage, and network behavior all reflect shared-resource decisions. Policies, monitoring, and availability features extend the control model, but none removes the need for capacity planning and recovery testing. The next lesson shifts from the control layer to the software-defined computers it manages.