Paravirtualization is a technique where the guest operating system knows it runs in a virtual machine. It talks to the hypervisor directly, instead of acting as if it owns real hardware. Full virtualization runs an unmodified guest and hides the hypervisor from it. Hardware-assisted virtualization uses CPU features (Intel VT-x, AMD-V) to make full virtualization fast. Today most VMs use hardware assistance for the CPU and paravirtualized drivers, such as virtio, for disk and network.
Updated October 2026. This guide replaces the 2012 version with current tools and a home lab focus.
Who this is for: you run VMs in a home lab or a small team. You keep seeing terms like "PV", "HVM" and "virtio" in settings menus. You want to know what they mean and which to pick.
The problem these techniques solve
A hypervisor must stay in control of the real hardware. The guest OS kernel expects to control it too. So the hypervisor must catch every sensitive instruction the guest kernel runs, and handle it safely.
On many CPU designs, this is simple. A sensitive instruction run with too little privilege causes a trap, and the hypervisor steps in. The older x86 design did not work this way. The 2003 paper "Xen and the Art of Virtualization" from the University of Cambridge states the issue plainly. Support for full virtualization was never part of the x86 design. Some supervisor instructions fail silently when run without enough privilege, instead of causing a trap.
Three answers came out of that problem. Each one is still visible in the tools you use today.
Full virtualization with binary translation
Full virtualization means the guest OS runs unmodified. You install a stock copy of Windows or Linux, and it never learns it is in a VM. The hypervisor presents a complete virtual machine that looks like real hardware.
Before CPUs helped, x86 hypervisors did this in software. The Xen paper describes how VMware's ESX Server worked at the time. It rewrote parts of the guest's machine code on the fly to insert traps where the hypervisor had to step in. This is called binary translation. ESX Server also kept "shadow" copies of structures such as page tables, and trapped each attempt to change them.
The benefit is clear: any OS runs as it is. The cost is complexity and overhead. The hypervisor must translate guest kernel code. Work that updates page tables often, such as starting new processes, suffers the most.
What is paravirtualization?
Paravirtualization takes the opposite path. Instead of hiding the hypervisor, it changes the guest kernel so it cooperates. The guest calls the hypervisor directly (these calls are often named hypercalls) for privileged jobs such as page table updates. Nothing has to be caught or rewritten.
Xen made this approach well known. The 2003 Xen paper says paravirtualization was needed for high performance and strong isolation on x86. It also notes the price. The guest OS must be modified, but applications do not need to change, because the application binary interface stays the same. The Xen team ran a modified Linux (XenoLinux) and reported that a Windows XP port was in progress at the time.
That trade-off is the main weakness. VMware's 2007 white paper, "Understanding Full Virtualization, Paravirtualization, and Hardware Assist", names the problem. Paravirtualization needs guest OS changes, which make the guest depend on one specific hypervisor. Open-source kernels could be changed. Closed-source ones were harder.
Paravirtualization today: drivers, not kernels
Fully paravirtualized kernels are now uncommon. The idea lives on in a narrower form: paravirtualized devices. The guest uses a normal kernel, but it loads special drivers for disk, network and memory that know they talk to a hypervisor.
On KVM, QEMU and Proxmox, these drivers are called virtio. The Linux kernel documentation says virtio was first developed as a standard for paravirtualized devices that a hypervisor provides. The OASIS standards body publishes the specification. VIRTIO 1.0 was first approved as an OASIS Committee Specification in August 2014. You can read the VIRTIO 1.0 specification (the March 2016 revision). Newer versions exist, so check the OASIS site for the latest one.
Why it matters in a home lab: an emulated device copies the behavior of real hardware, such as an old Intel network card. That is slow, because the hypervisor must fake every register. A virtio device skips the act and uses a simple shared-memory channel. Linux guests include virtio drivers. Windows guests do not. The Proxmox wiki on Windows VirtIO drivers explains how to load them from the virtio-win ISO, as of October 2026.
Hardware-assisted virtualization
The third answer moved the hard part into the CPU. Intel added VT-x and AMD added AMD-V. These features give the hypervisor its own CPU mode. The guest kernel runs directly on the CPU, and the CPU itself hands control to the hypervisor when a sensitive event happens. No code rewriting and no guest changes are needed.
A second wave of features fixed memory overhead. Intel Extended Page Tables (EPT) and AMD Nested Page Tables (NPT, also called RVI) let the CPU translate guest memory addresses in hardware. The hypervisor no longer needs shadow page tables for every guest.
Hardware assistance is now the default. KVM, Hyper-V, current VMware products and VirtualBox all rely on it. Most of them will not start a 64-bit VM without it. If yours complains, read how to enable virtualization in BIOS.
The modern mix
Today the techniques are not rivals. A typical VM combines them:
- CPU and memory: hardware-assisted (VT-x or AMD-V, with EPT or NPT).
- Disk and network: paravirtualized (virtio, or the hypervisor's own equivalent).
- Boot and legacy devices: emulated, for compatibility during install.
Xen shows the same shift. Its PVH guest type first appeared in Xen 4.4. The current design, PVH version 2, became a supported guest type in Xen 4.10. It uses hardware virtualization for the CPU and memory, paravirtualized drivers for I/O, and no QEMU device emulator. It mixes the best parts of the old PV and HVM modes.
Full virtualization vs paravirtualization: side by side
| Point | Full (binary translation) | Paravirtualization | Hardware-assisted |
|---|---|---|---|
| Guest OS changes | None | Kernel or drivers modified | None |
| Needs CPU features | No | No | Yes (VT-x or AMD-V) |
| How sensitive work is caught | Hypervisor rewrites guest code | Guest calls the hypervisor | CPU traps to the hypervisor |
| Main cost | Complexity and overhead | Guest tied to one hypervisor | Needs a modern CPU |
| Where you see it today | Mostly historical on x86 | virtio and similar drivers | Almost every VM |
Two related techniques
OS-level virtualization
OS-level virtualization does not create virtual hardware at all. The host kernel splits itself into isolated user spaces. Containers (LXC, Docker, Podman) work this way. There is no guest kernel, so none of the three techniques above apply. For when to use one or the other, read containers vs virtual machines. For where this sits among all the other kinds, see the guide to types of virtualization.
Nested virtualization
Nested virtualization runs a hypervisor inside a VM. You might run Proxmox inside VirtualBox to learn it, or test Hyper-V inside a Hyper-V VM. The outer hypervisor must expose VT-x or AMD-V to the guest. Without that, the inner hypervisor falls back to slow emulation or refuses to start.
On Linux KVM, the kernel documentation on nested guests says nesting has been on by default since kernel 4.20. A distribution can override that. Nested VMs run slower than VMs on bare metal, so use them to learn and test, not for production. For the commands to check and enable it on Hyper-V, KVM and Proxmox, see how to enable virtualization.
What this means for your settings
You rarely pick a technique by name anymore. You pick device types. Here is a practical guide for KVM and Proxmox:
- Linux guests: use VirtIO SCSI for disks and VirtIO for the network card. The drivers are already in the kernel.
- Windows guests: attach the virtio-win ISO during install, load the storage driver, then switch the network to VirtIO.
- Old or odd guests: use emulated devices (IDE or SATA disk, Intel E1000 network) if the OS has no virtio drivers.
- CPU type: "host" passes the full CPU feature set to the VM. It is the simplest way to allow nested virtualization. A generic type helps when you plan to live-migrate VMs between different CPUs.
Common mistakes
- Installing Windows on a VirtIO disk with no driver. The installer sees no disk. Load the driver from the virtio-win ISO first.
- Leaving emulated devices in place after install. They work, but they waste CPU time. Switch to VirtIO once the drivers are in.
- Thinking paravirtualization is obsolete. Full PV kernels are rare. PV drivers are everywhere.
- Running a hypervisor in a VM without exposing VT-x or AMD-V. Set the CPU type and nesting first.
- Calling containers "paravirtualization". Containers share the host kernel. They are OS-level virtualization.
For how the hypervisor assigns CPU, memory, disk and network to each VM, read what a hypervisor is, type 1 vs type 2.
FAQ
What is paravirtualization in simple terms?
It is a method where the guest OS knows it runs in a VM and asks the hypervisor for help directly. This avoids the work of catching and translating sensitive instructions. Today it mostly appears as paravirtualized drivers, such as virtio.
What is the difference between full virtualization and paravirtualization?
Full virtualization runs an unmodified guest that does not know it is virtual. Paravirtualization modifies the guest, or its drivers, so it cooperates with the hypervisor. Full virtualization runs any OS. Paravirtualization trades that freedom for less overhead.
Is KVM full virtualization or paravirtualization?
Both. KVM uses hardware-assisted full virtualization for the CPU and memory. It then uses virtio paravirtualized drivers for disk and network when the guest has them.
Is hardware-assisted virtualization the same as full virtualization?
It is a way to do full virtualization. The guest still runs unmodified. The difference is that the CPU, not software rewriting, catches the sensitive instructions.
Does Xen still use paravirtualization?
Xen still supports PV guests. It also offers HVM and PVH guests, which use hardware virtualization with PV drivers. Check the Xen Project docs for which modes your version supports.
Do containers use paravirtualization?
No. Containers share the host kernel and have no virtual hardware. They are a form of OS-level virtualization.
