Home / Glossary / VM (Virtual Machine)
Tech & ITVM (Virtual Machine)
By Sitraka Forler · Lecturer, Durham Business SchoolUpdated 3 October 2026 About this site
A computer simulated in software, with its own operating system, on a physical host.
A virtual machine runs a full guest operating system on virtual hardware, while a hypervisor such as VMware ESXi or Microsoft Hyper-V shares one physical server between many VMs. Infrastructure as a service (IaaS) clouds rent you VMs, so you patch their operating system yourself. Unlike a container, a VM does not share the host kernel (the operating system's core): heavier to run, but more strongly isolated.
The intuition
A virtual machine is a computer made of software. A program called a hypervisor, such as VMware ESXi, Microsoft Hyper-V, KVM on Linux or VirtualBox on a laptop, carves one physical server into several pretend computers, each with its own share of CPU, memory, disk and network. Inside each one, a complete operating system boots and runs as if it had the hardware to itself. From the guest's point of view there is nothing unusual; from the host's point of view it is just another process, which can be started, paused, copied and deleted.
The economics explain why VMs took over data centres and then became the raw material of the cloud. A physical server bought for one application typically idled at 10% utilisation; running ten VMs on it uses the hardware and isolates the applications from each other. A VM can be snapshotted before a risky upgrade and rolled back in seconds, migrated to another host while running, and cloned to make a test copy of production. Every infrastructure-as-a-service offer, from Amazon EC2 to Azure Virtual Machines, is at bottom a hypervisor renting out VMs by the hour.
The comparison people most need is with containers. A container shares the host's kernel and packages only the application and its libraries, so it starts in a second and weighs megabytes; a VM carries a whole operating system, boots in a minute and weighs gigabytes. The price of the container's lightness is weaker isolation: a kernel exploit in a container reaches the host. VMs are the stronger wall, which is why cloud providers put each customer's containers inside VMs, and why a bank's compliance team often insists on a VM boundary between environments.
Cloning a production VM to test a database upgrade, then rolling back
- A fund's position database runs on a Linux VM, db-prod-01, with 4 virtual CPUs, 16 GB of memory and a 200 GB virtual disk, on a VMware host shared with a dozen other VMs. The team must test an upgrade of PostgreSQL from version 14 to 16 without touching production.
- Clone it: in the vSphere console, right-click db-prod-01, choose Clone to Virtual Machine, name it db-test-01 and place it on the isolated test network. The copy takes a few minutes because the 200 GB disk is duplicated. The clone boots with the same operating system, the same data as of the clone time and a different network address.
- Snapshot before the risky step: on db-test-01, take a snapshot named pre-upgrade. A snapshot freezes the disk state, so any later change can be discarded. Then run the upgrade: sudo apt install postgresql-16 followed by pg_upgradecluster 14 main. It completes, but the nightly reconciliation job fails because an extension used by the risk reports is not yet available for version 16.
- Revert: choose Revert to Snapshot pre-upgrade. Within seconds db-test-01 is back on version 14 with no trace of the attempt. Production was never involved. The team waits for the extension, repeats the test a week later, and it passes.
- Right-size while you are there: the host's monitoring shows db-prod-01 averaging 8% CPU. Reducing it from 4 to 2 virtual CPUs frees capacity for other VMs on the host; memory stays at 16 GB because PostgreSQL caches use it. The change needs a reboot, scheduled for the maintenance window.
- Clean up: db-test-01 keeps 200 GB of storage and a copy of production data on the test network. It is deleted after the upgrade, and the snapshot on production (if one was taken) is removed too, because snapshots left in place grow and slow the disk over weeks.
A VM is a file you can copy, freeze and roll back, which makes testing dangerous changes safe, as long as the clones and snapshots are deleted once they have done their job.
Common pitfalls
- Leaving snapshots in place for weeks: they are not backups, they grow with every write and slow the VM down until someone consolidates them.
- Treating a clone of production as harmless: it contains real client data and must live on an isolated network with the same access controls, then be deleted.
- Over-allocating virtual CPUs: a VM with more vCPUs than it uses can run slower on a busy host, because the hypervisor must schedule all of them together.
- Confusing a VM with a container and choosing one for the wrong reason: a VM for a single stateless microservice wastes resources; a container where regulators require strong isolation between environments fails an audit.
- Forgetting that the guest operating system is a full computer: it needs patches, antivirus and monitoring exactly like a physical server.
Frequently asked questions
What is a virtual machine in simple terms?
A complete computer simulated in software. A hypervisor on a physical host lends it CPU, memory, disk and network, and a full operating system runs inside, unaware that the hardware is shared. Several VMs can run on one server, each isolated from the others, and each can be copied, snapshotted or moved like a file.
What is the difference between a virtual machine and a container?
A VM runs its own operating system on virtual hardware; a container shares the host's kernel and packages only an application with its libraries. Containers start in seconds and are small, VMs take a minute to boot and carry gigabytes, but VMs isolate more strongly because nothing is shared with the host kernel. Cloud providers typically run containers inside VMs to get both.
What is a hypervisor?
The software that creates and runs virtual machines by sharing physical hardware among them. Type 1 hypervisors such as VMware ESXi, Microsoft Hyper-V and KVM run directly on the server and power data centres and clouds. Type 2 hypervisors such as VirtualBox or VMware Workstation run as applications on a laptop, which is how most people first try a Linux VM on Windows or macOS.
Why do cloud providers use virtual machines?
Because VMs let them sell slices of large physical servers to many customers safely. Each customer's VM is isolated by the hypervisor, can be any size from a fraction of a core to a whole machine, and can be created or destroyed in minutes by an API call. That elasticity and isolation are what make infrastructure as a service possible.