What is a hypervisor? A guide to Type 1, Type 2, and beyond

Key takeaways

• A hypervisor is software that lets one physical machine run multiple isolated virtual machines by allocating CPU, memory, storage, and other resources.
• Hypervisors improve hardware efficiency, reduce server sprawl, and support common workloads in cloud computing, server virtualization, and development.
• Type 1 hypervisors run directly on hardware, while type 2 hypervisors run on top of an operating system.
• Hypervisors offer flexibility and scale, but they also add overhead, shared-resource tradeoffs, and cases where bare metal may be the better fit.

Before hypervisors, IT infrastructure was very limited, forcing a rigid one-to-one relationship between hardware and operating system. Today, they’re the foundation of cloud computing, and this guide will explore what a hypervisor is, the different types, and how it all works.

What is a hypervisor?

A hypervisor is the foundational virtualization engine responsible for abstracting physical computing infrastructure into fully independent virtual machines, each capable of running its own operating system and workloads.

The need for hypervisors emerged from the structural limitations of traditional servers. They were typically bound to a single operating system, and often to a single application stack. 

The model led to low hardware utilization, inefficient capability planning, higher capital and operating costs, and slow provisioning cycles because everything had to be done manually for each new environment. 

Virtualization solved those problems by introducing a control layer that could partition a single physical system into multiple isolated environments using only software.

How does a hypervisor work?

A hypervisor operates by positioning itself as the sole authority over a server’s physical hardware, sitting directly between the bare metal and every operating system running above it.

But to understand what it actually does, you have to start with the problem it was built to solve. That problem is a specific hardware conflict, not just a matter of resource sharing.

An operating system expects exclusive control over the machine it runs on, managing memory, controlling devices, and scheduling processes. You can’t have two operating systems claiming that authority simultaneously. 

The hypervisor resolves that by claiming it for itself, mediating everything about it, ensuring every guest’s OS still runs and behaves as normal, but just without direct access to the physical hardware beneath.

When a guest OS issues an operation that would normally require direct hardware access, the hypervisor intercepts it, executes it safely, and returns the result, but for the guest OS, it feels like it did the action. 

At the same time, it maintains a fixed pool of physical resources, allocating each virtual machine its own CPU, memory, and storage when it’s created, and strictly enforcing the boundaries, so no VM can consume beyond what it’s being assigned or reach into what belongs to another.

Why hypervisors matter

Better hardware utilization

Physical infrastructure typically offers far more capacity than any single workload can use efficiently on its own. For a long time, that gap between installed capacity and actual demand was treated as a routine limitation of dedicated systems. Servers were often assigned to individual roles even when much of the underlying hardware remained underused.

Virtualization allows multiple workloads to share the same physical machine, and a hypervisor turns unused capacity into productive capacity. Instead of tying one environment to one server, an organization can consolidate demands across fewer systems and push utilization closer to the hardware’s real potential.

Isolation between workloads

Even though multiple VMs may share the same physical servers, the hypervisor keeps them separated as if they were running on entirely different machines. 

Administrative changes, software activities, and system behavior inside one VM remain confined to that guest rather than spilling into others on the same host.

Faster provisioning and flexibility

Ordering and setting up physical hardware can take days. With a hypervisor, creating a new virtual machine takes minutes. Administrators can spin up, clone, or delete environments instantly without ever touching the physical machine.

Lower physical server count

Running multiple virtual machines on a single host drastically reduces the number of physical servers an organization needs to buy. Fewer machines mean less required rack space, lower power and cooling bills, and far less hardware to support over time.

Types of hypervisors

There are two main types of hypervisors, defined by their relationship to the physical servers and whether or not they require a traditional operating system to function. To understand the difference, it helps to look at the architecture flow of each:

• Type 1 (Bare-Metal): Server Hardware -> Hypervisor (acts as the base OS) -> Guest OS (Inside the VM) -> Application
• Type 2 (Hosted): Server Hardware -> Host OS (like standard Windows or macOS) -> Hypervisor (runs as an application) -> Guest OS (Inside the VM) -> Application

Type 1 hypervisors

A Type 1, or bare-metal, hypervisor runs directly on physical server hardware and manages virtual machines without relying on a traditional host operating system

In a modern enterprise server, the hypervisor boots first and takes full control of system resources such as CPU scheduling, memory allocation, storage, and device access. Rather than running user applications, its role is to divide the physical hardware into isolated virtual environments, each capable of running its own guest operating system independently.

This architecture reduces latency, improves efficiency, and enables near-native performance for virtual workloads. 

Industry-leading bare-metal hypervisors include VMware ESXi, widely adopted in enterprise data centers for its mature ecosystem and management tooling, Microsoft Hyper-V, commonly integrated into Windows Server environments, and KVM, which powers a large portion of modern cloud and Linux-based infrastructure.

Type 2 hypervisors

A Type 2 hypervisor, also known as a hosted hypervisor, operates above a conventional host operating system rather than directly on physical hardware. In this architecture, the host OS retains control, while the hypervisor runs within that existing software layer to create and manage guest virtual machines.

While this reliance on an intermediary host operating system introduces performance overhead, it provides unmatched flexibility for local computing. It allows users to rapidly deploy isolated guest environments using tools like Oracle VirtualBox or VMware Workstation. 

Type 2 hypervisors are the industry standard for software testing, legacy application support, and prototyping on everyday desktop infrastructure.

Type 1 vs. Type 2

The architectural difference reflects a fundamental tradeoff between raw control and practicality.

Type 1 with direct access delivers better performance and stability that the enterprise demands. Of course, you need a higher expertise on every step and your own infrastructure, but that is an expected tradeoff.

Type 2 hypervisor runs as an application. Every guest request must travel through the host, and from a systems standpoint, each virtual machine runs as a collection of scheduled processes, with guest memory and virtual CPUs, handled through the host OS resource management layer. Disk and network must pass through the guest’s virtual hardware abstraction and traverse the host OS driver stack before reaching the physical devices. That complexity adds delay, especially noticeable under disk-heavy loads.

When the goal is performance isolation and uptime guarantees, Type 1 is the way to go. Type 2 is perfect for short-lived test environments, where the speed of iteration is needed the most.

Common hypervisor use cases

Server virtualization

The moment a physical box becomes a virtual workload, it collapses into a portable set of files: disk image, configuration, state. Dozens of single-purpose servers once consumed dedicated rack space at single-digit utilization consolidated onto shared physical hosts, with the hypervisor enforcing the isolation that previously required physical separation. The economics of that density compound at scale. 

The hardware lifecycle is also different now. A virtual workload migrates live between physical generations without the application stack ever knowing the silicon changes underneath it. That makes refresh cycles non-disruptive: a host can be drained, replaced, and returned to the pool while service keeps running. It also extends the useful life of aging infrastructure. Hardware that would otherwise sit idle can join the shared pool incrementally and be removed the same way.

Cloud computing

Cloud providers run a hypervisor at a scale no single organization builds for itself, and that scale is what makes the economics work. A physical host gets carved into isolated tenant slices, each bullied independently. What hypervisor abstracts away on-premises, the cloud removes entirely from the customer’s reach: the physical layer becomes invisible, and with it control.

What remains in the customer’s hands is the configuration layer: which resources to allocate, how they connect, and what runs inside them. Everything below the virtual machine boundary belongs to the provider. The hypervisor is still there, doing the same job, but it’s just no longer in the customer’s reach.

Development and testing

Software development demands environments that can be created, broken, and discarded without consequence. 

Before virtualization, reproducing a specific OS version, dependency conflicts, or a legacy configuration meant sourcing dedicated hardware, which made certain test scenarios expensive and very slow. A hypervisor removes that friction by making environments entirely software-defined and instantly disposable.

A developer can run three different OS versions on the same laptop to chase a platform-specific bug. A QA engineer can hand a teammate the exact VM image they tested against, eliminating rare case scenarios. 

Disaster recovery and workload migration

When a physical server fails, everything running on it stops until the hardware is replaced or rebuilt. 

A hypervisor decouples the workload from the machine it runs on, so recovery no longer depends on sourcing identical hardware or reconstructing the environment from scratch. The VM replicates to a secondary host and starts there, with the same OS, the same configuration, and the same state it had before the failure.

The same decoupling is what makes live migration possible. A running workload can move between physical hosts while it keeps serving requests, the application doesn’t pause, and users see nothing. Organizations use that capability constantly: draining a host before scheduled maintenance, rebalancing load across the pool, or retiring aging hardware without ever taking a service offline to do it.

Benefits of hypervisors

• Cost efficiency: By consolidating multiple virtual machines into a single physical host, organizations drastically reduce hardware expenses and maximize server utilization.
• Rapid provisioning: Hypervisors bypass the physical setup process, allowing administrators to instantly deploy compute resources exactly when and where workloads need them.
• Workload mobility: Virtual machines are completely divorced from the physical host. This allows IT teams to easily migrate environments or configure them as you wish.
• Hardware independence: Because the hypervisor abstracts the physical components, guests’ operating systems are no longer tied to specific hardware devices or proprietary devices.

Hypervisor vs. virtual machine

The hypervisor is the foundation, and the virtual machine is the environment running on top of it. It is the management layer responsible for controlling the physical hardware and dividing up its resources. 

The virtual machine is an isolated, self-contained operating system that utilizes those divided resources and has no visibility into what else is sharing the same physical machine.

They’re working together and solving different problems: The hypervisor solved the infrastructure problem. It divides one physical machine into many isolated environments. The virtual machine solved the workload problem: how to run an OS and application stack in a way that’s portable, reproducible, and independent of the hardware beneath it. 

Hypervisors vs. containers

While both are virtualization tools, they operate at fundamentally different levels of the software stack.

Hypervisors virtualize hardware. They divide physical servers into isolated virtual machines, requiring every VM to boot its own complete, independent operating system.

Containers virtualize operating systems. They package an application together with its required files, but they share the same host, existing under the same operating system, instead of booting its own.

Because containers don’t boot a full operating system, they’re incredibly lightweight and spin up in seconds. However, because hypervisors run entirely distinct operating systems, they provide much stronger, hardware-level security isolation and efficiency.

Hypervisor drawbacks and tradeoffs

Hardware vendors have spent decades closing the gap between virtualization and bare-metal performance. And yet, none of that changes the fundamental reality: a hypervisor is still an abstraction layer, and abstraction always costs something.

The latency problem is the most visible under I/O-heavy workloads. Every operation a guest OS issues, like a disk read, a network call, or a memory access, all pass through the hypervisor before it reaches physical hardware. That round trip is fast under normal conditions, but it is never zero, and especially noticeable on peak demand.

Then there’s the operating cost that rarely appears in architecture diagrams. Enterprise hypervisors like VMware carry licensing fees, and those costs compound at scale. 

Not to mention managing this infrastructure, which also requires specialized expertise that general systems administrators do not have. Misconfiguration at the hypervisor level doesn’t just affect one workload; it affects everything running on that host. The skills required to operate it safely, tune it, and troubleshoot it when something goes wrong are a real organization’s investments.

Bare metal vs. hypervisor

When a hypervisor makes sense

The strongest case for a hypervisor is when the infrastructure needs to serve multiple workloads, complex environments, and big teams without a dedicated physical machine for each. 

A hypervisor is fundamentally a tool for environments that need to move. Workloads get created, retired, cloned, and migrated. When you still can’t decide on the scale, you start building a system instead. You prepare for different scenarios, and the hypervisor is the solution.

When bare metal makes sense

Bare metal is for environments designed to stay the same and perform. If you have massive databases, heavy GPU processing, or real-time analytics, the virtualization tax is quite wasteful.

Bare Metal doesn’t have the hypervisor as a middleman, granting your application direct access to raw hardware. If a server has a single, dedicated job and doesn’t need to move any time soon, defaulting to a hypervisor would be overengineering the system.

How to choose

The decision hinges on what you need from the system: raw performance or flexibility. If the application demands every last drop of CPU, RAM, and I/O, the bare metal would be the best choice. If an organization anticipates rapid scaling and shifting priorities, the hypervisor makes the most sense.

Security considerations for hypervisors

Introducing a hypervisor means introducing a new attack surface. The absolute worst-case scenario in virtualization is when a virtual machine is compromised by an attacker and breaks out into the underlying hypervisor layer. Once they have the keys to the hypervisor, they own every other virtual machine sitting on that physical hardware.

By pooling all resources onto a single management layer, the risk increases dramatically. However, modern hypervisors are designed with that exact threat in mind. Type 1 hypervisors in particular run in internationally minimal codebases to have less change for exploits. VM escape vulnerabilities exist and get disclosed, but they’re rare, heavily researched, and patched.

The more common threat is the management plane. A compromised management console gives an attacker the same effective control as a hypervisor breach without ever touching the virtual layer. Locking down administrators, isolating management traffic from production networks, and many more.

The security holds as long as the hypervisor is patched, configured correctly, and treated as critical infrastructure.

Examples of common hypervisors

KVM

KVM, or Kernel-based Virtual Machine, is a Type 1 hypervisor built directly into the Linux kernel. 

It turns the Linux kernel into the hypervisor, giving virtual machines near-native access to hardware. It powers a significant number of modern cloud infrastructures, like Google Cloud, and remains a default choice for Linux-based virtual machines at scale.

VMware ESXi

VMware ESXI is a Type 1 bare-metal hypervisor. It runs directly on hardware with no underlying OS, managing resources via VMware’s broader ecosystem, and became the default choice for production virtualization, largely because it was mature and well-documented.

Microsoft Hyper-V

Microsoft Hyper-V is a Type 1 hypervisor built into the Windows Server, making it the default virtualization solution for organizations already running Microsoft infrastructure. It ships without additional licensing, which lowers the entry, and has tight integration with Microsoft Azure and the overall Microsoft ecosystem.

VMware Workstation / VirtualBox / Parallels

We’re introducing Type 2 hypervisors built for local use rather than production infrastructure. VMware, VirtualBox, or Parallels all run as applications on a host OS, which adds overhead but makes them immediately available without dedicated hardware or specialized setup.

• VMware Workstation is dedicated to developers who need tight performance and deep configuration control. 
• VirtualBox is open-sourced, free, and widely distributed.
• Parallels is macOS-friendly and becoming the best choice for developers running Windows on Apple silicon.

Hypervisor FAQs

Getting started with hypervisors

Hypervisors are the holy grail of modern cloud computing, enabling scale and flexibility we have never seen before. It’s the reason companies can afford to move fast and try things that classic servers couldn’t allow. But still, most organizations need both at different times, and the infrastructure should be a tool to help achieve these goals.

Liquid offers both plans. Whether your workload calls for a fully-managed VPS built on enterprise-grade virtualization, or a bare metal server with direct, unshared hardware access.

LiquidWeb has a wide range of options that will cover everything from a small project to enterprise-level demand.