Fundamentals of Virtualization · Lessons 1–4
Fundamentals of Virtualization Study Guide: Lessons 1–4
Exam-focused review of virtualization, hypervisors, virtual machines, VM lifecycle tools, and physical-to-virtual conversion.
How to use this guide
This guide combines the Lessons 1–4 chapter material. It is organized by lesson so you can connect the foundational concepts of virtualization to the hypervisors, virtual machines, and migration workflows they support.
Study in this order:
- Learn the vocabulary and comparisons in the lesson summaries.
- Explain the key comparisons and workflows in your own words.
- Revisit the high-yield distinctions and connect them across the lessons.
The ideas that connect all four lessons
Virtualization separates the software view of a computer from the physical hardware that supplies it. A guest operating system sees virtual CPUs, memory, disks, and network adapters. A hypervisor or virtual machine monitor (VMM) maps those requests to shared physical resources while enforcing boundaries between workloads.
The four ideas below are the foundation for the lessons in this guide:
- Fidelity: the virtual environment behaves like the physical environment expected by the guest.
- Isolation or safety: one VM cannot improperly control or read another VM’s resources.
- Performance: virtualization adds little enough overhead that the environment remains useful.
- Resource mediation: the hypervisor schedules and maps CPU, memory, storage, networking, and device requests.
Popek and Goldberg described a virtual machine monitor by three characteristics: it provides an environment identical to the physical environment, at minimal performance cost, while retaining complete control of the system resources. Fidelity, isolation, and performance are the properties a VMM needs to be efficient; simplicity is not one of them. Utilizing a self-managing pool of easily consumable resources describes cloud computing, not a hypervisor.
Virtualization does not remove physical hardware. It creates a managed software layer that makes physical capacity shareable, movable, repeatable, and easier to provision.
Lesson 1 — Understanding Virtualization
Why virtualization developed
Older data centers commonly placed one application on one physical server. As commodity servers became more powerful, many systems used only a small portion of their available CPU and memory. The result was server sprawl: more hardware, power, cooling, cabling, maintenance, and floor space than the workloads actually required.
Virtualization addresses this problem by allowing multiple isolated VMs to share a physical host. A consolidation ratio describes the relationship, such as eight VMs on one host being an 8:1 ratio. The ratio is meaningful only when CPU, memory, storage, network, availability, and application performance remain acceptable.
Consolidation and containment
- Consolidation moves existing physical workloads onto fewer virtualized hosts. It addresses yesterday’s physical-server sprawl.
- Containment deploys new application workloads directly into an existing virtual infrastructure. It changes tomorrow’s deployment habit.
- A virtualization-first policy means new projects should use existing virtual resources when those resources satisfy the requirements instead of automatically purchasing another physical server.
- Related policies are easy to confuse: a virtualization management strategy says an organization with virtualization infrastructure should use virtualization tools to create its virtual environment; a server virtualization policy sets requirements for acquiring, using, and managing server virtualization technology; and a virtualization security policy sets requirements for securely deploying, migrating, and managing VMs.
Types of virtualization
- Server virtualization: one physical server supports multiple VMs.
- Desktop virtualization: desktops execute centrally while users may connect through thin clients. Centralized images simplify support, and thin clients generally use less electricity than a PC, are not less reliable or more expensive than a PC, do not need specialized skills to replace, and have a long life span (about 7 to 10 years).
- Application virtualization: an application is isolated or packaged so it can be deployed with fewer conflicts and less dependence on the local operating system. Examples include VMware ThinApp, Microsoft App-V, and Citrix application streaming. These do not create a VM on a PC; a desktop hypervisor such as Oracle VirtualBox does.
- Network and storage virtualization: physical network or storage capacity is presented as logical, manageable resources.
- Converged infrastructure: compute, networking, and storage are assembled into a single unit and managed as one integrated system.
- Virtual appliance: a specially designed, preconfigured virtual machine. A virtual appliance that resides on each host can protect all of the virtual desktops running on that host from malware, without loading anti-malware software in every guest. It also eases deployment of a virtual application and improves interaction between applications on a host. It does not provide the environment in which a virtual application runs. Do not confuse it with a container (packages an application and its requirements for repeatable deployment in many environments), OpenStack (an open-source project for managing pools of compute, network, and storage resources in data centers), or a hypervisor (the software layer that manages interactions between each VM and the hardware).
Availability and cloud foundations
Virtualization improves availability by making workloads easier to restart, move, replicate, and provision on surviving capacity. Examples include adding virtual resources without rebooting when supported, migrating a workload between hosts, and replicating the files that make up a server to a secondary site. Running new application workloads on existing virtual infrastructure is a cost and hardware-refresh benefit (containment), not an availability example. High availability still requires enough shared capacity, functioning storage and networking, monitoring, and recovery testing.
Cloud computing builds on this model: a data center becomes a self-managing, highly scalable, highly available pool of resources that users can consume without assembling a physical server for every application. Virtualized resources in a cloud are highly scalable (they scale up or down with workload), highly available (continuous performance without failure), and self-managing. Virtualization is the engine that turns a data center into this pool.
Lesson 1 terms to know
virtualization, virtual machine, host, guest, VMM, hypervisor, consolidation, containment, converged infrastructure, thin client, consolidation ratio, virtual appliance, virtualization-first policy, fidelity, isolation, and performance.
Lesson 2 — Understanding Hypervisors
What a hypervisor does
A hypervisor is the software that provides the environment in which virtual machines operate. It acts as the control layer and interface between the physical hardware devices on a server and the virtual devices of each VM, and it decouples the guest OS from the hardware when resources are requested. It:
- presents virtual CPUs, memory, disks, network adapters, firmware, and other devices;
- schedules competing requests on finite physical resources;
- isolates guests from one another;
- mediates access to storage, networks, and devices; and
- may support clustering, migration, monitoring, and high availability.
The management console is not necessarily the hypervisor. The console configures the platform; the hypervisor performs the low-level scheduling, mapping, and enforcement.
Without a hypervisor, more than one guest OS would try to control the hardware at the same time, because each OS would communicate directly with the hardware and memory calls would go straight to physical memory. The hypervisor prevents this by allocating resources on the server, letting virtual networks carry traffic between workloads, and automating VM operations.
Type 1 versus Type 2
| Feature | Type 1 / bare-metal | Type 2 / hosted |
|---|---|---|
| Location | Runs directly on the server platform | Runs as an application inside a host OS |
| Dependency chain | Hardware → hypervisor → VMs | Hardware → host OS → hypervisor → VMs |
| Strength | Fewer software layers, strong isolation and efficiency | Easier installation and broad use of host OS drivers |
| Common use | Dedicated servers, production, clusters | Desktops, development, testing, and student labs |
| Examples | Microsoft Hyper-V, VMware ESX/ESXi, Xen | VMware Workstation/Player, VirtualBox, Microsoft Virtual Server |
Type 1 is more efficient than Type 2 because it has no host OS layer. In a Type 2 design the hypervisor passes I/O requests to the host OS, which passes the result back to the hypervisor and then to the guest, adding two extra steps. A Type 1 hypervisor is also less exposed to a misbehaving guest and has fewer points of failure, while Type 2 supports a wide range of hardware because it borrows the host OS drivers. There are only two classes of hypervisor, Type 1 (bare-metal) and Type 2 (hosted); “Tier 1” and “Type 3” are not hypervisor classes.
Type 1 does not mean that no management partition exists. Hyper-V, for example, uses a parent or root partition for drivers and management while retaining a Type 1 architecture. In Xen, Dom0 is the privileged management domain with hardware access; DomU domains are ordinary guest domains.
Resource management
A vCPU is a processor context presented to a guest; it is not automatically a dedicated physical core. The hypervisor schedules vCPUs on available physical CPUs. Likewise, configured guest memory is mapped to physical memory and may be affected by host pressure, sharing, ballooning, or swapping. Assign resources from measured demand and leave capacity for hypervisor overhead and workload spikes.
Virtual devices can be emulated for compatibility, exposed through guest-aware paravirtualized drivers for lower overhead, or assigned more directly for performance. Greater direct access can reduce portability, sharing, and migration flexibility.
Platform examples
- VMware ESX/ESXi: enterprise Type 1 platform. ESX has a service console; ESXi has no service console. ESX features include transparent page sharing, memory ballooning, fault tolerance, and high availability. A privileged domain is a Xen feature, not an ESX feature.
- Microsoft Hyper-V: Type 1 design with a Windows parent partition and child partitions.
- Xen: Dom0 (Domain 0) is the special privileged guest with direct access to the hardware and I/O support; DomU domains are the ordinary guests.
- KVM: virtualization integrated into the Linux kernel.
- VirtualBox, VMware Workstation, and VMware Fusion: common desktop or lab hypervisors.
- OpenStack: a cloud management platform that can coordinate virtualization resources; it is not itself the same thing as a hypervisor.
- OS-level partitioning: HP-UX Containers is the course example of a solution that carves a single OS-specific environment into multiple secure environments.
Lesson 2 terms to know
hypervisor, VMM, Popek and Goldberg, Type 1, bare-metal, Type 2, hosted, guest, Dom0, DomU, service console, transparent page sharing, parent partition, child partition, vCPU, pCPU, emulation, paravirtualization, ballooning, and high availability.
Lesson 3 — Understanding Virtual Machines
VM anatomy
A VM is a set of data files and metadata that instantiates a software-defined computer. It includes:
- a configuration file describing identity, firmware, virtual hardware, and resource settings;
- virtual disks containing the guest operating system, applications, and data;
- virtual processors, memory, controllers, network adapters, and other devices; and
- runtime or power state when the VM is running, paused, or suspended.
The configuration file matters as much as the virtual disk. Copying only a disk may omit firmware mode, controller type, network identity, or device mappings.
Common VM files:
| File | What it holds |
|---|---|
| Configuration | Describes the resources the VM can use: memory, storage, networking, and the other virtual hardware |
| Virtual disk | Stores the contents of the VM hard disk drive |
| Redo-log | Saves changes made to a virtual disk while the VM is running |
| Delta disk | Accumulates all changes made to the VM until the snapshot process ends |
| Centralized | Holds information and metadata about snapshots |
How virtual resources map to hardware
- A vCPU is scheduled on a physical CPU by the hypervisor.
- Guest memory is mapped to physical memory while the hypervisor enforces isolation.
- A vNIC gives the guest a familiar network adapter and connects it to the virtual switch. A virtual switch is the component of the virtual network to which vNICs connect. The virtual network connects to the physical NICs and is the tool for creating secure environments for VMs that share a host.
- A guest virtual disk maps through the hypervisor to a file, volume, SAN, or other backing storage.
- Two VMs on one host may communicate without traffic reaching a physical switch.
Privilege rings and how a request reaches hardware
The x86 architecture defines four privilege rings:
| Ring | Trust level | What runs there |
|---|---|---|
| Ring 0 | Most privileged | The OS kernel, privileged instructions that change the hardware state of the processor, and the hypervisor |
| Ring 1 and Ring 2 | Intermediate (rarely used in practice) | Device drivers |
| Ring 3 | Least trusted | Applications |
An application in Ring 3 cannot touch hardware directly; it asks the operating system, which does the privileged work in Ring 0. For example, a C program that wants data from a file calls a library function such as fgets() (fopen() only opens the file). In a virtual environment the hypervisor sits between the guest OS and the hardware, so it decouples the OS from the hardware when resources are requested.
Clone, template, snapshot, and OVF/OVA
- Clone: another VM identity copied from an existing VM. A clone should receive a unique name, address, identifiers, certificates, and application identity.
- Template: a maintained, normally nonrunning baseline used as a mold for repeatable VM deployment. A template is for standardization, not for running a workload directly.
- Snapshot: a point-in-time state used for short-term rollback around testing or a controlled change. New writes go to delta or child disks. Snapshots can consume storage and affect performance; they are not independent backups.
- Snapshot consolidation: consolidating after a snapshot ends the snapshot process. New changes no longer go to the delta disk; instead the delta disk changes are merged into the base VM files and become the updated VM. Taking another snapshot creates another delta disk. Do not confuse this with server consolidation in Lesson 1.
- OVF: a vendor-neutral, cross-platform standard for exchanging virtual systems, such as exporting a VM from a Xen-based system so it can be imported into VMware. It supports two packaging methods: many files that represent the VM, or a single file.
- OVA: the single-file form of OVF (Open Virtual Application or Appliance), stored as a TAR archive (not ZIP or RAR), containing an OVF package and its referenced files.
Use a clone when another independent copy is needed, a template when many standardized VMs are needed, a snapshot for a short rollback point, and OVF/OVA when a VM must be packaged for exchange.
The key difference between a clone and a template is running state: a clone is in a running state, while a template is not and must be converted back into a VM to be changed. Cloning and deploying from a template take a similar amount of time, both require a unique identity to be applied to the new VM, and both produce fully configured virtual servers.
Containers
A VM packages a complete guest operating system and provides a virtual hardware boundary. A container packages an application and its dependencies while sharing the host operating system kernel. Containers usually have lower overhead and start faster, but they do not provide the same independent guest-kernel boundary as VMs. Containers are not simply lightweight VMs. A container abstracts at the operating-system level (a VM abstracts at the hardware level), all workloads in a container must run the same OS or kernel, and a container offers a platform-independent package for deploying applications, with lower overhead and faster deployment than a VM. A hypervisor can run different operating systems side by side; a container host cannot.
Lesson 3 terms to know
configuration, virtual disk, redo-log, vCPU, vNIC, virtual switch, virtual network, privilege ring, snapshot, delta disk, clone, template, OVF, OVA, container, host, guest, NIC, iSCSI, and NFS.
Lesson 4 — Creating a Virtual Machine
Consolidation, containment, and P2V
Physical-to-virtual (P2V) conversion turns an existing physical server into a VM. It is commonly used for consolidation. New VM creation is commonly used for containment, development, testing, or a new service. Consolidation and containment are the two main strategies data center administrators use for virtualization; clustering (which supports high availability) and cloud computing are not those two strategies.
Before converting, inventory services, dependencies, databases, shares, DNS, certificates, licenses, hardware dongles, unusual controllers, drivers, firmware, storage, network settings, and recovery requirements. Decide how much downtime is acceptable and define validation and rollback criteria.
Hot and cold conversion
- Hot conversion or cloning: the source remains running. It reduces downtime but can copy data while it is changing, creating consistency concerns for databases and other write-intensive workloads.
- Cold conversion or cloning: the source is shut down. It improves consistency but requires an outage.
Both methods are P2V conversion processes. The choice is driven by data consistency and downtime requirements, not by the application’s power mode or by a desire to avoid planning.
P2V workflow
- Determine the source workload’s actual CPU, memory, disk, network, and service requirements.
- Create a VM with a correct and supportable configuration.
- Copy data from the source server to the target VM.
- Run post-conversion cleanup and configuration work (after the data is copied, not before), including removing obsolete physical drivers, adapting firmware and network settings, installing supported guest tools, and right-sizing resources. Make manual adjustments to the configuration if required.
- Validate application function, performance, security, monitoring, backup, restore, and recovery.
The converted VM inherits the source’s history. Old drivers, stale identities, unnecessary services, and incorrect hardware assumptions must be reviewed. A clean rebuild can be safer than a direct conversion when the source is obsolete, compromised, or poorly understood.
Creating a desktop VM
Desktop Type 2 products such as VMware Workstation, VMware Player, VMware Fusion, Parallels, and VirtualBox are useful for labs. Host support differs: Oracle VirtualBox runs on Windows, Linux, Mac OS X, and Solaris hosts; VMware Workstation runs on Windows and Linux; VMware Fusion runs on Mac OS X only; and Microsoft Hyper-V runs on Windows client and Windows Server hosts. A typical wizard sequence is to create a new VM, choose the guest operating system and version, name the VM and storage location, set disk capacity, customize hardware, attach installation media, and start the VM.
In VMware Workstation Player, Download a Virtual Appliance lets a user search for specific prebuilt VMs; the other main choices create a new VM, open a VM, or change Player Preferences. In the Help menu, Support links to the online discussion areas through Online Community and lets users suggest features through Request a Product Feature. Help Topics and Online Documentation open user guides in a browser, and Hints toggles hints.
Allocate CPU, memory, disk, and network resources from the guest’s actual requirements and the host’s available capacity. More resources are not automatically better: over-allocation can starve the host and increase contention. The best practice for memory management and processor utilization is to create every new VM with one vCPU and add more only if required; usually one vCPU is more than enough. Start small and add resources later rather than starting with a large VM (or one sized to match the physical server) and subtracting resources afterward. Virtual machine configuration files can be edited as text in some products, but a syntax error can prevent the VM from booting.
Lesson 4 terms to know
P2V, physical-to-virtual, consolidation, containment, hot cloning, cold cloning, right-size, one vCPU, VMware Workstation Player, guest tools, source server, target VM, and virtual appliance.
Course Notes