Cloud Parts

Virtual machines

A whole computer, carved out of a bigger physical one.

12 technologies on this page ↓
Live model
What you’re watchingTraffic for three different tenants lands on three VMs that share one physical server. Each VM runs its own operating system and can’t see the others.

How it works

A hypervisor splits one physical server into several isolated machines. Each VM gets its own virtual CPUs, memory and disk, plus a full operating system that you install, patch and secure. To your software it looks exactly like a real server.

Think of it as

Renting a furnished apartment in a big building. The walls are yours to paint, the plumbing is shared, and everything inside your door is your responsibility.

Reach for it when

  • Lifting an existing app off an office server without rewriting it
  • Software that needs a specific OS, kernel module or licensed agent
  • Long-running workloads where you want full control over tuning

Think twice when

  • Spiky traffic: you pay for the machine while it sits idle
  • Small teams that don’t want to own OS patching and hardening

A real example

A company moves its ten-year-old Windows ERP system to the cloud by copying it onto an 8-vCPU VM. Nothing in the app changes; the server just lives in a cloud data center now.

More on virtual machines

Narrower ideas that build on this one.

Technologies

Specific products, and what each does differently.

Also used for virtual machines

Products of other kinds that are often used this way, grouped by what they are.

Hypervisors →

KVM (Kernel-based Virtual Machine)Open sourceThe hypervisor built into the Linux kernel: it runs guest code directly on the CPU through `/dev/kvm`, and leaves device emulation to a user-space program such as QEMU or Firecracker.libvirtOpen sourceA stable API, daemon and `virsh` command line for managing virtual machines, storage and networks, with drivers for QEMU/KVM, Xen, LXC, Cloud Hypervisor, VMware ESX, Hyper-V and more.Microsoft Hyper-VCommercialMicrosoft’s type-1 hypervisor, built into Windows Server and Windows 10 and 11 Pro and Enterprise: a thin hypervisor under a Windows root partition, which also underpins Azure’s hypervisor and Windows features like VBS, WSL 2 and Windows Sandbox.Oracle VirtualBoxOpen sourceOracle’s free, open-source desktop hypervisor: a type-2 hypervisor that runs VMs as an application on Windows, macOS, Linux and Solaris, scriptable with `VBoxManage` and the default provider for Vagrant.Proxmox Virtual EnvironmentOpen sourceA Debian-based server platform from Vienna that runs KVM virtual machines and LXC containers, with clustering, high availability, Ceph and ZFS storage, backups and a web interface in one free ISO.QEMUOpen sourceThe open-source machine emulator and virtualizer: it emulates whole computers in software, or runs them at native speed on a hypervisor such as KVM, and supplies the virtual devices either way.VMware ESXiCommercialVMware’s bare-metal hypervisor (called ESX again since VCF 9), whose own kernel runs VMs directly on servers while vCenter adds vMotion, HA, DRS and vSAN; since Broadcom bought VMware in 2023 it is sold only as per-core subscriptions.Xen Project hypervisorOpen sourceThe open-source type-1 hypervisor from Cambridge that ran the first Amazon EC2 instances: a small microkernel-style core that boots first, with drivers and management in a privileged VM called dom0.

What each provider calls it

AWS
EC2
Google Cloud
Compute Engine
Azure
Virtual Machines
Open source & others
KVM, Proxmox, OpenStack; Vagrant for local dev VMs; Packer to build images; KubeVirt for VMs managed by Kubernetes

In code · bash

# Launch one Ubuntu VM with 2 vCPU / 4 GB
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.medium \
  --key-name my-key \
  --subnet-id subnet-0a1b2c3d

Often confused with

ContainersMicroVMsHypervisorsAutoscalingBlock storageVM, container, microVM or function?
Where it came from1967–2023

Virtual machines began as a way to share one very expensive computer. At IBM’s Cambridge Scientific Center, working alongside MIT, engineers built CP-40 on a specially modified System/360 Model 40. It went into production in January 1967, giving each user a virtual machine that could run its own operating system as if it had the hardware to itself. The design became CP-67 and then IBM’s VM/370 (1972). In 1974 Gerald Popek and Robert Goldberg wrote down the rules: a guest must behave as on real hardware, the monitor must stay in control, and the guest must run at nearly full speed, with most instructions running directly on the CPU.

The PC’s x86 chips broke those rules: some sensitive instructions didn’t trap to the monitor. VMware, founded in 1998 by Stanford’s Mendel Rosenblum, Diane Greene and others, got around this in VMware Workstation (1999) by rewriting problem kernel instructions on the fly. Cambridge University’s Xen (2003) took a different route, modifying the guest OS to call the hypervisor directly. In 2005 Intel and AMD added hardware support (VT-x and AMD-V), and KVM used it to turn Linux itself into a hypervisor.

Virtualization on ordinary x86 servers let one physical machine host many isolated ones, which is the basis of every public cloud: EC2 ran on Xen from 2006, and from 2017 its new instances moved to the Nitro system, whose hypervisor is based on KVM.

Why it’s built this way

Run guest code directly; trap only the sensitive parts
Emulating every instruction would be far too slow. Letting the CPU run ordinary instructions natively and stepping in only for privileged ones is what makes a VM nearly as fast as bare metal.
Binary translation when the hardware won’t help
Since x86 couldn’t trap every sensitive instruction, VMware scanned kernel code and rewrote the problem instructions before they ran, while still running user code directly.
Paravirtualization: let the guest know it’s virtual
Xen changed the guest kernel to make explicit calls to the hypervisor instead of touching hardware, which avoided costly emulation.
Hardware support in the CPU
VT-x and AMD-V gave x86 a proper mode for guests, so a hypervisor no longer needed rewriting tricks. KVM, which turned Linux into a hypervisor, depends on them.

Timeline

  1. 1967

    IBM’s CP-40 goes into production, running virtual machines on one System/360

  2. 1999

    VMware Workstation virtualizes the x86 PC

  3. 2003

    Xen released from the University of Cambridge

  4. 2005

    Intel VT-x and AMD-V add hardware virtualization to x86

  5. 2007

    KVM merged into Linux 2.6.20

  6. 2017

    New EC2 instances move from Xen to the KVM-based Nitro hypervisor

  7. 2023

    Broadcom completes its purchase of VMware

Sources10

Improve this page on GitHub