Virtualization Basics
Learn how virtual machines share physical hardware while remaining isolated as separate computer systems.
- Certification
- CompTIA A+
- Recommended study time
- 5h 50m
- Status
- Not started
Recommended study time
About 5h 50m in total, measured from the material on this page. At your session length of 45 minutes that is 8 sittings.
- Read the lesson20 min
About 2,630 words at a careful technical reading pace.
- Second pass with notes12 min
Re-read the harder parts and write your own notes.
- Work through the examples20 min
1 worked example and 3 practice questions.
- Recall from memory12 min
2 written recall questions.
- Practice decision12 min
One applied decision with feedback.
- Teach it back20 min
Write the topic in your own words.
- Real-world scenario15 min
Read the situation and justify your decision in writing.
- Hands-on practice2h 40m
Labs, commands and configuration until you can do it unaided.
- Spaced review1h 20m
4 short review sessions spread over the following weeks.
Learning objectives
- Distinguish a host, hypervisor, guest, virtual machine, and container.
- Explain common benefits and limits of virtualization.
- Choose sensible CPU, memory, storage, and network resources for a small lab VM.
Start here
About 17 minutes of reading, in 9 short parts.
Virtualisation breaks the assumption that one physical computer runs one operating system. A hypervisor divides real hardware into isolated virtual machines, which is the foundation of the modern data centre, of cloud computing, and of the lab you will use to practise everything else in this programme.
Where you meet it: Server consolidation, test environments, your own study lab, and every cloud instance you will ever provision.
The lesson, part by part
Open one part at a time. Each part stands on its own, so you can stop and come back.
A hypervisor presents virtual CPUs, memory, disks, and network adapters to guest operating systems, and schedules the real hardware underneath. The physical machine is the host; each virtual computer is a guest. Guests are isolated from each other: a guest crash does not affect its neighbours, and a guest believes it owns a complete machine.
Type 1 hypervisors (VMware ESXi, Microsoft Hyper-V, Proxmox/KVM) install directly on the hardware and are used in production. Type 2 hypervisors (VirtualBox, VMware Workstation) run as an application on a desktop OS and are what you will use to learn. Type 1 gives better performance and density; Type 2 gives convenience.
Key ideas
If you remember nothing else from this topic, remember these.
- A Type 1 hypervisor installs directly on hardware for production performance and density, while a Type 2 hypervisor runs as an application on top of a desktop operating system for convenience, and choosing the wrong type for the use case wastes either performance or simplicity.
- Memory is the resource that most reliably runs out first in virtualization, and overcommitting it across guests forces the host itself to swap, which quietly degrades every guest at once rather than failing one guest cleanly.
- Hardware virtualization extensions, Intel VT-x or AMD-V, let guest instructions run nearly natively on the real processor while the hypervisor only intercepts privileged operations, which is why these extensions must be enabled in firmware before any 64-bit guest will start.
- A snapshot captures a point-in-time state for short-term rollback, but it typically still depends on the original virtual disk file, so it is not a substitute for a real backup and can silently grow until it exhausts datastore space.
- Containers isolate a process using the host kernel's namespaces and cgroups rather than virtualizing hardware, which makes them start in milliseconds but also means every container on a host shares that one kernel, so a Windows container cannot run on a Linux host kernel.
- Virtual networking mode determines whether a guest is reachable from the physical network at all: bridged puts it on the LAN directly, NAT hides it behind the host's address, and host-only isolates it to a private lab network with no outside path.
Diagnosing a virtual machine that will not start after a hypervisor upgrade
A worked example, step by step.
After installing a new Type 2 hypervisor update, a technician's Linux virtual machine refuses to power on, reporting a 64-bit guest error, while it worked fine before the update.
- 01Read the exact errorThe hypervisor reports that this host does not support 64-bit guest operation, or virtualization has been disabled.
- 02Check firmware settingsReboot into UEFI firmware setup and look for the virtualization extension setting, commonly labeled Intel VT-x or SVM Mode for AMD.
- 03Confirm the setting's current stateThe setting shows as Disabled, despite it previously being enabled, suggesting a firmware reset or update reset it to default.
- 04Enable and saveToggle the setting to Enabled, save changes, and allow the machine to reboot fully back into the host operating system.
- 05Re-test the VMAttempt to power on the same virtual machine again; it now progresses past the earlier error but hangs at a black screen.
- 06Check for a conflicting hypervisorOn Windows, run bcdedit /enum to check if Hyper-V or WSL2's virtualization layer is also enabled, since both compete for the same CPU extensions as the Type 2 hypervisor.
- 07Resolve the conflictDisable the competing feature (Windows Hypervisor Platform) through Windows Features, since only one hypervisor can own the extensions exclusively in this configuration.
- 08Verify full functionalityReboot once more and start the virtual machine; it boots cleanly to its Linux login prompt, and network connectivity inside the guest is confirmed with a successful ping to the gateway.
Outcome: The failure had two separate causes stacked together, a firmware setting reset by the update and a competing hypervisor claiming the same CPU extensions; resolving both in sequence restored normal virtual machine operation.
Virtualization Facts Worth Memorising
Worth keeping at hand while you work.
- Type 1 hypervisor
- Runs directly on hardware; examples are VMware ESXi, Microsoft Hyper-V, Proxmox/KVM
- Type 2 hypervisor
- Runs as an application on a host OS; examples are VirtualBox, VMware Workstation
- Intel VT-x / AMD-V
- CPU hardware virtualization extensions required for efficient guest execution
- VMDK / VHDX / QCOW2
- Common virtual disk file formats used by VMware, Hyper-V, and KVM/QEMU respectively
- Thin vs thick provisioning
- Thin allocates disk space as used; thick reserves the full size up front
- Bridged networking
- Guest appears as its own device directly on the physical LAN
- NAT networking
- Guest shares the host's address and is hidden from the physical LAN
- Host-only networking
- Guest can reach the host and other guests, but has no path to the physical network
- Live migration
- Moves a running VM between hosts with no downtime, used to patch a host safely
- cgroups and namespaces
- Linux kernel features containers use for resource limits and process isolation
- Guest additions/integration tools
- Paravirtualized drivers improving disk, network, and display performance inside a guest
- vCPU oversubscription
- Assigning more virtual CPUs than physical cores can slow a guest due to scheduling contention
Common misunderstandings
What most beginners get wrong here.
A snapshot is an acceptable backup strategy for a virtual machine.
A snapshot usually depends on the original virtual disk file remaining intact and can grow indefinitely, so it protects against a bad recent change, not against actual data loss or storage failure.
Giving a virtual machine more vCPUs always makes it faster.
Assigning more vCPUs than the workload can use or than the host can schedule simultaneously introduces contention and can make performance worse, not better.
Containers and virtual machines provide the same level of isolation.
Containers share the host kernel and are isolated by namespaces and cgroups, a weaker boundary than a hypervisor, which fully separates guest kernels from each other.
You can run a Windows container on any Linux host by installing Docker.
Containers share the host kernel, so a Windows container needs a Windows kernel underneath; Linux containers cannot run Windows binaries no matter what container engine is installed.
If one virtual machine on a host is slow, the problem is inside that guest's operating system.
Host-level resource contention, such as memory overcommitment or a saturated datastore, commonly causes symptoms inside a single guest that look like an internal OS problem.
Exam traps
How the question writers try to catch you out.
- A question describing a VM that fails to start with a 64-bit guest error is testing whether you know to check firmware-level virtualization extensions first, not reinstall the guest OS.
- Expect the exam to test the specific difference between Type 1 and Type 2 hypervisors by describing a production data center scenario (Type 1) versus a technician's personal test lab (Type 2).
- Questions contrasting containers and VMs expect the kernel-sharing distinction specifically, not just 'containers are lighter weight.'
- A scenario where every VM on one host becomes slow simultaneously is testing host-level memory overcommitment or datastore capacity, not a fault in any single guest.
- Network mode questions expect you to match a stated requirement, such as 'the VM must be reachable from other physical devices on the LAN,' to bridged mode specifically, not NAT or host-only.
Check yourself
Answer in your head first, then reveal. This is not scored.
Why is a snapshot not considered a proper backup?
A host has plenty of free RAM, but a single guest still performs poorly. What two guest-level configuration issues should you check?
Why must Intel VT-x or AMD-V be enabled in firmware before a 64-bit guest will run?
A developer needs to run a single Linux application many times identically and start instances almost instantly. Should they use a VM or a container, and why?
What is the practical risk of setting a virtual machine's network adapter to NAT when the requirement is for other physical devices on the LAN to reach it directly?
Quick reference
A condensed summary of the lesson above, for revision.
What It Is
A virtual machine, or VM, is a software-defined computer with virtual CPU, memory, storage, and network hardware. A hypervisor allocates physical resources to VMs. The physical system is the host; each installed operating system is a guest. Containers instead share the host kernel and isolate applications rather than emulating a complete computer.
Why It Matters
Organizations consolidate servers, reproduce test environments, recover systems from images, and isolate workloads with virtualization. Learners can build a lab without buying several computers. Resource planning still matters: every guest consumes real host CPU, RAM, storage space, and network capacity.
How It Works
- A hypervisor presents virtual CPU, memory, disks, and network adapters to each guest.
- The host schedules real resources among active guests.
- Virtual switches connect VMs to one another or external networks.
Where You See It
- Server consolidation, learner labs, software testing, cloud compute, and disaster-recovery environments.
Key Terms
- Hypervisor
- The layer that creates and manages virtual machines.
- Host
- The physical system and base environment providing resources.
- Guest
- An operating system running inside a virtual machine.
- Snapshot
- A record of VM state used to return to an earlier point.
- Container
- An isolated application environment that shares the host OS kernel.
Examples
- A student runs a Linux guest on a Windows laptop to practice commands without replacing the host OS.
- A company runs several lightly used servers as separate VMs on one larger physical host.
Common Problems
- Overallocated RAM or CPU
- No virtual network connectivity
- Insufficient disk space
- Stale snapshots
How It Fails
- Host resource exhaustion slows every guest.
- A detached virtual adapter isolates one VM.
- Snapshot growth can fill the datastore.
How to Troubleshoot
- Check host capacity and guest allocation.
- Verify VM power state, virtual hardware, and network attachment.
- Inspect both guest symptoms and hypervisor events.
Practical Knowledge
- Leave enough resources for the host.
- Treat snapshots as short-term rollback points, not backups.
Exam Coverage
- Host, guest, and hypervisor roles
- VM resource planning
- Snapshots, networking, and containers
Interview Questions
- How is a virtual machine different from a container?
- Why can assigning more RAM to every VM make performance worse?
Worked examples
Each calculation is shown one step at a time, then you try it yourself before revealing the answer.
Size virtual machines on a host
A host has 16 GB RAM and 8 CPU cores. How many 4 GB lab VMs can safely run at once?
- 1. Reserve for the hostThe host operating system and hypervisor need their own memory — reserve about 4 GB.
- 2. Divide what remains16 − 4 = 12 GB available. 12 ÷ 4 = 3 VMs.
- 3. Check CPUCores can be oversubscribed; memory generally cannot. Two virtual CPUs each across 3 VMs is 6 of 8 cores — comfortable.
- 4. Check diskDynamically expanding disks grow over time; confirm free space on the host volume before you build.
Answer: Three 4 GB VMs. Memory is the hard limit: overcommit it and the host swaps to disk and everything crawls.
Now you try
Same host, VMs need 6 GB each. How many?
Why does a container need less memory than a VM?
Which resource can you safely oversubscribe?
Watch and read
Verified official and reputable sources for this topic. Links open in a new tab.
Video training
Reading and courses
Lesson notes and bookmark
Notes and bookmarks for this lesson, saved with everything else you have marked.
No notes on this item yet.
Learning progress
0% across six evidence areas. Reading alone does not change progress.
Prerequisites
Next steps
- 01Check whether virtualization support is enabled on your computer.
- 02Plan a small lab VM without assigning more RAM or CPU than the host can spare.