What is a hypervisor? Type 1 vs Type 2 explained

The plain idea

Think of the hypervisor as a traffic controller for a physical machine’s resources. Several virtual machines want to use the same CPU cores, the same pool of memory and the same disk — the hypervisor decides, moment to moment, which guest gets which slice, and makes sure one guest’s activity never leaks into another’s. Each virtual machine believes it has dedicated hardware; the hypervisor is the illusion-maker that makes that belief consistent and safe.

It also handles the harder edge cases: starting and stopping virtual machines, presenting each one with virtual versions of a network card and a disk controller, and — in more advanced setups — moving a running virtual machine from one physical host to another without it ever noticing. All of that sits inside, or just above, the hypervisor.

The two types, clearly

Hypervisors come in two shapes, distinguished by what they run on top of.

• Type 1 ("bare-metal") — runs directly on the physical hardware, with no general-purpose operating system underneath it. This is what data centres and cloud providers run: it has the smallest possible layer between the guest virtual machines and the real hardware, which means less overhead and a smaller attack surface.
• Type 2 ("hosted") — runs as an application on top of a normal operating system, the same way a word processor or a browser does. This is the shape most people meet first, running desktop virtualization software on their own laptop to try a different operating system inside a window, without needing dedicated hardware for it.

How it relates to virtualization and the cloud

The virtualization explainer describes the abstraction — turning one physical machine into many virtual ones; the hypervisor is the software that performs that abstraction. Every claim made there about efficient hardware use and isolation is really a claim about what the hypervisor guarantees: it schedules the shared resources fairly and keeps each guest sealed off from the others.

Cloud providers run Type 1 hypervisors at enormous scale across their physical fleets. When you launch a compute instance, a provider hypervisor somewhere carves out a virtual machine for you on one of its physical hosts, wires up its virtual network interface, and starts it — all before you have finished typing the command. You never see or manage that hypervisor directly; it is entirely the provider’s responsibility, which is part of what "infrastructure as a service" actually means in practice.

Hypervisors versus container runtimes

A hypervisor creates isolation by giving each virtual machine its own full operating system on top of virtualised hardware. A container runtime creates isolation differently: containers share the host’s operating-system kernel and are separated from each other by kernel-level boundaries rather than by running a whole separate operating system each. That is why containers start in a fraction of the time a virtual machine takes and use markedly less overhead per instance — and also why their isolation boundary is thinner than a hypervisor’s. The full comparison, including where each approach is the better fit, lives in the containers-versus-virtual-machines explainer rather than here.

The security angle

The hypervisor is one of the most important isolation boundaries in the whole cloud model. It is what stops one customer’s virtual machine from reading another customer’s memory, disk or network traffic, even though both run on the very same physical host. A hypervisor vulnerability that allowed a guest to "break out" and reach the host, or another guest, would undermine the isolation the entire multi-tenant cloud depends on — which is exactly why providers invest heavily in hardening it and patching it quickly.

This is also a clean, concrete example of the shared-responsibility model: securing the hypervisor and the physical infrastructure underneath it is the cloud provider’s job, not yours. Your responsibility starts one layer up, inside the guest operating system and the application you run on it.

Where hypervisors fit in certification study

Foundational exams — AWS Cloud Practitioner, Azure Fundamentals — expect you to know what a hypervisor is conceptually and, often, where the line of shared responsibility sits: the provider secures the hypervisor and physical hardware, you secure what you run inside the virtual machine. Deeper hypervisor internals, such as Type 1 architecture details or live-migration mechanics, sit outside almost every cloud certification track and belong to specialist virtualization qualifications instead.