A computer inside a computer
A virtual machine, often shortened to VM, is a software-based computer that runs inside a physical one. It behaves like a complete machine, with its own operating system, applications and settings, but it does not have its own dedicated hardware. Instead, it uses a share of the real computer’s processor, memory, storage and network connection.
One physical computer can host several virtual machines at once, each separate from the others. A program running in one VM generally cannot see or interfere with another VM on the same host.
The role of the hypervisor
The software that makes this possible is called a hypervisor. It sits between the physical hardware and the virtual machines and has several jobs:
- dividing up processor time, memory and storage among the VMs
- presenting each VM with a set of virtual hardware that looks like a real computer
- keeping the VMs isolated from one another
- starting, stopping, pausing and moving VMs as requested
The machine that provides the resources is the host, and each virtual machine is a guest. Some hypervisors run directly on the hardware, which is common on servers. Others run as an application on top of an ordinary operating system, which is common on desktops for testing or running another operating system.
Modern processors include features designed to support virtualization, which helps VMs run with relatively little performance loss compared with the same software on real hardware, though some overhead remains.
An everyday analogy
Think of a large house divided into apartments. The building, plumbing and electricity are shared, but each household has its own front door, rooms and belongings, and cannot walk into the neighbors’ homes. The landlord (the hypervisor) decides how large each apartment is and handles the shared systems.
Like most analogies, it breaks down at some point. For instance, a host can sometimes promise more total resources than it has, on the assumption that not every guest will use their full share at once. This is called overcommitment, and if done too aggressively it can slow everyone down.
Why they matter
Before virtualization, a company often ran one application per physical server for safety and simplicity. Many of those servers sat mostly idle. Virtualization allowed several workloads to share the same hardware, which improved utilization, reduced the number of machines, and saved space, power and cooling. This ties into data center energy.
It also changed how computing is bought. Cloud providers can carve their large pools of hardware into VMs of different sizes and rent them to customers by the hour or second. When you “launch a server” in the cloud, you are usually starting a virtual machine on a host in a data center, as described in cloud infrastructure. That is the basis of the infrastructure model in cloud service models.
Useful features
- Isolation. A crash or security problem in one VM normally stays within it.
- Snapshots. The state of a VM can be saved at a point in time and restored later, which is useful before risky changes. Snapshots are handy, but they are not a substitute for proper data backups, since they often live on the same storage as the VM.
- Cloning and templates. A configured VM can be copied to create more with the same setup.
- Migration. Many systems can move a running VM from one physical host to another with little or no interruption, which lets operators service hardware.
- Flexibility with operating systems. One host can run guests with different operating systems, and older software can be kept running in a controlled environment.
- Safe testing. Developers and security researchers can experiment, including with suspicious files, in a VM that can be discarded afterward, although isolation is not perfect.
Limits and trade-offs
- Overhead. Each VM carries a full operating system, which uses memory, storage and processing time. Many VMs on one host means many operating systems running side by side.
- Slower to start. A VM typically takes longer to boot than a lightweight alternative such as software containers, which share the host’s operating system kernel.
- Shared hardware. Heavy activity from one VM can sometimes affect its neighbors, often called the “noisy neighbor” problem. Providers use limits and scheduling to reduce it.
- Security is not automatic. Isolation relies on the hypervisor being correct. Vulnerabilities in hypervisors and in processors have been found in the past and fixed through software updates and firmware updates, but they show isolation is a strong boundary rather than an absolute one.
- Management work. Every VM needs its own operating system updates, patching and monitoring. In the infrastructure model, that is the customer’s job.
- Specialized hardware. Some tasks, especially those using accelerators for machine learning, need special arrangements to share hardware with VMs or to give a VM direct access to a device.
VMs and the alternatives
Containers package an application with its dependencies and share the host kernel, making them lighter, but with somewhat weaker isolation. Serverless computing hides the machine entirely. Bare-metal servers give a customer a whole physical machine with no hypervisor, which can suit demanding or sensitive workloads. These approaches are often combined. For example, containers are commonly run inside virtual machines to gain both convenience and a stronger boundary.
A short example
Suppose a small company needs a web server and a database server. Instead of buying two machines, it rents two small virtual machines from a cloud provider. Each has its own operating system and settings. Later, when demand grows, the company can resize the VMs or add a third. If the physical host underneath needs maintenance, the provider may move the VMs to another host. The company never touches the hardware, yet the VMs behave much like real computers.
That flexibility is why virtual machines remain a core building block of the cloud, even as newer approaches grow alongside them.