A type 1 hypervisor installs directly onto the hardware. A type 2 hypervisor is an application inside an operating system that booted first. That single difference decides the performance, the security boundary and the failure modes. Type 1 runs servers and cloud infrastructure. Type 2 runs on a laptop, and belongs nowhere near production.
- Ask what boots first, and the classification answers itself
- The overhead is on the device path, not on the processor
- Hyper-V looks type 2 and is not. KVM looks type 2 and behaves type 1
- A type 2 host reboots for updates, taking every machine with it
- Bare metal hypervisors will not drive a laptop wireless card
On this page
The stackThe stack, drawn in words
The whole comparison is one difference in layering, and it is worth being precise about it.
A type 1 hypervisor is the operating system. The machine boots the hypervisor software. Nothing sits between it and the processor, the memory or the storage controllers.
It owns the physical hardware, schedules virtual machines directly onto those resources, and it is deliberately small: ESXi has no general purpose shell and no thousand background services, because everything it does not have is something that cannot go wrong or be attacked.
A type 2 hypervisor is a program. Windows or macOS or Linux boots first, does everything an operating system does, and then somebody launches the virtualization software. Every instruction a virtual machine executes, every disk read, every packet of data, passes through the host scheduler and drivers on the way to the physical hardware.
That layer costs three things.
Performance. The overhead is real and it is not catastrophic. Modern processors have virtualization extensions both types use, so the CPU work is close. What differs is everything touching hardware: disk and network data goes through the host driver stack, which adds latency to every operation.
Predictable resources. The host operating system schedules the hypervisor alongside a browser, a mail client and an antivirus scan. Virtual machines that are fast in the morning and slow after lunch are a type 2 hypervisor competing for resources with whatever else the user opened.
The security boundary. The attack surface of a type 1 hypervisor is the hypervisor software. For a type 2 hypervisor it is that software plus an entire general purpose operating system underneath, with its browser, its user, and every application that user installs. A security flaw in the host reaches every virtual machine on it.
The products, sorted by what actually boots first, because the question underneath this one is usually which type the thing on your desk already is.
| Product | Type | What boots first |
|---|---|---|
| VMware ESXi | 1 | The VMkernel, and nothing else |
| Microsoft Hyper-V | 1 | The hypervisor, then Windows as a partition |
| Xen | 1 | Xen, then dom0 as a privileged guest |
| KVM | 1, by behavior | Linux, with the kernel acting as the hypervisor |
| Proxmox VE | 1 | Debian with KVM, so the same argument as KVM |
| Oracle VirtualBox | 2 | Your operating system, then the application |
| VMware Workstation and Fusion | 2 | Your operating system, then the application |
| Parallels Desktop | 2 | macOS, then the application |
| QEMU without KVM | 2 | Your operating system, and it emulates rather than virtualizes |
The KVM and Proxmox rows are where the classification argument lives, and the last row is the one worth knowing separately: QEMU on its own emulates a processor in software, which is far slower and is also what lets it run an architecture the host does not have.
The edge casesWhere the categories blur
The textbook split is clean and real systems are not, and knowing where it bends prevents a lot of confused argument.
KVM is the interesting case. It is a module inside the Linux kernel, so Linux boots first and KVM turns that kernel into a hypervisor. By the strict definition it looks type 2, because an operating system is underneath.
In behavior it is entirely type 1: virtual machines are scheduled by the kernel itself with no intermediate software layer, and it runs a large share of the world's cloud infrastructure. Most people classify it as type 1, and the argument is more interesting than it is useful.
Hyper-V looks type 2 and is not. Enabling the role on Windows moves the hypervisor underneath, and the Windows installation that appeared to be the host becomes a privileged partition beside the other VMs rather than under them. The screen still shows Windows, and the architecture underneath has changed.
ESXi has a management layer that is not an operating system. The VMkernel is software purpose built for this job, not a general purpose system with a hypervisor bolted on, which is the distinction people reach for when they call it truly bare metal.
The practical rule that survives all of this: ask what boots first. If a general purpose operating system boots and you then start an application to run VMs, it is type 2. If the physical machine boots into virtualization, it is type 1, whatever the kernel underneath is called.
Which to useWhich one you should be running
The answer is not close in any of the real use cases, and it is worth stating plainly because the two types sometimes get presented as a genuine choice.
Anything in production is type 1. Servers, hosts, cloud infrastructure, any enterprise systems that have to stay up when nobody is watching. Bare metal is where the performance is, where the isolation is, and where the management software exists.
A laptop or a desktop is type 2. Testing a configuration, running Linux environments on a Windows machine, keeping legacy applications alive, building a lab. Installation is a download, the VMs share the screen you are already looking at, and none of the type 1 advantages matter for work that stops when you close the lid.
Development environments are type 2, and increasingly containers instead. One VM per project was the standard answer for a decade, and containers do it faster with fewer resources. The remaining case for type 2 virtualization software in development is needing a whole different operating system, which containers cannot provide.
Do not run production on a type 2 hypervisor. It happens, usually by accident: a proof of concept on somebody's workstation that became load bearing infrastructure. The failure mode is that a Windows update reboots the host at three in the morning and takes every VM down without warning, because from the host's point of view it was closing an application.
PitfallsWhere people go wrong
Assuming type 2 means slow. The CPU overhead is small. The hardware path is where the cost is, so VMs doing heavy disk or network data transfer suffer and those doing computation barely notice.
Running Hyper-V and VirtualBox at the same time. Two hypervisors cannot both own the virtualization extensions. Enabling Hyper-V, which includes turning on features that quietly enable it such as WSL 2 or Windows security features, makes VirtualBox and VMware Workstation fall back to slow emulation or refuse to start.
Recent versions cooperate better and the conflict is still the single most common complaint on the desktop.
Forgetting that the host reboots. Patch Tuesday on a workstation running a type 2 hypervisor is a scheduled outage for everything on it.
Expecting type 1 to run on a laptop. The software installs on many of them and the wireless card does not work, because bare metal hypervisors ship drivers for server hardware. This is a well trodden disappointment.
Choosing on the classification rather than the use case. The question is not which type is better. It is whether the applications on it need to survive the host being closed, and that answers it immediately.
Ignoring the nested case. Running a hypervisor inside a VM works, and needs nested virtualization enabled on the outer one. It is the right way to build a lab environment, and it is noticeably slower than physical hardware.
ComparisonBare metal and hosted hypervisors, on what the extra layer costs
| Criterion | Type 1, bare metal | Type 2, hosted |
|---|---|---|
| What boots first | The hypervisor | An operating system |
| Device performance | Direct | Through the host drivers |
| Predictable resources | Yes | Competes with the host |
| Attack surface | Small | The host as well |
| Survives users closing a laptop | Yes | No |
| Installation effort | A server build | A download |
| Runs on ordinary laptop hardware | Rarely | Yes |
| Management tooling for a fleet | Mature | None |
| Right for production | Yes | No |
| Right for a lab on your own machine | No | Yes |
The last two rows are the answer, and everything above them is why. There is no workload where the middle ground is interesting.
FAQFrequently asked questions
What is the difference between a type 1 and type 2 hypervisor?
Type 1 installs directly onto the hardware with nothing underneath it. Type 2 runs as an application inside an operating system that booted first. Everything else follows from that.
Which is faster?
Type 1, and mostly on disk and network rather than on processor work. Both use the same CPU virtualization extensions, so computation is close.
Is KVM type 1 or type 2?
It is a Linux kernel module, so it looks type 2 by the strict definition and behaves like type 1, and most people classify it as type 1. The disagreement matters less than knowing why it exists.
Is Hyper-V a type 1 hypervisor?
Yes. Enabling the role moves the hypervisor underneath Windows, and the Windows installation becomes a privileged partition beside the virtual machines rather than a host under them.
Is VirtualBox type 1 or type 2?
Type 2. It is an application you install on an operating system that was already running.
Can I run a type 1 hypervisor on my laptop?
It usually installs and the wireless card usually does not work. Bare metal hypervisors ship server drivers, and consumer wireless is rarely among them.
Why does VirtualBox stop working after I enable Hyper-V?
Because two hypervisors cannot both own the processor virtualization extensions. Enabling Hyper-V, including indirectly through WSL 2 or some Windows security features, takes them.
Is a type 2 hypervisor less secure?
The boundary is weaker, because the attack surface includes a whole general purpose operating system with a browser and a user on it. The hypervisor itself is not the weak part.
Can I run production workloads on type 2?
You can and you should not. A host reboot for an operating system update takes every virtual machine down as though an application had been closed.
What is nested virtualization?
Running a hypervisor inside a virtual machine. It works with a setting enabled on the outer hypervisor, it is slower, and it is the right way to build a lab.
Do containers replace type 2 hypervisors?
For development environments, largely yes, and faster. The case a container cannot cover is needing a genuinely different operating system.
Which type does the cloud use?
Type 1, universally. Every major provider runs bare metal hypervisors, several of them heavily modified versions of KVM or Xen.
Keep readingRelated concepts
Read next · Containers What Is Docker? Containers replaced a virtual machine per project for most development work. Open this next14 min- Hypervisors · 11 min Hyper-V vs VMware Once you know it has to be type 1, this is the choice between the two that matter.
- Containers · 11 min Containers vs VMs The other way to run isolated workloads, which shares the kernel instead of virtualizing hardware.
- Platforms · 12 min Open Source Operating Systems, and Where the Cost Actually Goes The other place it arrives inside a product.
- Hypervisors · 10 min ESX vs ESXi, and Why the Question Is Now About Something Else The category ESXi belongs to, and what the alternative looks like.