Fundamentals of Virtualization · Lessons 5–8

Fundamentals of Virtualization Study Guide: Lessons 5–8

Exam-focused review of Windows and Linux VM installation, CPU virtualization, vCPU sizing, and virtual-memory management.

  • study-guide
  • virtualization
  • windows
  • linux
  • cpu
  • vcpu
  • memory
  • hyper-threading
  • ballooning

How to use this guide

This guide combines the Lessons 5–8 chapter material. It is organized by lesson so you can connect guest operating-system administration to the physical resources and hypervisor features that support it.

Study in this order:

  1. Learn the vocabulary and comparisons in the lesson summaries.
  2. Connect each guest operating-system task to the virtual hardware and host resources beneath it.
  3. Revisit the high-yield distinctions and the final checklist in the lesson summaries without looking at the source notes.

The ideas that connect Lessons 5–8

Installing and managing a guest operating system requires two views at once. The guest sees virtual CPUs, memory, disks, adapters, firmware, and integration services. The host or hypervisor sees the VM configuration, backing resources, contention, and physical capacity shared with other VMs.

The four ideas below connect these lessons:

  • Guest integration: tools and drivers help the guest use virtual hardware correctly and let the hypervisor exchange status and control information with the guest.
  • Measured configuration: CPU, memory, disk, and network settings should be based on workload requirements and observed behavior rather than maximum possible values.
  • Resource contention: a VM can appear to have resources assigned while still waiting for physical CPU, memory, storage, or network capacity on the host.
  • Safe optimization: changes should be workload-specific, tested, documented, and reversible. A lower utilization number is not automatically an improvement.

Lesson 5 — Installing Windows on a Virtual Machine

Installation media and boot devices

An ISO image is a file containing the contents and structure of optical media. A hypervisor can present an ISO through the VM’s virtual CD/DVD drive so the VM can boot from it. When a VM is powered off and has no operating system, it needs an ISO image to boot from. Always verify the source, edition, architecture, license, and integrity of the image.

The VM installs Windows to a virtual disk, not directly to the host’s entire physical disk. After the first reboot, disconnect or eject the ISO when appropriate; otherwise the VM may boot into the installer again.

For a new VM, a custom installation gives the administrator control over the target virtual disk and partitioning. Express settings are convenient defaults that streamline the configuration process, while Custom settings let the administrator review and customize all of the settings.

Guest integration and inspection

VMware Tools, VirtualBox Guest Additions, and comparable packages provide guest-aware drivers and services. Common benefits include better display and mouse behavior, virtual storage and network drivers, time synchronization, clean shutdown support, and improved management visibility. They are not the guest operating system and do not replace patching or security controls.

Inspect a VM from two perspectives:

  • Inside the guest: the guest sees assigned vCPUs, RAM, virtual disks, adapters, firmware, drivers, and services.
  • At the host or hypervisor: the administrator sees the VM configuration, backing files, power state, host contention, and physical capacity shared with other VMs.

Useful clues that a system is virtual include virtual device names, guest-tool services, system information, firmware details, and hypervisor management data. No single clue is absolute proof.

Three ways to tell whether a system is physical or virtual: (1) match the devices on the system against physical vendor hardware, since a match means the system is physical and otherwise it is virtual; (2) open the Properties window of a device and read the devices listed on the Hardware tab, since a physical computer shows only physical devices; and (3) compare the size of the C: drive, since a physical C: drive is considerably larger than a virtual one. A VM logo is not a reliable test: it only shows that VMware Tools is installed, which is recommended but not mandatory, so its absence does not prove the machine is physical.

Safe reconfiguration and optimization

Configured memory is the amount assigned to the VM; consumed or resident memory is the amount currently backed by host resources. Hot-add permits a supported resource to be added while the VM remains powered on. Reducing resources commonly requires a shutdown and reboot, and both the hypervisor and guest must support the operation.

The preferred practice when moving a physical workload to a VM is to allocate enough resources to the VM to give equal or better performance than the physical server. Extra I/O bandwidth, network tuning, and personalization are not the primary practice; personalization in particular uses extra CPU cycles and disk space.

Windows VM optimization is workload-specific. First identify the VM’s role and capture a baseline. Then disable only unnecessary services or features, patch the guest and guest tools, test application and recovery functions, and document the change. Wireless networking services, desktop power-management behavior, wallpapers, screen savers, and visual effects may be unnecessary in some server workloads, but never disable a component without checking its dependencies. In the course’s list, wireless networking, power management, and personalization are the features to disable in a VM: the physical hardware usually has no wireless network in the virtual environment, power management does not apply to a VM, and personalized settings consume disk, CPU, and memory. Storage management should stay enabled: it is a service that optimizes the virtual environment, and disabling it fixes the VM to a set amount of resources so more cannot be added when required.

Lesson 5 terms to know

ISO image, virtual CD/DVD drive, Express settings, Custom settings, guest integration tools, VM logo, configured memory, consumed memory, resident memory, hot-add, and baseline.

Lesson 6 — Installing Linux on a Virtual Machine

Linux and VirtualBox

Linux is common in server and cloud environments because of its broad hardware support, open-source ecosystem, distribution choices, and compatibility with cloud, automation, database, and container platforms. Open source does not mean that administration, security updates, support, or lifecycle planning are unnecessary.

VirtualBox is a Type 2 hypervisor: it runs as an application inside a host operating system. Because it is a Type 2 hypervisor installed on top of a host OS, it can be installed on machines running Windows, Linux, Mac OS X, and Solaris; being open source or used for testing and development is not the reason. A typical lab VM includes a virtual CPU, assigned memory, a virtual disk, and a trusted Ubuntu ISO connected to the virtual optical drive.

With dynamically allocated storage, the virtual disk can have a maximum capacity larger than its current physical consumption. It grows as the guest writes data, which saves space initially but can eventually fill the host datastore.

In the VirtualBox Manager, Preferences controls how VirtualBox interacts with the physical environment. Virtual Media Manager manages virtual disk and media images, and Import Appliance brings in a packaged VM; neither is the selection for interaction with the physical environment.

Guest Additions, packages, and daemons

VirtualBox Guest Additions provide drivers and services for display, mouse integration, time synchronization, shared folders, clipboard behavior, and status reporting. Linux may require superuser privileges to install drivers and system services. Shared folders and clipboard features cross the isolation boundary, so enable them deliberately.

A package contains an application suite or a set of installable functionality. A daemon is a background service; the term is especially associated with Linux/Unix systems. Optimize a Linux VM by inventorying services, disabling or removing only unneeded daemons and packages, applying updates, and documenting changes. Disabling some daemons is a common practice when building production VMs (daemons are processes that start automatically as part of OS boot). Installing only the packages a VM needs saves storage and reduces CPU and memory use. Do not disable every service: networking, storage, security, management, and the workload itself may depend on them.

Time and observation

The Network Time Protocol (NTP) synchronizes systems with trusted time sources. To keep time synchronized on all the Linux VMs on a host, use an NTP server: it provides a steady, reliable time source when a system CPU is slightly off or tends to drift out of sync. Setting a computer clock by hand at intervals is not reliable or efficient. Reliable time matters for logs, authentication, certificates, transactions, scheduled jobs, databases, and clusters. Verify the guest clock, host clock, configured time source, synchronization status, and logs.

The guest sees only its assigned virtual hardware. Use process, resource, file-system, and network observations to build a baseline. A low CPU percentage alone does not prove that the VM is healthy; memory pressure, disk latency, DNS, routing, firewall behavior, or application dependencies may be the actual bottleneck.

Lesson 6 terms to know

Linux distribution, Type 2 hypervisor, dynamically allocated disk, package, application suite, daemon, Guest Additions, NTP, and VirtualBox Preferences.

Lesson 7 — Managing CPUs for a Virtual Machine

CPU virtualization and terminology

The hypervisor usually does not emulate every instruction as a different processor. Instead, it schedules guest work on available physical resources. Virtualizing a CPU therefore means scheduling workloads on an available physical CPU: the hypervisor schedules slices of time on the physical host CPUs to run the virtual instructions. Emulating a physical CPU would cause poor performance and scalability problems.

Four resources are used to configure a virtual server and determine its performance: CPU, memory, network I/O, and storage I/O. Power I/O is not one of them. A vCPU is a virtual processor context presented to the guest; it is not automatically a dedicated physical core.

Use these terms precisely:

Term Meaning
Physical CPU or socket Processor package installed in the server
Core Individual processing unit inside a package
pCPU Schedulable physical processing resource
vCPU Virtual processor context presented to a guest
Logical processor Schedulable hardware thread, such as one exposed by hyper-threading

The hypervisor can run a VM’s vCPU on different physical cores over time. This mobility enables consolidation, but a busy host can delay a VM even when the guest sees a familiar processor.

The processors inside a CPU package are called cores. Operating systems can limit the number of physical processors: Windows XP Professional supports a maximum of two physical processors but takes advantage of multicore processors. To let it use four CPUs, create a VM with two dual-core vCPUs; a VM with four single-core vCPUs would use only two of them.

Right-sizing and contention

Start with the smallest supported vCPU count that meets the application’s requirements. Measure utilization, scheduling delay, latency, and application response before adding capacity. On a host with an equal number of physical CPUs available, a single-vCPU VM is scheduled sooner than a multi-vCPU VM because it needs to hold only one physical CPU at a time. VMware ESXi supports up to 32 vCPUs per physical core. More vCPUs are not automatically better: a multi-vCPU VM may wait longer on a busy host because the scheduler must find more capacity, and the application may not use the extra parallelism.

Hot-add may allow additional vCPUs while a VM is powered on. Hot-remove is less commonly supported, so reducing vCPUs often requires a shutdown and reboot. Windows supports hot-add, live migration, and hyper-threading but not hot-remove: to reduce the CPUs in a Windows VM, shut it down, change the number of CPUs, and restart it. Current hypervisor and guest documentation controls the actual limit.

Hyper-threading and migration

Intel hyper-threading exposes two logical processors per physical core. It improves parallel operations in each core by making it appear as two logical cores; do not confuse it with QuickPath Interconnect, Turbo Boost, or Tri-Gate (3D) transistors, which are different Intel technologies. For hyper-threading to work, the processor must be an Intel microprocessor capable of hyper-threading, the OS must support multiple processors, and the OS must support hyper-threading. It can improve utilization when the workload and platform support it, but it does not create a second full physical core or guarantee a 2× performance increase.

Live migration requires compatible CPU features. A VM can generally migrate while running within an Intel-compatible cluster or an AMD-compatible cluster. Moving between Intel and AMD hosts may require powering off the VM before restarting it on the other host. The steps to move a VM between an AMD host and an Intel host, in either direction, are to shut down the VM and then restart it on the second host with the different chipset; cloning and pre-cleanup are not part of those steps. The course’s term for migrating a running VM from one physical server to another without interrupting its application is clustering. Check the hypervisor’s compatibility matrix, firmware settings, feature baselines, and guest limits.

Lesson 7 terms to know

vCPU, pCPU, physical CPU, core, logical processor, CPU contention, hyper-threading, hot-add, live migration, and clustering.

Lesson 8 — Managing Memory for a Virtual Machine

Pages, paging, and memory size

RAM is the fast workspace for active operating-system code, applications, and data. Operating systems divide memory into blocks called pages. The usual page size is 4 KB, although supported sizes depend on the architecture and operating system.

When RAM is full, less recently used pages can be written to disk. This is paging; the disk area used is commonly called swap space or a page file. Paging is expensive because disk I/O is much slower than RAM. Specifically, paging copies memory pages to disk, and working with disk storage is much slower than working with memory; paging can run in parallel with other processes, so it does not make them idle. Sustained paging or hypervisor swapping is a warning that the workload, VM configuration, or host capacity needs attention.

Keep these measurements distinct:

  • Allocated/configured memory: what the VM is told it can use.
  • Consumed or actively used memory: what the guest and hypervisor are using now.
  • Resident memory: what is currently backed by physical RAM.
  • Reserved memory: capacity protected for a VM or platform function.
  • Overhead: memory used by hypervisor code and mapping structures.

The size of a memory block, or page, depends on the processor type and the architecture; it does not depend on the data written to it. Disk storage does not determine the processor’s memory-page size.

Reclamation and overcommitment

Ballooning uses a guest-aware balloon driver. During contention, the hypervisor asks the driver to inflate; the guest identifies less recently used pages and may flush them to its page file or swap area, allowing the hypervisor to reclaim physical pages. Ballooning and paging to a physical disk are the techniques used to reclaim memory from a VM that was given too much. Page sharing saves space by keeping one copy of identical pages but does not reclaim memory for other use, and compression moves pages to a cache rather than to disk.

Memory overcommitment assigns more virtual memory to VMs than the host physically contains, relying on inactive, shared, compressed, or otherwise nonresident pages. It can improve consolidation, but it is not the creation of new memory. A VM using half of its allocated memory has a 2-to-1 overcommitment ratio. The hypervisor does not add memory to VMs; it manages memory across them by using memory from idle VMs or from VMs that use less than they were allocated, which gives a better consolidation ratio. It is safe only when active working sets, reserve policy, alerts, and service-level impact are understood.

Compression stores compressed pages in a reserved physical-memory cache. It usually costs less than disk I/O and can delay swapping during short periods of pressure.

Page sharing and copy-on-write

Page sharing stores one physical copy of identical read-only pages and maps multiple VMs to it. It is analogous to data deduplication. Disk mirroring, copy-on-write, and swap space are different mechanisms. VMware vSphere 6.0 is the course example of a hypervisor that offers page sharing. If a VM attempts to modify a shared page, the hypervisor uses copy-on-write to create a private copy for that VM. This preserves isolation while retaining savings for pages that remain identical.

Swapping is a last-resort action in which the hypervisor writes VM memory pages to disk. It can keep a VM running, but latency can become severe because page faults require storage I/O.

Lesson 8 terms to know

page, paging, swap, page file, ballooning, memory overcommitment, page sharing, data deduplication, copy-on-write, compression, overcommitment ratio, and swapping.