Virtualization and Hypervisors

Why virtualize?

Virtualization is creating a software version of something physical: a computer, a disk, a network switch. Most often it means running several virtual computers, virtual machines (VMs), on one physical computer, each believing it has a machine to itself.

Before virtualization, the rule in many server rooms was one application per server, so that a crash or an update of one application could not affect another. The result was rows of servers that were busy perhaps 10 to 15 percent of the time, each using power, cooling, rack space and a support contract. Virtualization fixes this with three gains:

• Utilization. Ten lightly used servers become ten virtual machines on one or two physical hosts. Fewer machines means less hardware, power and space.
• Isolation. Each virtual machine still has its own operating system, memory and disks. A crash, a bad update or malware in one VM does not directly affect the others.
• Flexibility. A VM is a set of files plus a configuration. It can be created in minutes, copied, moved to another host while running (VMware calls this vMotion, Hyper-V live migration), and deleted when it is no longer needed.

Those same properties are what made cloud computing possible: a provider can sell slices of large servers to many customers, safely and on demand. See What Is Cloud Computing?

The hypervisor

A hypervisor, also called a virtual machine monitor (VMM), is the software that creates and runs virtual machines. It divides the physical processor (CPU) time, memory, storage and network among the VMs, and keeps them isolated from one another. The physical computer is the host; each virtual machine is a guest. Hypervisors come in two types, depending on what they run on.

Type 1: bare-metal

A type 1 hypervisor runs directly on the host's hardware rather than as an application on top of an operating system (KVM does this by making the Linux kernel itself the hypervisor). It is small, fast and has little to attack, which is why data centers and cloud providers use it. Examples:

• VMware ESXi, managed with vCenter, long the standard in corporate data centers.
• Microsoft Hyper-V, in Windows Server and in Windows 10/11 Pro, Enterprise and Education. When Hyper-V is enabled, the hypervisor starts first and Windows itself runs on top of it in a privileged partition, so even on a laptop Hyper-V is type 1.
• KVM (Kernel-based Virtual Machine), a module in the Linux kernel that turns Linux into a hypervisor. Proxmox VE and many clouds are built on it.
• Xen, an open-source hypervisor that ran the early years of Amazon Elastic Compute Cloud (EC2) and is still used in XenServer, XCP-ng and others.

Type 2: hosted

A type 2 hypervisor is an application that runs on a normal operating system, such as Windows, macOS or a Linux desktop. Guest instructions still run directly on the processor (with the hardware support described below), but the VM's disk, network and display access goes through the host operating system, and the VM competes with host programs for CPU time, which costs some performance. It is easy to install next to your other programs. It suits desktops and laptops: trying a new operating system, running an old application, or building a test lab. Examples are Oracle VirtualBox, VMware Workstation (Windows and Linux) and VMware Fusion or Parallels Desktop (macOS).

Virtual machines

A virtual machine (VM) is a complete computer made of software: it has virtual processors, memory, disks and network cards, boots from virtual firmware, and runs an ordinary operating system. On the host, a VM is mostly a handful of files: a configuration file and one or more virtual disk files.

Virtual hardware

• vCPU (virtual CPU). Each vCPU is a thread the hypervisor schedules onto one of the host's logical processors. A VM with 4 vCPUs can use at most four logical processors at the same moment.
• RAM (random access memory). The amount of memory the guest sees. The hypervisor maps it onto the host's physical memory.
• Virtual disks. Files on the host's storage that the guest sees as a whole disk, in formats such as VMDK (VMware), VHDX (Hyper-V) and qcow2 (KVM). A thin-provisioned disk grows as data is written; a thick-provisioned disk reserves its full size immediately.
• Virtual network interface cards (NICs). Each VM gets one or more virtual NICs with their own media access control (MAC) addresses, plugged into a virtual switch inside the hypervisor. The virtual switch connects VMs to each other and, through the host's physical NICs, to the real network, and it can carry virtual LAN (VLAN) tags just like a physical switch (see Network Devices).

Desktop hypervisors offer a few standard network modes. NAT (network address translation) hides the VM behind the host's address, which is the easy default for internet access. Bridged puts the VM directly on the physical network with its own address from the network's Dynamic Host Configuration Protocol (DHCP) server, as if it were another computer on the local area network (LAN). Host-only or internal networks connect VMs only to the host or to each other, which is ideal for isolated labs. Hyper-V calls its versions external, internal and private virtual switches, plus a built-in Default Switch for NAT.

Guest and host

The guest operating system is the operating system installed inside a VM; the host is the physical machine (and, with a type 2 hypervisor, the operating system running on it). Guest and host do not have to match: a Windows host can run Linux guests and the other way round, as long as the guest is built for the same processor architecture (an x86-64 host runs x86-64 guests; running ARM software on x86 needs slow emulation instead). Every guest needs its own license, its own updates and its own security care, exactly like a physical computer.

Hypervisors provide guest drivers, such as VMware Tools, VirtualBox Guest Additions or the virtio drivers for KVM, that make virtual disks and NICs much faster and add conveniences like a shared clipboard and clean shutdown from the host. Install them in every guest.

Snapshots, clones and templates

Snapshots

A snapshot records the state of a VM at one moment: its disks and, optionally, its memory. From then on, the hypervisor writes changes to a separate delta file instead of the original disk, so reverting simply discards the delta. Hyper-V calls snapshots checkpoints. They are ideal before a risky change: take a snapshot, install the update, and roll back in seconds if it goes wrong.

Clones and templates

A clone is a copy of a VM. A full clone is independent; a linked clone shares the original's disk and stores only its own changes, which saves space but ties the two together. A template is a prepared "golden" VM (operating system installed, updated and configured) that is never started itself and is used only to create new VMs quickly and consistently.

Clones start as exact copies, including identifiers that should be unique on a network: the computer name, and on Windows the security identifier and domain membership. Prepare a Windows template with Sysprep (the /generalize option) before cloning it; on Linux, reset the machine ID and Secure Shell (SSH) host keys. Cloud machine images follow the same idea; see Compute in the Cloud.

Host requirements

CPU virtualization extensions

Modern hypervisors need help from the processor. Intel calls its extensions VT-x (Virtualization Technology) and AMD calls them AMD-V (shown as SVM, Secure Virtual Machine, in many firmware menus). They are present in almost every current desktop and server CPU, but are often disabled in the firmware by default. If a hypervisor refuses to start a 64-bit VM, or Hyper-V cannot be enabled, the first thing to check is this setting in the firmware setup (BIOS or UEFI, the Unified Extensible Firmware Interface; see BIOS, UEFI and Boot).

On Windows, Task Manager shows the state under Performance, CPU ("Virtualization: Enabled"). On Linux, lscpu reports it:

$ lscpu | grep -i virtualization

Virtualization:                       VT-x

A second extension, second level address translation (SLAT), lets the processor translate guest memory addresses to host memory addresses in hardware instead of in software. Intel calls it Extended Page Tables (EPT) and AMD Rapid Virtualization Indexing (RVI). Every recent CPU has it; Hyper-V on Windows requires it.

RAM, storage and network

• RAM is usually the first limit. The host needs enough for itself plus every running guest: a laptop with 16 GB that runs Windows and two VMs of 4 GB each has little left over.
• Storage. Each VM needs room for its virtual disks and snapshots. Several VMs reading and writing at once need fast storage; a solid-state drive (SSD) makes a far larger difference than a faster CPU.
• Network. All guests share the host's physical NICs, so a busy virtualization host has several fast NICs, often in a team for redundancy.

Overcommitment and VM sprawl

Resource overcommitment

Most VMs are idle most of the time, so hypervisors let you assign more virtual resources than physically exist. This is overcommitment, expressed as a ratio. Four vCPUs per physical core (4:1) is a common starting point for general office and web workloads; demanding databases may get 1:1. Memory is overcommitted far more cautiously: when guests really use more RAM than the host has, the hypervisor must reclaim memory (with a balloon driver inside the guest, page sharing or swapping to disk) and every VM on the host slows down. When CPU is overcommitted too far, VMs wait for a free processor; VMware shows this as "CPU ready" time.

The example estimates how many identical VMs fit on one host for three combinations of ratios. The numbers are illustrative sizing, not vendor guidance.

HOST_CORES = 32          # physical CPU cores
HOST_RAM_GIB = 512
RESERVED_RAM_GIB = 16    # kept free for the hypervisor itself

VM_VCPUS = 4             # every VM gets 4 vCPUs and 16 GiB of RAM
VM_RAM_GIB = 16


def vms_that_fit(cpu_ratio, ram_ratio):
    by_cpu = int(HOST_CORES * cpu_ratio // VM_VCPUS)
    by_ram = int((HOST_RAM_GIB - RESERVED_RAM_GIB) * ram_ratio // VM_RAM_GIB)
    return by_cpu, by_ram


for cpu_ratio, ram_ratio in [(1, 1), (4, 1), (4, 1.25)]:
    by_cpu, by_ram = vms_that_fit(cpu_ratio, ram_ratio)
    limit = "CPU" if by_cpu < by_ram else "RAM"
    print(
        f"vCPU {cpu_ratio:g}:1, RAM {ram_ratio:g}:1 -> "
        f"{min(by_cpu, by_ram)} VMs (CPU allows {by_cpu}, RAM allows {by_ram}; "
        f"limited by {limit})"
    )

vCPU 1:1, RAM 1:1 -> 8 VMs (CPU allows 8, RAM allows 31; limited by CPU)
vCPU 4:1, RAM 1:1 -> 31 VMs (CPU allows 32, RAM allows 31; limited by RAM)
vCPU 4:1, RAM 1.25:1 -> 32 VMs (CPU allows 32, RAM allows 38; limited by CPU)

Without overcommitment the host is full at 8 VMs while most of its memory sits unused; with a 4:1 CPU ratio, memory becomes the limit. Real sizing also keeps headroom so that the VMs of a failed host can restart on the remaining hosts of a cluster.

VM sprawl

Because VMs are so easy to create, organizations accumulate them: test machines nobody deleted, copies made "just in case", servers whose owner left. This VM sprawl wastes capacity and licenses, and forgotten VMs miss updates and become security risks. The cure is administrative: record an owner and purpose for every VM, give test VMs an expiry date, and review the inventory regularly. In the cloud, sprawl shows up directly on the bill; see Cloud Costs and FinOps.

Desktops, sandboxes and labs

Desktop virtualization (VDI)

In virtual desktop infrastructure (VDI), users' desktops run as VMs in a data center, and users connect to them from a laptop, thin client or tablet over a remote display protocol such as the Remote Desktop Protocol (RDP). Data stays in the data center, a lost laptop exposes nothing, and a broken desktop is replaced from a template. The cost is a dependency on the network and on central infrastructure. Cloud versions include Azure Virtual Desktop, Windows 365 and Amazon WorkSpaces. Remote access in general is covered in Remote Access.

Sandboxes and test labs

A VM is a safe place to try things: open a suspicious attachment, test an update before rolling it out, or run software that only works on an old operating system, all isolated from the host. Windows Sandbox (Windows 10/11 Pro, Enterprise and Education, not Home) is a throwaway VM that is wiped when you close it. For learning, a laptop with a type 2 hypervisor and a host-only network is a complete lab: a Windows Server domain controller, a Linux server and a client, without touching the real network.

Virtualization in the cloud

Every cloud virtual server is a VM on a provider's type 1 hypervisor (bare-metal instances, which give you the whole server, are the exception). Amazon EC2 runs on the Amazon Web Services (AWS) Nitro System, whose hypervisor is based on KVM (the earliest EC2 instances used Xen); Azure uses a hypervisor based on Hyper-V; Google Compute Engine uses a hardened version of KVM. You never see the hypervisor: you choose a size (an instance type), an image and a network, and the provider does the rest. See Compute in the Cloud.

Virtual machines are not the only way to isolate workloads. Containers isolate applications while sharing the host's kernel, which makes them lighter and faster to start but less strongly isolated. Many cloud systems combine both: containers running inside VMs.