One computer pretending to be several
A virtual machine, often shortened to VM, is a software-created computer that runs inside a real one. It has its own virtual processor, memory, storage and network connection, and it runs its own operating system as though it were a separate physical machine. The operating system inside the VM, called the guest, usually does not need to know it is not running on real hardware.
The physical computer is the host. A single host can run several VMs at once, each isolated from the others. If one guest crashes or gets infected with malware, the others and the host are typically unaffected, although isolation depends on correct configuration and is not absolute.
The hypervisor
The software that creates and manages VMs is called a hypervisor. It divides the host’s real resources among the guests: some processor time, a slice of memory, a portion of disk space. Two broad styles are common.
- Bare-metal hypervisors run directly on the hardware and are typical in data centers, where the machine exists only to host VMs.
- Hosted hypervisors run as an ordinary application on top of a normal desktop operating system. These are convenient for learning and testing on a laptop.
Because VMs share the host, they compete for the same resources. If too many are started, or if one is very demanding, all of them may slow down. Careful planning of how much each receives is part of running virtualization well.
What a VM is stored as
A VM is largely a set of files: a virtual disk, which acts as the guest’s hard drive, and a configuration describing its virtual hardware. This has useful consequences. The VM can be copied, moved to another host, backed up like any other file, or reset to an earlier state using a snapshot, a saved point in time. That is quite different from a physical machine, which is tied to its hardware.
Snapshots are handy, but they are not a replacement for backups. They typically sit alongside the original data, so if the underlying storage fails, both may be lost, and a long chain of them can reduce performance.
Common reasons people use VMs
Consolidating servers
Years ago, many organizations ran one application per physical server, and most of those machines sat mostly idle. Virtualization lets several lightly loaded systems share one host, which can reduce hardware, power and space needs. It also makes it simpler to add a new server: creating a VM can take minutes, whereas buying and installing hardware takes much longer.
Testing and development
Developers and administrators use VMs to try software in a clean environment, test an update before it goes live, or reproduce a customer’s setup. If something goes wrong, the VM can be deleted or reverted without harm to the real system. This also fits well with patch management, where updates are tried on a copy first.
Learning and practice
Anyone can create several VMs on a single laptop and practice installing systems, configuring services and breaking things safely. This is a common way to build a home lab with little money.
Running software that needs a different system
Sometimes an application works only on a particular operating system, or an older application will not run on a current one. A VM lets you run that guest system alongside your normal one. Old systems that no longer receive security updates remain a risk, though, so such VMs should be isolated from sensitive networks.
Safer handling of risky files
Security analysts sometimes open suspicious files in an isolated VM so that any damage is contained and can be discarded. Careful setup matters, because some malicious software tries to detect or escape from virtual environments.
Cloud computing
Much of the cloud is built on virtualization. A cloud provider runs huge numbers of VMs on its hardware and rents them out. When people hire a virtual server there, they are using this idea at scale, as part of the infrastructure model described in cloud service models.
Virtual machines and containers
Containers are a related but different approach. A VM includes a complete guest operating system, whereas software containers share the host’s operating system kernel and package just an application and its dependencies. Containers are generally lighter and quicker to start, while VMs usually provide stronger separation because each has its own operating system. Many environments use both.
Costs and limits
Virtualization is not free of trade-offs.
- Overhead. The hypervisor and each guest operating system use some resources, so performance is somewhat lower than running directly on hardware for the same job.
- Shared fate. If the host fails, every VM on it goes down, unless the organization has designed for this with extra hosts and backups.
- Sprawl. Because VMs are easy to create, organizations can end up with many forgotten ones that still need patching and monitoring.
- Licensing and skills. Operating systems and software inside VMs still need valid licenses and management, and the virtualization layer needs people who understand it.
- Security. The hypervisor becomes a high-value component and must be kept up to date and tightly controlled, in line with least privilege for administrators.
Trying it out
If you want a first experience, install a hosted hypervisor on a computer with enough memory and free disk space, create a VM, and install a guest operating system from an official installation image. Keep the guest’s resource settings modest, take a snapshot after setup, and experiment freely. Learning how a VM behaves makes later topics, such as servers, cloud computing and recovery planning, much easier to picture.