HostiServer
2026-06-27 13:00
What is a Hypervisor: Virtualization Basics for Hosting in 2026
What is a hypervisor: virtualization basics for hosting in 2026
One physical server can simultaneously serve dozens of independent sites, databases, and mail systems — each on its own operating system, each isolated from the others as if they were sitting in different data centers. This is made possible by a single software layer between the hardware and the operating systems. It's called a hypervisor, and modern hosting rests on it.
Without hypervisors, modern hosting and cloud platforms simply wouldn't exist. AWS, Google Cloud, Microsoft Azure, every serious VPS provider in the world — it's all built on hypervisors. This isn't "one of the options" for infrastructure; it's the fundamental layer the industry stands on.
This article is about the basics: what a hypervisor is, how it works, what types exist, and how to pick the right one for your project. For a deep dive into specific platforms (Proxmox VE, VMware ESXi, KVM, Hyper-V, and others) there's a separate article on 8 bare-metal hypervisors of 2026; here we stay at the level of principles.
ℹ️ Who this article is for: site owners who want to understand what their VPS stands on; junior developers who keep hearing "hypervisor" from the DevOps team; anyone choosing a hosting type and wanting to understand what the actual difference is.
A hypervisor in plain language
A hypervisor (also: monitor of virtual machines, VMM) is a software layer between physical hardware and the operating systems running on that hardware. Its job is to convince each OS that it's running on "its own" computer, while in reality it shares resources with others.
It does this through three key mechanisms:
- Hardware emulation. The hypervisor creates virtual analogs of physical components: vCPUs in place of physical cores, a virtual memory controller, virtual disks, virtual network adapters. The guest OS sees these virtual components as if they were real.
- Resource allocation. The hypervisor tracks how much actual CPU time, RAM, and disk I/O each VM gets. If a VM has used up its quota, it has to wait for access to free up.
- Isolation. Each VM has its own OS kernel, its own user space, its own network configuration. A crash or compromise of one VM doesn't affect its neighbors.
This is a fundamental separation of concerns: physical hardware is "resources", the hypervisor is the "dispatcher", and VMs are "separate workstations". On a single physical server with 64 GB of RAM and 16 CPU cores, the hypervisor can launch, say, 8 VMs with 8 GB of RAM and 4 vCPUs each — and all of them will run as full-featured machines.
What a hypervisor does NOT do
It's worth saying this up front, because there are popular marketing promises that don't match reality:
- Doesn't protect against DDoS attacks. If your VM is being hit with a network flood, the hypervisor is powerless — DDoS protection works at the network level (firewalls, scrubbing services, CDN), not at the virtualization layer.
- Doesn't give magical speedups. The sum of all VM resources cannot exceed the server's physical capacity. If you provision 4 VMs with 8 vCPUs each on a 16-core server, at peak load all four will be fighting over the same 16 cores.
- Doesn't launch microservices in milliseconds. For that there are containers (Docker, Podman) and lightweight micro-VMs (Firecracker from AWS, Cloud Hypervisor). A regular VM boots in seconds to tens of seconds, which is too slow for large-scale cloud functions.
Two types of hypervisors: Type 1 (bare-metal) and Type 2 (hosted)
The classical hypervisor classification is based on where exactly the hypervisor runs relative to the operating system. Understanding this difference helps you correctly choose between VPS hosting and local development.
Type 1 — bare-metal: the hypervisor as the foundation
A Type 1 hypervisor installs directly on the physical hardware, replacing the operating system. On a server like this, there's no Windows or Linux in the traditional sense — there's only the minimal hypervisor shell on which virtual machines run.
This is the option for servers, data centers, clouds, and corporate installations. Everything running in production — VPS providers, AWS, Google Cloud — is built on Type 1.
Examples: VMware ESXi, Microsoft Hyper-V, Proxmox VE, KVM, XCP-ng, Nutanix AHV.
Type 2 — hosted: the hypervisor as an application
A Type 2 hypervisor installs on top of an already running OS (Windows, macOS, Linux) as a regular application. The host OS does all the "dirty work" with the hardware, while the hypervisor simply creates virtual machines inside that OS.
This is the option for developer workstations, testers, and education. Not for production: performance is limited by the host OS, isolation is weaker, and the extra layer introduces noticeable overhead.
Examples: Oracle VirtualBox, VMware Workstation/Fusion, Parallels Desktop, QEMU without KVM.
A side-by-side comparison
| Characteristic | Type 1 (Bare-metal) | Type 2 (Hosted) |
|---|---|---|
| Where it runs | Directly on hardware, replacing the OS | As an application on top of an OS |
| VM performance | Near-native (1-5% overhead) | Depends on the implementation: 5-15% with hardware acceleration, up to 30-40% without |
| Isolation | High — at the hardware level | Depends on the host OS |
| Deployment complexity | Requires a sysadmin | Simple — like installing any app |
| Typical use | VPS, clouds, data centers, production | Development, testing, education |
| Examples | VMware ESXi, KVM, Proxmox VE, Hyper-V | VirtualBox, VMware Workstation |
ℹ️ A note about modern Type 2: the classic picture of "Type 2 = slow because of the host OS" refers to older solutions like VirtualBox without hardware acceleration, where overhead can reach 30-40%. Modern approaches look different: VirtualBox with KVM acceleration on Linux, or with the native Hypervisor framework on Mac (M1+), gives performance much closer to Type 1. WSL2 on Windows and Docker Desktop are not even formally Type 2 — they use Hyper-V (Type 1) as the foundation, running a thin Linux VM on top. So when evaluating performance, what matters isn't the Type 1/Type 2 category itself but the specific implementation and whether hardware extensions VT-x/AMD-V, EPT, and IOMMU are involved.
How a hypervisor works technically
The short version: a hypervisor uses special CPU instructions to let each VM think it has exclusive access to the hardware, while in reality they all share the same CPUs, RAM, disks, and network.
Hardware virtualization support
Since the mid-2000s, Intel and AMD processors have shipped with built-in virtualization support:
- Intel VT-x — Virtualization Technology for x86
- AMD-V — AMD Virtualization (SVM)
- Intel EPT / AMD RVI — hardware support for virtual memory, without which modern VMs simply won't run
- IOMMU (Intel VT-d / AMD-Vi) — for passing physical devices directly through to a VM (needed for GPU passthrough, NVMe passthrough)
These technologies made virtualization so efficient that overhead on modern hardware comes out to 1-5%, not the 20-30% seen in 1999. Thanks to them, Type 1 hypervisors can deliver "near-native" VM performance.
Methods of hardware access
The hypervisor has several ways to give a VM access to the hardware, from slowest to fastest:
| Method | How it works | Speed |
|---|---|---|
| Emulation | The hypervisor emulates the device entirely in software | Slow (20-50% of native) |
| Paravirtualization | The guest OS knows it's in a VM and uses optimized drivers (VirtIO) | Fast (5-15% overhead) |
| SR-IOV | A physical device (NIC, NVMe) is split into virtual functions at the hardware level | Near-native (1-3% overhead) |
| Passthrough | A physical device is handed off to a VM directly and exclusively | Native (no overhead) |
Most VPSes in 2026 use paravirtualized VirtIO drivers for disks and network — that's the best balance between speed and flexibility. Passthrough is typically used for AI workloads (GPU passthrough to Nvidia H200/B200) or high-performance NVMe databases.
Hypervisors and containers — not enemies, but complements
In today's DevOps world the question often comes up: "why VMs if there's Docker?". The answer is that they're different tools for different jobs. In 2026 there's no "VM or container" dilemma — in serious installations they work together.
How they differ
| Parameter | Virtual machine (VM) | Container (Docker) |
|---|---|---|
| OS kernel | Its own per VM | Shared with the host OS |
| Size | Gigabytes (a full OS image) | Megabytes (just the app and its dependencies) |
| Startup time | Seconds to tens of seconds | Milliseconds |
| Isolation | Strong — at the hardware level | Weaker — namespaces + cgroups |
| Different OSes | Yes — any OS on any VM | No — only Linux containers on a Linux host (without emulation) |
| Typical use | VPS hosting, full servers, legacy apps | Microservices, CI/CD, fast deploys |
How they combine in practice
Modern hosting and cloud architecture is almost always two-layered:
- At the bottom — the hypervisor (KVM, Proxmox VE, ESXi) slices the physical server into VMs, providing strong isolation between clients.
- On top — containers (Docker, Kubernetes) inside each VM slice its resources among the microservices of a single application.
This gives the best of both worlds: hard isolation between clients (via VMs) and the flexibility of microservice architecture inside each client (via containers). That's how the vast majority of modern cloud platforms work.
💡 The third option — micro-VMs: AWS Firecracker, Kata Containers, Cloud Hypervisor — these are a new class of hypervisors that launch minimal VMs in milliseconds, with the isolation of a classic VM but the startup speed of a container. They're the foundation of modern serverless platforms (AWS Lambda, Fargate). The technology is interesting for large-scale cloud providers but remains niche for typical VPS hosting.
Where hypervisors are used in 2026
VPS and VDS hosting
The most obvious and widespread use. A client gets an isolated virtual machine with dedicated resources and full root access. What you rent from any serious hosting provider is a VM on a hypervisor (usually KVM or Proxmox VE).
Public and private clouds
AWS, Google Cloud, Microsoft Azure, Oracle Cloud, DigitalOcean — these are hypervisors at gigantic scale. AWS uses a modified KVM (Nitro), Google also uses KVM, Azure uses Hyper-V. Private clouds (built on OpenStack, Nutanix, VMware Cloud Foundation) are also built on hypervisors.
Data centers and consolidation
Instead of 100 physical servers, each running at 10-20% utilization, companies virtualize the load onto 10-15 physical servers running 100 VMs. The savings on hardware, power, cooling, and data-center floor space are measured in multiples.
Development and DevOps
Local development with Vagrant + VirtualBox, testing on different OSes, reproducing the production environment on a workstation. Mostly Type 2 hypervisors here.
Edge computing and IoT
Lightweight hypervisors (often custom KVM or Xen forks) on routers, industrial controllers, edge servers — to run isolated services close to the user.
AI/ML infrastructure
Training large models often runs on bare metal without virtualization, for maximum performance. But inference, multi-tenant AI services, data-scientist dev environments — those are VMs with GPU passthrough or vGPU partitioning via Nvidia MIG.
How to choose the right hypervisor
If you're renting a VPS, the provider chooses the hypervisor for you. If you're building your own infrastructure, you have a choice. Practical recommendations:
For a typical web project or business site
Pick a VPS based on KVM or Proxmox VE. This is the industry standard: guaranteed dedicated resources, full isolation, full root access. Unlike older container-style virtualization like OpenVZ (where resources could theoretically be redistributed among neighbors), a KVM VPS gives you exactly what's on the price plan.
For projects on a Microsoft stack
Active Directory, .NET, SQL Server, Exchange — this is a scenario where Microsoft Hyper-V feels at home thanks to its tight integration with the entire Microsoft ecosystem.
For microservice architecture
Consider a KVM VPS + Docker/Kubernetes inside. The VM gives you an isolated environment; containers give you fast deploys and microservice scaling.
For very heavy workloads
If your project outgrows a VPS, pick a dedicated server with the option to install your own hypervisor (Proxmox VE), or go straight to bare metal without virtualization for maximum performance. For more on the difference, see our article "Bare Metal Servers: Uncompromising Power".
For AI/ML
VPS with GPU passthrough — for inference and light training. Bare metal with AI cards (H200, B200) — for serious large-model training.
ℹ️ Which hypervisor does your provider use? A serious host is always transparent about what its infrastructure is built on. If a plan description just says "VPS" without specifying the technology, ask support. KVM, Proxmox VE — indicators of quality. OpenVZ — outdated technology with known limitations.
🚀 VPS on KVM and Proxmox VE from Hostiserver
Hostiserver builds all of its VPS infrastructure on modern open-source hypervisors — KVM and Proxmox VE. No vendor lock-in, no risk of license changes, with guaranteed dedicated resources and full root access.
💻 Cloud (VPS) Hosting
- From $19.95/mo — KVM isolation, guaranteed dedicated vCPU and RAM
- Apex-series hardware with VT-x/AMD-V, EPT, and IOMMU hardware support
- Snapshot and cloning — instant VM state backups
- Live migration during planned maintenance without taking the site down
- API access for automation, compatibility with Terraform and Ansible
- 24/7 DevOps support — engineers who know KVM/Proxmox at architect level
🖥️ Dedicated Servers
- From $90/mo — physical server, full freedom to pick the hypervisor
- Proxmox VE preinstall — available as an option at order time
- VMware migration with engineer assistance and VM conversion
- GPU passthrough for AI/ML workloads
- 99.9% uptime SLA guaranteed in the contract
💬 Not sure which option fits you?
💬 Drop us a line and we'll help you figure it out!
Frequently asked questions
- How does KVM differ from Proxmox VE?
KVM is a hypervisor — a Linux kernel module. On its own it's managed via CLI and config files, which isn't convenient for most people. Proxmox VE is a ready platform that wraps KVM in a web interface and adds clustering, backups, network management, and ZFS/Ceph storage. So Proxmox VE uses KVM "underneath" but provides far more usable tooling. If you see "VPS on KVM," the provider is most likely using Proxmox VE or its own control panel on top of KVM.
- How much stronger is VPS isolation on a hypervisor compared with plans where resources are shared among clients without virtualization?
Fundamentally stronger. On non-virtualized plans all clients share one OS kernel and one environment — if one neighbor runs a heavy script or gets compromised, it can affect everyone. On a hypervisor-backed VPS you get your own full-featured VM with its own kernel, users, and network stack. No neighbor can either consume your resources or even see that your site exists. It's a fundamentally different level of security.
- How can I tell which hypervisor my VPS is running on?
On a Linux guest, run
dmidecode -s system-product-nameorcat /sys/class/dmi/id/product_name. Depending on the hypervisor, you'll see something like "KVM", "VMware Virtual Platform", "Microsoft Corporation Virtual Machine", or "Xen". Alsolscpu | grep Hypervisorwill show the hypervisor vendor ID (KVM, VMwareVMware, Microsoft Hv, etc.). It's worth knowing because some code optimizations depend on the platform.
- What is "VM Escape" and is it a real threat?
VM Escape is a hypothetical attack in which an attacker who has gained access to one VM breaks out of it and gains control over the hypervisor (and therefore over all other VMs on the same server). Technically such vulnerabilities exist and are occasionally found — for example, CVE-2024-22252 in VMware ESXi/Workstation/Fusion (use-after-free in the XHCI USB controller, CVSS 9.3, March 2024) or CVE-2023-46835 in Xen/Citrix Hypervisor (AMD host compromise via PCI passthrough, November 2023). But these are extremely rare events fixed in emergency patches. For a regular VPS customer this isn't a real day-to-day threat — simpler things carry much more risk: weak passwords, unpatched WordPress plugins, missing backups.
- Can I run Docker on a VPS?
Yes, fully. Modern KVM-based VPSes fully support nested virtualization, so Docker (and even Kubernetes) work inside them without restrictions. It's the standard architecture: the VPS provides isolation between clients, and Docker inside the VPS provides isolation between services for a single client.
- Does the hypervisor slow my site down?
Modern Type 1 hypervisor overhead on modern hardware (CPUs with VT-x/AMD-V, EPT, paravirtualized VirtIO drivers) is 1-5%. For websites, databases, and APIs that's irrelevant: the bottleneck is almost always not virtualization but the application code, disks, network, or database. If your site is slow, the hypervisor isn't to blame.
- Which hypervisor is better — Type 1 or Type 2?
The question isn't "which is better" but "for what". Type 1 — for production, servers, hosting. Type 2 — for a developer's laptop. Neither is "better" — they're different tools for different jobs. If you see a VPS running on a Type 2 hypervisor, that's suspicious (and it doesn't happen with serious providers).