VM Isolation
How a Hypervisor Keeps Virtual Machines Apart
VM isolation is the set of mechanisms that stop one virtual machine (VM) on a shared physical server from reading, changing or interfering with the memory, disks and devices of another. A VM is a complete guest system, and the hypervisor is the software layer that runs VMs and enforces the boundaries between them.
Memory is the first boundary. The hypervisor gives each VM its own memory map and uses hardware features in modern processors to translate the addresses a guest uses into real memory locations. A guest can reach only the memory the hypervisor has assigned to it. An attempt to reach anything else is stopped by the processor and handled by the hypervisor.
CPU time is isolated as well. The hypervisor schedules each virtual CPU onto physical cores and saves and restores each guest's state when it is paused, so one VM's instructions never run in another VM's context.
Devices form the third boundary. A VM rarely talks to physical hardware directly. It sees virtual disks and network cards that the hypervisor provides, so every request passes through a layer that checks it. When a physical device is handed to one VM, a technique called passthrough, an IOMMU (a hardware unit) limits which memory that device can read and write, so it cannot reach into another guest.
Where Isolation Can Fail: VM Escape and Side Channels
No isolation layer is perfect. The most serious concern is VM escape, in which code running inside a guest exploits a flaw in the hypervisor or in a virtual device to act on the host or another VM. Such flaws are rare. When they are found, hypervisor vendors and open-source projects release patches, which is why hosts keep their hypervisors updated.
A subtler risk is the side channel. VMs on the same processor share caches and other hardware. A malicious guest can measure small timing differences in that shared hardware to infer data another guest is processing. Processor vendors and operating systems have added mitigations, but the lesson is that isolation makes attacks hard and costly rather than impossible.
Isolation also does not guarantee performance. A VM can be fully separated from its neighbors and still run slowly when they use a lot of CPU, disk or network. That effect is covered in the noisy neighbor problem.
Example: Two Customers on One Physical Server
Imagine a physical server running a VM for a customer's staging site and another VM for a different customer's online shop. Each VM has its own memory, virtual disk and virtual network card. If the shop's website is compromised, the attacker is still confined to the shop's VM. Reaching the staging VM would require breaking out of the hypervisor, which is far harder than exploiting the web application itself.
Frequently asked questions
Can one virtual machine read another VM's data on the same host?
Not under normal conditions. The hypervisor gives each VM separate memory, CPU scheduling and virtual devices, so a VM cannot read another's memory or disk through ordinary means. Doing so requires a flaw in the hypervisor or the hardware. Such flaws are rare and are patched when found, which is why keeping the host updated matters.
Are containers as isolated as virtual machines?
Containers are isolated, but more weakly. Containers on one host share the same Linux kernel, so a kernel flaw can affect all of them. A VM runs its own guest kernel behind a hypervisor, which is a separate and stronger boundary. For this reason, many hosts run containers inside VMs when customers need strong separation. See containers vs virtual machines for a full comparison.