Study guide
6.1 Virtualization Concepts & Hypervisor Types
CompTIA Tech+ FC0-U71
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: IT Concepts & Terminology
1.1 CompTIA Tech+ Overview & The Computing Cycle 1.2 Notational Systems & Character Representation 1.3 Units of Measure for Storage, Throughput & Speed
2 Chapter 2: Troubleshooting Methodology & Computing Devices
2.1 CompTIA 6-Step Troubleshooting Process 2.2 Computing Device Categories & Purposes 2.3 IoT, Smart Devices & Specialized Hardware
3 Chapter 3: Internal Hardware Components & System Storage
3.1 Motherboards, CPUs & Memory Architecture 3.2 Firmware, Power Delivery & Hardware Configuration 3.3 Storage Media & Drive Technologies
4 Chapter 4: Peripherals, Interfaces & Connections
4.1 Peripheral Device Types & Configuration 4.2 Wired I/O Interfaces & Video Cable Standards 4.3 Wireless Peripheral Connectivity & Short-Range RF
5 Chapter 5: Networking Technologies & Internet Services
5.1 Internet Access Technologies & Connection Types 5.2 Network Scopes & Physical Infrastructure 5.3 Wi-Fi Standards, Bands & Performance 5.4 IP Addressing & Fundamental Network Protocols
6 Chapter 6: Virtualization, Cloud Computing & AI Fundamentals
6.1 Virtualization Concepts & Hypervisor Types 6.2 Cloud Architecture & Service Categories 6.3 Artificial Intelligence Concepts & Modern Use Cases
7 Chapter 7: Operating Systems Architecture & Management
7.1 Operating System Categories & Core Functions 7.2 OS Architecture, Process Management & Utilities 7.3 File Systems, Directory Trees & Access Control
8 Chapter 8: Applications, Software Licensing & Web Browsing
8.1 Software Applications & Business Productivity Suites 8.2 Software Deployment Architectures & Licensing 8.3 Web Browser Architecture & Security Configuration
9 Chapter 9: Software Development & Programming Concepts
9.1 Programming Language Categories & Paradigms 9.2 Data Types, Variables & Identifiers 9.3 Programming Logic, Control Flow & Data Structures
10 Chapter 10: Data Concepts, Analytics & Database Fundamentals
10.1 The Value of Data, Information & Big Data Analytics 10.2 Relational Database Concepts & Schema Structure 10.3 Non-Relational Databases & Core SQL Commands
11 Chapter 11: Data Protection, Backup & Recovery
11.1 Data Backup Methodologies & Recovery Strategies 11.2 Backup Media Destinations & Disaster Recovery
12 Chapter 12: Security Concepts, Access Control & Device Hardening
12.1 Foundational Security Principles & the CIA Triad 12.2 Security Threats, Social Engineering & Malware Defense 12.3 Physical Security & Endpoint Hardening Practices
13 Chapter 13: Identity, Encryption & Wireless Network Security
13.1 Password Security Practices & Multi-Factor Authentication 13.2 Encryption Concepts & Cryptographic Applications 13.3 Wireless Network Security & Access Controls
6.1 Virtualization Concepts & Hypervisor Types
Key Takeaways Explain This Topic AI
Virtualization decouples physical hardware from software execution, enabling multiple isolated Virtual Machines (VMs) to run concurrently on a single physical host.
Hypervisors (Virtual Machine Monitors) manage hardware resource scheduling: Type 1 (bare-metal) executes directly on host silicon for high-density datacenters, while Type 2 (hosted) runs atop an existing host OS for desktop development and testing.
Virtual hardware allocation maps physical components into software abstractions including virtual CPUs (vCPUs), virtual RAM (vRAM), virtual hard disks (.vmdk, .vhd/.vhdx), and virtual Network Interface Cards (vNICs) connected to virtual switches.
While Virtual Machines virtualize the hardware layer to execute full, independent guest operating systems, containers share the host operating system kernel, offering significantly lighter disk footprints and sub-second initialization times.
Last updated: September 2026
Virtualization Concepts & Hypervisor Types
Exam Focus: Virtualization is the foundational technology underpinning modern datacenters, enterprise infrastructure, and cloud computing. Understanding the architectural differences between Type 1 and Type 2 hypervisors, how virtual hardware resources are provisioned, and when to deploy full Virtual Machines versus lightweight containers is essential for technical literacy.
The Foundations of Hardware Virtualization
Traditionally, computing followed a single-tenant physical deployment model : an operating system was installed directly onto physical computer hardware (bare metal), and applications executed within that operating system. This model suffered from severe inefficiencies. Most enterprise servers operated at only 5% to 15% of their total processing and memory capacity, wasting electrical power, physical rack space, and cooling capacity.
Virtualization resolves this inefficiency by introducing an abstraction layer between physical computer hardware and the operating systems that execute software workloads. Through virtualization, a single physical computer can host dozens or hundreds of independent, self-contained virtual environments simultaneously. Traditional Architecture vs. Virtualized Architecture:
- [ Traditional Server ] [ Virtualized Host Server ]
- +-----------------------+ +-----------------------------------+
- | Single Application | | App 1 | App 2 | App 3 | App 4 |
- +-----------------------+ +---------+---------+---------+---------+
- | Operating System | | Guest OS| Guest OS| Guest OS| Guest OS|
- +-----------------------+ +---------+---------+---------+---------+
- | Physical Hardware | | Hypervisor Layer |
- | (CPU, RAM, Disk) | +-----------------------------------+
- +-----------------------+ | Physical Hardware |
- | (CPU, RAM, Disk) |
- +-----------------------------------+
- Host Systems vs. Guest Systems
Virtualization establishes a clear operational hierarchy between the underlying physical machine and the virtual environments it sustains:
Host System (Physical Machine): The underlying physical server, desktop, or laptop that provides genuine silicon, memory modules, storage controllers, and physical network adapters. The host supplies the raw computational horsepower.
Guest System (Virtual Machine): An emulated software computer that runs atop the host. Each Virtual Machine (VM) operates as an independent digital entity with its own virtual processor, virtual memory, virtual storage, and virtual network adapters. To the software running inside it, the guest VM perceives itself as an autonomous physical machine.
Guest Operating System: The operating system installed directly inside the virtual machine (such as Windows Server, Ubuntu Linux, or Red Hat Enterprise Linux). The guest OS interacts with virtualized hardware abstractions created by the hypervisor rather than directly executing against physical motherboard silicon.
Virtual Hardware Resource Allocation
When a systems administrator provisions a new virtual machine, the hypervisor allocates slices of physical host resources and translates them into virtual abstractions:
Virtual CPU (vCPU): A virtual processor assigned to a VM. The hypervisor maps vCPUs to physical CPU cores or execution threads using advanced CPU scheduling algorithms. Administrators can assign multiple vCPUs to a compute-heavy database VM while assigning a single vCPU to a lightweight DNS server. Advanced hypervisors support CPU overcommitment , where the total sum of configured vCPUs across all VMs exceeds the number of physical CPU cores, banking on the statistical likelihood that not all VMs require 100% CPU utilization simultaneously.
Virtual RAM (vRAM): A defined block of memory allocated to the guest VM from the physical host's RAM pool. Technologies such as memory ballooning and transparent page sharing allow hypervisors to dynamically reclaim unused memory from idle VMs and reallocate it to busy VMs experiencing memory pressure.
Virtual Hard Disks: Persistent storage presented to the guest OS as a physical storage drive. In reality, a virtual disk is encapsulated as a single large file stored on the host's physical file system or Storage Area Network (SAN). Standard virtual disk file formats include:
VMDK (Virtual Machine Disk): Standardized format developed by VMware.
VHD / VHDX (Virtual Hard Disk): Native formats utilized by Microsoft Hyper-V (VHDX supports capacities up to 64 TB and resilient metadata logging).
QCOW2 (QEMU Copy-On-Write): Primary format used by KVM (Kernel-based Virtual Machine) in Linux.
Provisioning Types: Virtual disks can be provisioned as Thick Provisioned (the entire disk capacity, such as 500 GB, is immediately allocated on physical storage up front) or Thin Provisioned (the disk file starts small, e.g., 20 GB, and dynamically grows on demand as data is written, up to the defined limit).
Virtual Network Interface Cards (vNICs) & Virtual Switches: Each VM is assigned one or more software-emulated network adapters, complete with unique virtual MAC addresses. These vNICs connect to a Virtual Switch (vSwitch) —a software-defined network bridge operating inside the hypervisor. The vSwitch bridges traffic from the VMs to the physical host NIC, enabling VMs to communicate with each other, access physical LAN resources, and traverse default gateways out to the Internet.
- Physical Component Virtualized Abstraction Management Mechanism
- Physical Multi-Core CPU vCPU Hypervisor thread scheduler & time-slicing
- Physical DDR4/DDR5 RAM vRAM Virtual memory paging & ballooning drivers
- Physical NVMe/SATA SSD Virtual Disk (.vmdk / .vhdx) File container (Thin vs. Thick allocation)
- Physical PCIe Gigabit NIC vNIC Virtual Switch (vSwitch) bridging & VLAN tagging
- Hypervisor Classifications: Type 1 vs. Type 2
The software layer responsible for creating, executing, and orchestrating virtual machines is called a Hypervisor , also known as a Virtual Machine Monitor (VMM) . Hypervisors fall into two distinct structural classifications based on where they reside in the software stack. TYPE 1 HYPERVISOR TYPE 2 HYPERVISOR
(Bare-Metal / Native) (Hosted / Desktop)
- +-----------------------------------+ +-----------------------------------+
- | Guest VM 1 | Guest VM 2 | | Guest VM 1 | Guest VM 2 |
- | (Linux OS) | (Windows OS) | | (Linux OS) | (Windows OS) |
- +---------------+-------------------+ +---------------+-------------------+
- | HYPERVISOR | | HYPERVISOR |
- | (VMware ESXi, Hyper-V, KVM) | | (VirtualBox, Workstation) |
- +-----------------------------------+ +-----------------------------------+
- | | | HOST OPERATING SYSTEM |
- | PHYSICAL HARDWARE | | (Windows 11, macOS, Linux) |
- | (CPU, RAM, Storage, Network) | +-----------------------------------+
- | | | PHYSICAL HARDWARE |
- +-----------------------------------+ +-----------------------------------+
- Type 1: Bare-Metal (Native) Hypervisors
A Type 1 Hypervisor installs directly onto the physical server hardware, completely replacing any general-purpose host operating system. Because it interacts directly with physical CPU instruction sets, memory channels, and storage buses without an intermediate operating system layer, it is referred to as bare-metal or native .
Performance and Efficiency: Delivers near-native bare-metal execution speeds with negligible virtualization overhead (typically 1% to 3%). It manages device drivers directly for certified datacenter hardware.
Security and Stability: Minimal software footprint means a vastly reduced attack surface. Because there is no general-purpose host OS (like Windows 11 or desktop Linux) running background desktop services, there are fewer vulnerabilities to patch and fewer reboots required.
Enterprise Datacenter Standard: Type 1 hypervisors power virtually all modern enterprise datacenters, private clouds, and commercial public cloud providers (including AWS, Microsoft Azure, and Google Cloud).
Prominent Examples:
VMware ESXi: The industry-leading enterprise bare-metal hypervisor managed through vSphere.
Microsoft Hyper-V: Enterprise hypervisor embedded in Windows Server (Hyper-V installs underneath the parent management partition, running directly on hardware).
KVM (Kernel-based Virtual Machine): An open-source virtualization module integrated directly into the Linux kernel, transforming Linux into a Type 1 bare-metal hypervisor.
Citrix Hypervisor (XenServer): High-performance bare-metal hypervisor widely used in virtual desktop infrastructure (VDI).
Type 2: Hosted Hypervisors
A Type 2 Hypervisor installs and executes as an application program on top of a standard host operating system (such as Windows 11, macOS, or Ubuntu Desktop). It relies on the host OS to manage physical device drivers, system scheduling, and hardware interactions.
Performance and Latency: Introduces measurable overhead because every hardware request issued by the guest VM must pass through two software layers: first through the Type 2 hypervisor, and then through the host operating system kernel, before reaching the physical silicon.
Dependency on Host OS: If the host operating system crashes, encounters a blue screen error, or requires a restart for system updates, all guest virtual machines running within the hosted hypervisor terminate immediately .
Accessibility and Ease of Use: Extremely easy to install, configure, and manage. It runs alongside ordinary desktop applications (web browsers, word processors) and allows seamless drag-and-drop file sharing and clipboard synchronization between the host desktop and guest VM.
Primary Use Cases: Local software development, application testing across multiple OS versions, running legacy applications incompatible with the host OS, cybersecurity training, and safe malware analysis.
Prominent Examples:
Oracle VM VirtualBox: Free, open-source cross-platform hosted hypervisor supporting Windows, macOS, and Linux hosts.
VMware Workstation Pro / Player: Commercial desktop virtualization for Windows and Linux.
VMware Fusion: Desktop virtualization designed specifically for macOS.
Parallels Desktop: Optimized virtualization tool for running Windows on macOS hardware.
Comprehensive Hypervisor Comparison
- Feature Type 1 (Bare-Metal) Type 2 (Hosted)
- Installation Location Directly on physical computer hardware On top of an existing host operating system
- Underlying Host OS None (Hypervisor is the operating system) Windows, macOS, or Linux
- Performance Overhead Extremely low (1%–3% overhead) Noticeable overhead due to host OS translation
Stability & Uptime Maximum; highly resilient for continuous uptime Dependent on host desktop stability and reboots
Management Interface Remote web console, API, or dedicated management client Local graphical application window on desktop
Primary Environment Enterprise datacenters, server rooms, public clouds Developer workstations, home labs, classrooms
- Typical Examples VMware ESXi, Microsoft Hyper-V, KVM Oracle VirtualBox, VMware Workstation, Parallels
- Operational Advantages of Virtualization
Organizations adopt hardware virtualization because it fundamentally improves computing economics, administrative agility, and disaster recovery capabilities.
1. Server Consolidation & Datacenter Footprint Reduction
Before virtualization, deploying twenty distinct corporate services (email, active directory, payroll, internal wiki, web proxy, DNS, file sharing) required purchasing, racking, and powering twenty independent physical rack servers.
Consolidation Ratios: With virtualization, those twenty workloads can be consolidated as guest VMs onto one or two high-performance physical servers equipped with redundant power supplies and multi-core processors.
Operational Savings: Server consolidation drastically slashes electrical utility consumption, reduces air conditioning (HVAC) cooling demands, minimizes physical datacenter floor space, and cuts networking switch port requirements by up to 80%.
2. Rapid Provisioning & Templating
Procuring a physical server involves vendor quotes, shipping, unboxing, rack mounting, cabling, and operating system installation—a process requiring weeks. In contrast, provisioning a virtual machine takes less than two minutes . Administrators maintain golden image templates (pre-configured, sysprepped OS images with baseline security policies applied) and clone new VM instances instantly upon demand.
3. Point-in-Time Snapshots
A snapshot captures the exact state, configuration, and data of a virtual machine at a specific moment in time. When a snapshot is taken, the hypervisor freezes the base virtual disk file into read-only mode and routes all subsequent write operations to a new delta differencing file .
Change Management Safeguard: Systems administrators routinely capture a snapshot immediately before applying operating system service packs, installing software upgrades, or editing critical registry hives.
Instant Rollback: If the update introduces corruption or breaks application dependencies, the administrator executes a rollback operation . The hypervisor discards the delta differencing file and restores the VM to its pristine pre-patch operational state in seconds.
Exam Trap: A snapshot is NOT a backup! Snapshots rely entirely on the integrity of the original base virtual disk. If the physical storage drive hosting the base disk fails, the snapshot cannot recover the system. Furthermore, leaving active snapshots running for weeks degrades disk I/O performance and consumes massive storage space as delta files balloon.
4. Sandboxing & Security Isolation
Because the hypervisor enforces strict memory and execution isolation between guest VMs, virtual environments serve as excellent sandboxes . Cybersecurity analysts safely detonate suspicious email attachments, analyze active ransomware execution, and reverse-engineer malware inside a dedicated VM. If the guest OS is compromised, the infection remains trapped inside the virtual sandbox without threatening the physical host or corporate network (provided virtual networking is isolated).
5. Hardware Independence & Live Migration
Because every VM is completely abstracted from the underlying physical silicon and stored as portable disk files, VMs are hardware-independent. If host server hardware requires maintenance, advanced clustering technologies (such as VMware vMotion or Microsoft Hyper-V Live Migration) transfer running VMs across physical hosts over a high-speed network with zero dropped user connections and zero downtime .
Virtual Machines vs. Containers
While hardware virtualization with VMs remains foundational, modern software deployment increasingly utilizes Containers —an architectural evolution representing operating system-level virtualization . VIRTUAL MACHINE ARCHITECTURE CONTAINER ARCHITECTURE
- +-----------------------------------+ +-----------------------------------+
- | App A | App B | App C | | App A | App B | App C |
- +------------+------------+---------+ +------------+------------+---------+
- | Bins/Libs | Bins/Libs |Bins/Libs| | Bins/Libs | Bins/Libs |Bins/Libs|
- +------------+------------+---------+ +-----------------------------------+
- | Guest OS | Guest OS |Guest OS | | CONTAINER ENGINE (Docker) |
- | (Windows) | (Ubuntu) | (RedHat)| +-----------------------------------+
- +-----------------------------------+ | HOST OPERATING SYSTEM |
- | HYPERVISOR | | (Shared Linux Kernel) |
- +-----------------------------------+ +-----------------------------------+
- | PHYSICAL HARDWARE | | PHYSICAL HARDWARE |
- | (CPU, RAM, Storage, Network) | | (CPU, RAM, Storage, Network) |
- +-----------------------------------+ +-----------------------------------+
- The Architectural Difference: Shared Kernel vs. Guest OS
The fundamental distinction between a virtual machine and a container lies in what layer of the software stack is being virtualized :
Virtual Machines Virtualize Hardware: The hypervisor emulates physical hardware (vCPU, vRAM, vNIC, BIOS/UEFI). Each VM must boot its own dedicated, complete Guest Operating System , containing its own kernel, system binaries, device drivers, background services, and patch management overhead. A single VM image typically measures 10 GB to 40 GB and requires several minutes to boot.
Containers Virtualize the Operating System: Containers bypass hardware emulation entirely. Instead, a container engine (such as Docker, Podman, or containerd) runs atop the host OS kernel. Containers execute as isolated user-space processes that share the host operating system kernel directly . A container packages only the application code, runtime libraries, and environment dependencies required to execute the workload. Because no guest OS kernel needs to boot, containers initialize in milliseconds and frequently measure only 50 MB to 500 MB in size.
VMs vs. Containers Architectural Comparison
- Characteristic Virtual Machine (VM) Container (e.g., Docker)
- Virtualization Layer Hardware Level (vCPU, vRAM, virtual disks) Operating System Level (User Space)
- Operating System Full independent Guest OS per VM Shares the Host OS Kernel
- Storage Footprint Gigabytes to tens of Gigabytes (10–50+ GB) Megabytes (50–500 MB)
- Startup / Boot Time Minutes (must boot full OS kernel) Milliseconds to seconds (launches process)
- Resource Overhead High (each VM runs background OS services) Minimal (executes only application code)
- Security Isolation Strong (hardened hypervisor boundary) Moderate (process isolation via cgroups/namespaces)
- Density per Host Dozens of VMs per physical host Hundreds or thousands of containers per host
- Ideal Use Case Monolithic apps, diverse OSs, multi-tenancy Microservices, rapid scaling, CI/CD pipelines
- Common Exam Traps & Real-World Pitfalls
Trap 1: Confusing VM Snapshots with True Backups. The exam frequently presents scenarios where an administrator relies solely on snapshots for disaster recovery. If the underlying storage volume or physical server suffers catastrophic hardware failure, all snapshots are lost along with the base disk. A true backup is an independent, validated duplicate of the VM exported to physically separate storage or an offsite cloud repository.
Trap 2: Misclassifying Microsoft Hyper-V as Type 2. Because Hyper-V is managed through graphical tools on Windows Server or Windows 11 Pro, students often mistake it for a Type 2 hosted hypervisor. In reality, enabling the Hyper-V role installs a Type 1 bare-metal hypervisor directly on the hardware; the Windows operating system is demoted to a privileged "parent management partition" that runs atop the Hyper-V hypervisor.
Trap 3: Resource Overcommitment Exhaustion. While hypervisors permit assigning more vCPUs and vRAM than physical hardware possesses, excessive overcommitment leads to severe performance degradation. If too many VMs request CPU cycles simultaneously, the hypervisor incurs high CPU ready time (the time a vCPU waits for physical CPU time), resulting in stuttering and application timeouts.