Understanding Virtual Machines

Lesson purpose

Virtual machines are the containers that run operating systems and applications on a hypervisor. From inside, a VM looks like a physical computer. From outside, it is configuration, virtual disks, runtime state, policies, and shared demand. This lesson teaches students to switch between those two views, trace how virtual hardware maps to physical resources, and select the right lifecycle tool for copying, standardizing, rolling back, or transporting a workload.

Learning objectives

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

• Identify the configuration, virtual devices, disks, and state that make up a VM.
• Explain the inside and outside views of a virtual machine.
• Describe how vCPU, memory, networking, and storage map to host resources.
• Explain why guest integration tools improve device behavior and manageability.
• Distinguish a clone, template, snapshot, backup, and OVF or OVA package.
• Compare the machine boundary of a VM with the shared-kernel model of containers.

1. VM anatomy

A VM is a set of data files and metadata that instantiate a software-defined computer. The configuration records identity, firmware, capacity, device choices, and platform settings. Virtual hardware gives the guest logical processors, memory, controllers, disks, and adapters. Virtual disks hold the guest operating system, applications, and data. Execution state describes whether the VM is powered off, running, paused, or suspended and whether runtime memory is being preserved.

The configuration file matters as much as the disk. Copying only a virtual disk may omit firmware mode, controller type, network identity, or device mappings needed to recreate the workload. Adding memory changes the VM’s configuration. Starting the VM changes its runtime state. Students should avoid treating “the VM” as a single file or as the operating system image alone.

2. Inside and outside views

From inside the guest, the operating system sees processors, RAM, storage, network interfaces, firmware, and device drivers. Applications use ordinary system calls and services. This is the fidelity property from the first lesson.

From outside, an administrator sees VM files, metadata, power state, snapshots, mappings, quotas, datastore latency, host contention, and neighboring workloads. A guest can show free disk space while the backing datastore is nearly full. A guest can show low CPU usage while the host scheduler is delaying it. Switching views is an essential troubleshooting skill.

Standard virtual devices make movement easier because the guest depends less on the exact physical components in one server. Portability still has limits. A platform-specific virtual switch, firmware feature, direct-assigned device, or integration service may not map perfectly to another product.

3. Virtual resources

Virtual processors

The guest detects configured vCPUs. The hypervisor schedules them on physical processor resources over time. Assign enough vCPUs for the workload’s parallel demand, but do not use maximum settings as a default. A two-vCPU VM may run on different physical cores while the guest remains unaware of the placement. Validate the choice with utilization, latency, and scheduler metrics.

Virtual memory

The guest reports its configured RAM. The hypervisor maps guest pages to physical memory and enforces isolation. Configured, consumed, reserved, and resident memory are different values. Host pressure can degrade a VM even when the guest believes it has enough memory. Ask students which host and guest metrics they would compare before adding RAM.

Virtual networking

A vNIC gives the guest a familiar adapter, address, and driver. A virtual switch forwards traffic among guests and toward physical uplinks. NAT, bridged, host-only, and internal or isolated modes change reachability. Two VMs on one host may communicate without traffic reaching the physical switch. Because traffic can stay inside the host, physical network tools may not reveal every path. A working vNIC does not prove DNS, routing, firewall, VLAN, or uplink correctness.

Virtual storage

The guest sees partitions, file systems, and drive devices. A file, volume, or managed disk stores the actual blocks. Fixed disks commit backing capacity earlier. Dynamically allocated disks consume space as data grows toward the configured limit. Many thin disks can grow together and fill a datastore. Separate virtual disks can still compete for the same physical queues, controllers, and storage network.

Guest integration

Guest-aware tools and drivers can reduce emulation overhead and improve display, input, time synchronization, clean shutdown, status reporting, and other device behavior. These tools are software that must be patched and supported. Features such as shared clipboard or folders can also weaken isolation, so enable them only when the lab requires them.

4. Power states and lifecycle tools

Power state changes what is preserved. A powered-off VM keeps configuration and disks but no active guest execution. A running VM consumes CPU, memory, and I/O. A paused VM stops execution while memory remains allocated. A saved or suspended VM writes runtime state so it can resume later. Before changing fundamental virtual hardware, a clean shutdown is usually safer than a pause or saved state.

The lifecycle tools solve different problems:

• Clone: create another VM identity from an existing VM. A full clone copies configuration and disks; a linked clone may share a base and store differences. Review hostnames, addresses, identifiers, certificates, and application state after cloning.
• Template: maintain a nonrunning baseline for repeatable deployment. Customization should create unique identity and environment settings. Patching the template is part of maintenance because standardization reproduces both good configuration and hidden mistakes.
• Snapshot: capture a point in the VM timeline for short-term rollback around a controlled change. Delta chains can consume storage and affect performance. A snapshot is not an independent backup because a datastore failure can destroy the base and the snapshot together.
• OVF or OVA: package a virtual system for exchange. OVF metadata describes virtual hardware, disks, networks, and product information. An OVA is a single archive that bundles the package. Import still requires compatibility checks because vendor-specific features may not transfer perfectly.

Containers are related but different. A VM packages a complete guest operating system and presents virtual hardware. A container packages an application and dependencies while sharing the host kernel. Containers typically start faster, while VMs can run a different guest kernel and provide a stronger machine boundary. They should not be taught as lightweight VMs.

Classroom application

Ask students to choose the correct mechanism for each goal:

1. Twenty lab systems need one maintained baseline: template.
2. A risky update needs a short rollback point: snapshot.
3. A training appliance must move between supporting platforms: OVF or OVA.
4. A second independent lab system is needed: clone.

Next, have students draw a guest read from C: through the virtual disk, hypervisor mapping, backing storage, and returned result. Finally, compare a VM and a container for a legacy application that needs its own kernel versus a modern service that can share the host kernel.

Common misconceptions

• A VM is more than its operating-system disk.
• The guest and the operator see different but compatible views of the same workload.
• A configured vCPU is not a permanently owned physical core.
• Logical disk capacity is not the same as consumed physical capacity.
• A clone, template, snapshot, and backup have different purposes.
• Snapshots do not replace tested independent backup and restore.
• OVF improves exchange but cannot guarantee that every vendor-specific feature will import unchanged.
• Containers share a host kernel; they do not provide the same guest-OS boundary as a VM.

Lesson summary

A VM is a software-defined computer made from configuration, virtual hardware, disks, and runtime state. The guest sees a familiar machine; the operator manages mappings, policies, and shared demand. vCPUs, memory, networking, and storage each introduce a different mapping and contention story. Clones, templates, snapshots, and OVF packages solve distinct lifecycle problems. The next lesson applies this model to converting existing workloads and building a new VM deliberately.