A virtual machine (VM) is a computer defined entirely in software. It has virtual processors, memory, disks and network cards, runs its own operating system and applications, and behaves like a physical server to everything running inside it. Underneath, a hypervisor maps those virtual resources onto a real physical server (the host) that is usually shared with other VMs. VMs are the standard unit of compute in most data centers and the most common form of public cloud server.
At a glance
- A VM runs a full operating system on a share of a physical host’s resources, isolated from other VMs on the same host.
- It exists as files and configuration, so it can be copied, snapshotted, resized, backed up and moved between hosts.
- VMs are created and managed through a hypervisor and its management tools, or a cloud provider’s console and API.
- Each VM still needs operating system patching, security, monitoring and backup.
- Easy creation leads to sprawl: unused VMs that keep costing money and need patching.
What problem it solves
A physical server is slow to buy, hard to move and usually underused. VMs address all three. An administrator can create a new server in minutes from a template, give it exactly the resources it needs, and change them later. Several workloads can share one host without interfering with one another’s operating systems. When the host needs maintenance or fails, many platforms can move or restart its VMs on another host.
VMs also make migration practical. Because the operating system is not tied to specific hardware, a VM can be moved to newer hosts, a different data center, a hosted private cloud or, with conversion tools, a public cloud, without reinstalling the application from scratch.
How it works
Host and guest. The physical server is the host; each VM is a guest. The hypervisor on the host gives each guest virtual hardware and schedules its access to the real processors, memory, storage and network.
Sizing. A VM is defined by its virtual processors (vCPUs), memory and disks. In a private environment you choose any combination the platform allows; in public cloud you usually pick from a menu of instance sizes, priced per second or hour.
Storage. A VM’s disks are files or volumes on local, shared or distributed storage. Snapshots capture a VM’s state at a point in time, which is useful before changes but is not a substitute for backup.
Networking. Virtual network cards connect to virtual switches on the host, which link to physical networks, VLANs or cloud virtual networks.
Overcommitment. Platforms can allocate more virtual processors and sometimes more memory than the host physically has, on the assumption that not all VMs peak at once. This raises efficiency but can cause contention if done aggressively.
For hosted options, see our private cloud solution page.
When it matters for buyers
- During cloud cost reviews. Oversized and idle VMs are among the most common sources of waste in Infrastructure as a Service (IaaS) bills; rightsizing and scheduling shutdowns can cut spend.
- When licensing software. Some software is licensed per virtual processor, per physical core of the host, or per host. How you place VMs can change what you owe. Confirm with the software vendor.
- When inheriting an environment. An inventory of VMs, their owners, operating system versions and backup status is often the first job for a new IT leader.
- When changing virtualization platforms. VMs can usually be converted between hypervisors, but drivers, tools and networking need testing.
- When performance must be consistent. Shared hosts can introduce variability; dedicated hosts or bare metal are alternatives.
Questions to ask vendors
- What VM sizes are available, and can we customize processor and memory independently?
- Do you overcommit processors or memory on shared hosts, and by how much?
- Can we get dedicated hosts if licensing or compliance requires it, and at what cost?
- How are VM disks stored and replicated, and what happens to running VMs if a host fails?
- Which backup and snapshot options are included, and how is retention priced?
- What tools do you provide to import our existing VMs, and which source platforms do they support?
- How do you bill a VM that is stopped but not deleted (for example, its disks and IP addresses)?
How it differs from bare metal
A VM and a bare-metal server can run the same operating system and applications, but a VM shares a physical host through a hypervisor while bare metal gives your software the whole machine directly. VMs are quicker to create, resize and move, and usually cheaper for small or variable workloads. Bare metal avoids hypervisor overhead and neighbors, and can simplify licensing tied to physical cores. You can also install your own hypervisor on a bare-metal server and run your own VMs on it, which is how many private clouds are built. Both differ from containers, which share an operating system rather than hardware alone.