A hypervisor is the virtualization layer that creates, runs, and isolates virtual machines on physical hardware. It presents virtual CPU, memory, storage, and networking to each guest operating system while controlling access to the underlying server.
Hypervisors make VPS and cloud VM hosting possible because one physical machine can operate multiple independent virtual servers. Each VM can boot its own operating system, run separate applications, keep its own files and users, and restart without directly controlling neighboring VMs. The hypervisor coordinates those environments beneath the guest operating systems.
There are two main categories: Type 1 hypervisors run directly on server hardware, while Type 2 hypervisors run through a host operating system. Type 1 is the normal architectural fit for production cloud and VPS infrastructure; Type 2 is commonly used for local development, desktop virtualization, testing, and training. The category explains the software layers involved, but it does not by itself prove that one hosting provider will deliver better performance or isolation than another.
For the wider server model, start with how VPS hosting works. This guide focuses specifically on the hypervisor layer and the decisions hidden behind it.
A Hypervisor Creates and Controls Virtual Machines
A physical server provides processor cores, memory, storage connections, and network interfaces. A hypervisor divides or schedules access to those resources and presents each virtual machine with a virtual hardware profile.
That profile can include:
- One or more virtual CPUs
- A defined memory allocation
- One or more virtual disks
- Virtual network interfaces
- Firmware and boot settings
- Console access
- Device and resource policies
The guest operating system sees these resources as server hardware. Linux or Windows can then boot, load drivers, create users, start services, and accept remote connections.
The hypervisor sits outside the guest operating system. A user with root or administrator access inside a VM can control the guest OS and its applications, but that access does not normally provide control over the physical host or other virtual machines.
The hypervisor also manages VM lifecycle operations. Depending on the platform, it can create, start, stop, pause, restart, snapshot, clone, resize, or move virtual machines. Customers may trigger some of these actions from a dashboard or API, while the provider operates the host-level systems beneath them.
A simplified model looks like this:
Physical server resources ↓ Hypervisor ↓ VM 1 VM 2 VM 3 Linux Linux Windows
This is the central role of a hypervisor: turn physical capacity into separately controlled virtual machines without requiring one physical server for every operating system.
Host and Guest Systems Have Different Roles
Virtualization uses the terms host and guest to describe different layers.
The host is the physical machine and host-level virtualization environment that provides the underlying resources. It includes the processors, memory, storage connectivity, network interfaces, and the software responsible for running virtual machines.
The guest is the operating system running inside a VM. A guest may be Linux, Windows, or another supported operating system. It sees virtual hardware rather than directly controlling the provider’s physical devices.
The distinction matters because responsibilities are divided across the boundary.
| Layer | Typical responsibility |
|---|---|
| Physical host | Hardware health, capacity, power, physical networking |
| Hypervisor | VM creation, scheduling, isolation, virtual devices, lifecycle |
| Guest operating system | Users, packages, services, firewall, updates, files |
| Application | Code, runtime configuration, data, dependencies, monitoring |
In an unmanaged VPS service, the provider generally owns the first two layers while the customer owns the guest operating system and application layers. A managed service may move some guest-level responsibilities to the provider, but the scope must be verified separately.
This boundary explains why a VPS customer can reinstall an operating system or change a firewall rule without reconfiguring the physical host. It also explains why the customer cannot normally decide how other VMs are placed or how the provider maintains host hardware.
Type 1 Hypervisors Run Directly on Server Hardware
A Type 1 hypervisor is commonly called a bare-metal hypervisor. It operates directly on the physical server at the virtualization layer instead of depending on a general-purpose desktop operating system beneath it.
The architecture is typically represented as:
Physical hardware ↓ Type 1 hypervisor ↓ Guest VMs
Type 1 hypervisors are the normal fit for data centers, cloud platforms, VPS hosting, enterprise server consolidation, and other multi-tenant production environments.
They are used in these settings because the virtualization layer can manage physical resources and VM isolation as a primary system function. The provider can operate many virtual machines across a fleet of servers while applying scheduling, placement, networking, storage, monitoring, and recovery policies at the infrastructure level.
Common Type 1 characteristics include:
- Direct host-level control of compute resources
- Support for many concurrent VMs
- Centralized VM lifecycle management
- Production monitoring and automation
- Live maintenance or migration capabilities, depending on the platform
- Strong separation between guest operating systems
- Integration with provider networking and storage systems
“Bare metal” does not mean the customer owns the physical server. It describes where the hypervisor sits in the software stack. Multiple customers can still run VMs on the same host unless the service explicitly provides dedicated hardware.
Type 1 also does not guarantee perfect performance. Host capacity, CPU allocation, storage design, networking, provider operations, and contention policy still matter. A well-operated Type 1 platform can deliver strong consistency, while poor capacity planning can still create degraded service.
Type 2 Hypervisors Run Through a Host Operating System
A Type 2 hypervisor is commonly called a hosted hypervisor. It runs as software on top of a conventional host operating system.
The architecture is typically represented as:
Physical hardware ↓ Host operating system ↓ Type 2 hypervisor application ↓ Guest VMs
This model is convenient for laptops, workstations, local development, training labs, compatibility testing, and running a second operating system without dedicating a separate machine.
For example, a developer may use a Type 2 hypervisor to run a Linux guest on a desktop computer, test an application in a clean environment, or reproduce a customer configuration locally.
Common Type 2 characteristics include:
- Straightforward installation on an existing computer
- Easy access to host desktop devices and files
- Good fit for testing and learning
- Dependence on the host operating system
- Additional software layers between the guest and hardware
- Lower suitability for large multi-tenant cloud infrastructure
The host operating system remains responsible for many device drivers, processes, updates, and desktop services. The hypervisor application requests resources through that OS and then presents virtual hardware to the guest.
Type 2 is not automatically insecure or unusable for important work. It is simply optimized for a different operating model. It prioritizes convenience and compatibility on an existing host rather than large-scale production VM hosting.
Type 1 vs Type 2 Hypervisors Serve Different Environments
The main difference is where the hypervisor operates in relation to the physical hardware and host operating system.
| Factor | Type 1 hypervisor | Type 2 hypervisor |
|---|---|---|
| Position in stack | Directly on server hardware | Above a host operating system |
| Common name | Bare-metal hypervisor | Hosted hypervisor |
| Primary environment | Data center and production infrastructure | Desktop, laptop, test, and lab environments |
| Typical scale | Many centrally managed VMs | A smaller number of local VMs |
| Host OS dependency | No general-purpose host OS beneath guest VMs | Depends on the host operating system |
| Operational focus | Availability, isolation, automation, fleet management | Convenience, local access, compatibility |
| Typical VPS use | Strong fit | Not the normal hosting architecture |
| Typical developer use | Remote infrastructure or private lab | Local testing and development |
The comparison should not be reduced to “Type 1 is good and Type 2 is bad.” Each solves a different problem.
Type 1 is appropriate when virtualization is the primary purpose of the physical server. Type 2 is appropriate when virtualization is one application running on an existing computer.
Use Type 1 for production infrastructure
Type 1 is the stronger fit when the environment must operate many VMs, enforce tenant boundaries, automate lifecycle actions, integrate with data-center networking and storage, or support continuous provider operations.
Use Type 2 for local flexibility
Type 2 is the stronger fit when a person needs to run another operating system on a laptop or workstation without replacing the host OS. It is useful for software testing, security labs, demonstrations, education, and development environments.
Hypervisors Allocate Resources in Different Ways
A hypervisor presents resources to each VM, but CPU, memory, storage, and networking are not allocated in identical ways.
Virtual CPU is scheduled onto physical compute
A vCPU is a processor execution resource presented to the guest operating system. The guest schedules application threads onto its vCPUs, while the hypervisor schedules those vCPUs onto physical processor capacity.
Shared CPU plans allow multiple VMs to use a common compute pool over time. Dedicated CPU plans provide a more exclusive or reserved allocation. The precise meaning depends on the provider’s service definition.
For the buying decision, see shared vs dedicated vCPU. Hypervisor type alone does not reveal whether a VM receives shared or dedicated CPU.
Memory is mapped to the guest VM
The hypervisor assigns a memory limit or reservation to each VM and maps guest memory operations to physical host memory.
The guest operating system then uses that allocation for its kernel, applications, caches, processes, and filesystem activity. The provider’s host-level memory policy affects how confidently the advertised amount remains available under load.
Virtual disks connect guests to persistent storage
The guest sees a virtual disk device. The hypervisor and provider storage layer connect that device to persistent storage beneath the VM.
The disk may be backed by local devices, shared storage, or a distributed platform. From the customer’s perspective, the important characteristics are durability, latency, throughput, capacity, expansion, snapshot behavior, and backup options.
Virtual networks connect VMs to provider infrastructure
The hypervisor presents virtual network interfaces to the guest. Provider networking then connects those interfaces to public IP addresses, private networks, gateways, firewalls, or other services.
The guest controls its own operating-system network configuration, while the provider controls the wider host and data-center network.
Hypervisor Isolation Has Defined Boundaries
A hypervisor is responsible for keeping virtual machines logically separated. Each guest normally has its own memory space, virtual devices, operating system, processes, users, filesystem, and network identity.
This isolation means one VM cannot normally inspect another VM’s files, restart its operating system, or change its application configuration.
However, isolation does not mean every lower-level component is physically dedicated. Several VMs can still use the same physical processors, storage platform, network links, and host hardware.
The distinction is important:
Hypervisor isolation separates operating environments; resource allocation determines how much lower-level capacity is shared or reserved.
A dedicated CPU allocation can reduce compute contention, but it does not automatically provide a dedicated storage array or network connection. A provider may also use shared infrastructure while maintaining strong guest isolation and predictable service through capacity controls.
Security depends on more than the existence of a hypervisor. Buyers should also evaluate:
- Host and platform patching
- Access controls
- Guest update responsibility
- Firewall and network policy
- Console security
- Backup and restore design
- Monitoring and incident response
- Provider capacity and operational discipline
The cloud security fundamentals guide covers the broader control model beyond virtualization isolation.
Hypervisors and Containers Solve Different Problems
Virtual machines and containers both isolate workloads, but they operate at different layers.
A hypervisor creates virtual machines with separate guest operating systems. Each VM includes its own kernel and virtual hardware environment.
A container runtime isolates application processes while sharing the host operating-system kernel. Containers package applications and dependencies more lightly, but they do not create a full independent hardware environment in the same way as a VM.
| Factor | Virtual machine | Container |
|---|---|---|
| Isolation layer | Virtual hardware and guest OS | Process and operating-system level |
| Kernel | Separate guest kernel | Shared host kernel |
| Boot behavior | Boots an operating system | Starts an isolated process environment |
| Overhead | Higher | Lower |
| OS flexibility | Can run different supported guest operating systems | Must be compatible with the host kernel model |
| Typical use | VPS, cloud VM, strong workload boundaries | Application packaging and deployment |
The two models are often combined. A cloud provider creates a VM through a hypervisor, and the customer runs containers inside that VM. This gives the customer an isolated server boundary while retaining container-based application deployment.
Use a Hypervisor Decision Framework in the Right Context
Most VPS buyers do not select or install the provider’s hypervisor. They choose a service whose virtualization layer meets their requirements.
The decision therefore depends on who controls the infrastructure.
| Situation | Relevant decision | Recommended focus |
|---|---|---|
| Buying VPS or cloud VM hosting | Provider controls hypervisor | Resource guarantees, isolation, availability, recovery, support |
| Building a production private cloud | Your team controls infrastructure | Type 1 architecture, automation, networking, storage, operations |
| Running local test VMs | Individual controls workstation | Type 2 convenience, host compatibility, device access |
| Creating a training lab | Team controls lab environment | Ease of setup, repeatability, isolation requirements |
| Consolidating physical servers | Infrastructure team controls hosts | Type 1 capacity, migration, monitoring, failure domains |
| Running containers | Application team controls deployment | VM boundary, container runtime, kernel and security model |
For a hosting buyer, ask these questions instead of requesting a hypervisor brand:
- Are CPU resources shared or dedicated?
- Is the advertised memory allocation guaranteed?
- How are storage performance and durability described?
- What networking and bandwidth policies apply?
- What isolation and security responsibilities belong to the provider?
- How are backups, snapshots, resizing, and recovery handled?
- What uptime and support commitments apply?
A hypervisor name may provide technical context, but it does not replace answers to these service questions.