Mirco Cloud Primer
Photo by Pavel Danilyuk on Pexels
Think about the superintendent of a large apartment building. The super doesn't live in any one apartment, but decides how the building gets divided into separate units, makes sure each unit's utilities stay separate from its neighbors, and ensures no resident can wander into another resident's space uninvited. A hypervisor plays almost exactly that role for computers: it's the software that divides one physical machine into several separate, locked-off virtual machines, and makes sure none of them can see or interfere with the others.
This article explains what a hypervisor actually does, the two broad categories it comes in, and why this one piece of software is so central to how modern cloud computing works.
What a hypervisor is responsible for
A hypervisor sits between the physical hardware of a server — its processor, memory, and storage — and the virtual machines that run on top of it. Its job is to divide that hardware into separate slices, hand one slice to each virtual machine, and continuously enforce the boundary between them, so that one virtual machine's activity, or even a crash inside it, cannot reach across into another.
Type 1: hypervisors that run directly on hardware
A Type 1 hypervisor, sometimes called a "bare-metal" hypervisor, installs directly onto a physical server without a general-purpose operating system underneath it. This is the type almost all cloud providers rely on, because it's more efficient and generally considered more secure — there's no separate operating system layer underneath that could introduce extra overhead or an extra point of failure.
Type 2: hypervisors that run inside an operating system
A Type 2 hypervisor instead runs as a regular application on top of an existing operating system, the way any other program would. This type is common for individuals running a virtual machine on their own personal laptop or desktop — for example, to try out a different operating system temporarily — but it's rarely how large-scale cloud infrastructure is actually built, since it adds an extra layer of overhead that a bare-metal hypervisor avoids.
Comparing the two types
| Type | Runs on top of | Typical setting |
|---|---|---|
| Type 1 (bare-metal) | Physical hardware directly | Cloud provider data centers |
| Type 2 (hosted) | An existing operating system | Personal laptops and desktops |
Why isolation is the whole point
The entire value of a hypervisor comes down to trustworthy isolation. A cloud provider might run virtual machines belonging to many different, unrelated customers on the very same physical server, and none of those customers can see or affect each other's data or performance, because the hypervisor enforces a strict boundary between them. This isolation is a foundational piece of the shared responsibility model, since the provider is responsible for keeping that boundary solid, while each customer remains responsible for what happens inside their own virtual machine.
How this connects to everyday cloud use
Every time a cloud customer requests a new virtual machine, it's the hypervisor, working behind the scenes, that actually finds available capacity on a physical server and carves out a new, separate slice for that request. Most people using cloud services never see or configure a hypervisor directly — it operates invisibly, one layer beneath the virtual machines that customers actually interact with.
Why cloud providers invest so heavily in this layer
Because a single physical server running a hypervisor might host virtual machines belonging to many completely unrelated customers at once, that one piece of software becomes an unusually important point to get right. A flaw in a hypervisor's isolation could, in theory, let activity in one virtual machine affect another, which is why cloud providers dedicate significant engineering effort to testing, patching, and monitoring this layer specifically. For an everyday user, this mostly shows up as a kind of invisible trust: you generally don't need to think about the hypervisor at all, precisely because so much work goes into making sure it quietly does its job without drawing attention to itself.
Common mistakes beginners make
- Confusing the hypervisor itself with the virtual machines it creates and manages.
- Assuming a hypervisor is something only cloud providers use, when Type 2 hypervisors are also common on personal computers.
- Believing hypervisor isolation makes a virtual machine's own security unnecessary — the VM still needs its own updates and protections inside that boundary.
- Overestimating how much hands-on hypervisor management is required for typical cloud use, when most of it happens automatically.
Frequently asked questions
Is a hypervisor the same thing as a virtual machine?
No — a hypervisor is the software that creates and manages virtual machines, while a virtual machine is one of the isolated units that the hypervisor produces and keeps separate from the others.
What's the difference between Type 1 and Type 2 hypervisors?
A Type 1 hypervisor runs directly on the physical hardware and is the kind used by cloud providers, while a Type 2 hypervisor runs as an application on top of an existing operating system, which is more common for personal use on a regular laptop or desktop.
Can a hypervisor fail?
Like any piece of software, a hypervisor can fail, and because many virtual machines may depend on the same hypervisor, cloud providers invest heavily in redundancy and monitoring to keep that risk as low as possible.
Do I ever interact with a hypervisor directly?
Most cloud users never interact with the hypervisor directly; it works quietly in the background, and you typically only see and manage the virtual machines it creates, through a provider's console or tools.
Related reading
Sources
- NIST SP 800-145 — The NIST Definition of Cloud Computing
- Documentation published by major public cloud providers (consulted October 2026)