Running virtual machines on linux can involve a lot of different components, from hardware features to kernel primitives and userspace tooling. Since this article is specifically aimed at open source virtualization within the linux ecosystem, it excludes options like vmware, hyper-v or bhyve, as well as iaas/private cloud solutions like OpenNebula or OpenStack.
Hypervisors
A hypervisor is the lowest software primitive in virtualization, providing a coherent API for the different underlying hardware features and kernel resources. It abstracts away vendor-specific implementation differences, so Intel-VT/VT-x and AMD-V/SVM machines can be used with the same interface to create virtual CPUs, without needing to know which one is actually doing the work.
While hardware-accelerated hypervisors like xen, kvm and virtualbox can use a vast list of hardware virtualization features for better isolation, PCI/storage acceleration or PCI passthrough, only CPU hardware virtualization support is required to run them, anything else is optional.
Software-only hypervisors ("emulators") like qemu do not require any hardware support.
In linux environments, the KVM API built directly into the kernel is easily the most well-known hypervisor. It requires no additional drivers or setup planning, and ships by default with nearly any modern linux distribution.
A little lesser known is the xen hypervisor, which instead works as a thin operating system layer underneath other operating systems. It allows creating a privileged virtualized guest called dom0 (usually linux, but can be any OS) that can interact with the hypervisor underneath using xl/libxl to add more guests that sit alongside it. The main advantage is that the virtualization host has significantly reduced error surface, as it will continue to work even if the managing dom0 guest crashes.
The virtualbox kernel module is also a hypervisor, but commonly overlooked in comparisons. Virtualbox is open source, but uses its own virtualization ecosystem, not relying on existing hypervisors or tooling and instead providing their own alternatives.
Lastly, Qemu ("Quick Emulator") is the odd one out here, because it is focusing on hardware emulation rather than virtualization. However, it can emulate an entire CPU and use it to offer hypervisor capabilities in environments without hardware support, earning its place in the hypervisor list. This is slow but works in any linux environment, including running entirely in userspace without elevated privileges, kernel features or hardware support. It can even emulate foreign architecture, for example by emulating an ARM cpu on an x86 host machine. Using qemu as a hypervisor is a great fit for testing/development environments, but performs poorly for production workloads.
Type-1 and type-2 hypervisors
You may have seen claims around "type-1" and "type-2" hypervisors in conversations around virtualization. They describe the relationship between hypervisor and hardware access: A type-1 or "bare-metal" hypervisor sits directly on top of the hardware layer, while a type-2 "hosted" hypervisor reaches the hardware through an existing operating system.
Especially terms like "bare-metal" can be confusing here, since hypervisor types do not distinguish hardware virtualization features - both require real virtualization hardware support underneath. They only describe how many software layers sit between the hypervisor and said hardware support, marginally useful to evaluate attack surface but entirely useless for performance comparisons.
The distinction between hypervisor types has become borderline impossible in the modern virtualization landscape, as tools do not map cleanly onto either type anymore:
The hypervisor for xen stays cleanly within the type-1 definition as it is the layer below managing operating systems, while virtualbox maps directly to type-2 because it uses a kernel module to reach the hardware acceleration features.
KVM could arguably be both, as it is the operating system/kernel layer and uses other kernel features. It is now mostly considered type-1 because it is built into the kernel which sits directly on top of the hardware layer, but technically arguments could be made for type-2 since KVM requires a host operating system to be installed, so the type-2 attack surface applies.
Qemu in software emulated CPU mode is technically neither type-1 nor type-2 because it has no underlying hardware layer to reach, so cannot count the layers inbetween. If you made the argument that virtual hardware counts, it would be type-0 because it is the hardware layer itself, which is absurd in its own right.
You should not use type-1 or type-2 as meaningful distinguishing categories for modern hypervisors anymore.
Virtual machine managers
A virtual machine manager offers simple virtual machine processes and device emulation on top of hypervisor interfaces.
You can think of virtual machine manager as a program that ties hypervisor primitives (cpu, memory, ...) together with emulating devices (storage disks, network interfaces, ...) and support for virtual disk formats (qcow2, ova/ovf, ...) to create and run a virtual machine as a process. This process is notably stateless, meaning the "virtual machine" does not persist across guest crashes or host reboots, and only couples resources together as long as it is actively running.
While virtualbox again ships its own builtin solution that relies on hardware capabilities, every other stack uses qemu ("Quick Emulator") for this task.
Qemu offers a broad set of emulation capabilities and can integrate with hypervisors like kvm or xen, but also emulate an entire CPU and use itself as a hypervisor for it.
When combined with other hypervisors, qemu mostly exposes emulated devices like storage and audio controllers, graphics devices and network interfaces. It can work with common virtual disk formats like qcow2 to provide emulated disks and handles the tasks of combining all these resources into a running virtual machine process, editing that configuration at runtime and stopping / removing it later.
Since qemu handles device emulation, it can run entirely in userspace, without elevated privileges or kernel access, which heavily reduces the attack surface in case guests manage to escape the device emulation.
HVM, paravirtualization and passthrough
Virtualization can take one of three forms: the first is hardware assisted/accelerated virtualization or HVM ("Hardware Virtual Machine"), where isolation between guest and host are handled by physical hardware features directly. Where hardware does not offer such capabilities (especially for network cards and storage drives), the behavior of real hardware must be emulated. Emulation has significant overhead, as it for example needs to recreate the behavior of memory registers and physical circuits in software alone.
Hardware virtualization combined with device emulation has the primary benefit that the guest operating system sees its hardware as normal physical devices and typically needs no additional drivers to use it.
The alternative to emulating exact physical device behavior is called paravirtualization, where the guest is expected to know it is running on virtual hardware and uses drivers that talk directly to a host API rather than pretending to be real hardware, resulting in near zero overhead compared to emulation. This approach requires guests to install special drivers like virtio on kvm, xen frontend drivers on xen and virtualbox-guest-additions for VirtualBox.
Passthrough on the other hand simply exposes a raw device from the host directly inside a guest vm, without adding any isolation layers in between. Passing devices to guests directly means it is only available to that one guest instance, not the host or any other virtual machine. PCI passthrough is the most common use for this mechanism, often to pass direct GPU access to guests running machine learning or computer vision workloads.
Modern virtualization environments typically rely on hardware virtualization for cpu and memory, paravirtualization for networking and storage, and pci passthrough in special cases where devices like GPUs need to be directly accessible inside guests.
VM lifecycle managers
The actual user interface that end users or administrators use are vm lifecycle managers, and optimize for different tradeoffs and use cases.
They extend virtual machine managers like qemu with usability features like saving the composition of virtual machines, so they remember which devices, virtual hardware and configuration were used across host reboots. Virtual machines can be snapshotted, exported or imported, and typically some kind of support for (external) highly available storage options like NFS, Linstor or CEPH is built in.
Lifecycle managers ease the actual operation of virtual machines through automation (automatic restart on crash, autostart on host boot), availability (import/export, snapshots, migrate between hosts) and reproducibility (stored exact config+metadata for each vm).
Most commonly known in this category is the libvirt ecosystem, with its virsh/virt-* terminal command suite and the virt-manager GUI application. Libvirt can work with many virtualization stacks (including closed source options), but for open source linux stacks you will typically see either kvm/xen coupled with qemu. Operating libvirt directly can be challenging, as commands have a steep learning curve and configuration is stored as XML that still needs to be edited by hand at times. Libvirt is specifically aimed at managing local virtual machines, with no direct clustering (but support for external HA storage and vm migration across libvirt hosts).
In modern systems, incus (community fork of LXD) is becoming more and more popular as a libvirt replacement, using qemu and kvm directly without support for other hypervisors. It is extremely intuitive to use and stores instance configuration in yaml format, which rarely (if ever) has to be edited by hand. It further includes native clustering and self-healing support, multi-user projects with resource restrictions, default configuration profiles and can run OCI containers and system containers (successor to LXC containers) with identical commands.
Virtualbox also includes a lifecycle manager, accessible through the vbox* terminal commands and a graphical user interface. Virtualbox only uses its own components and is designed for single-host use only, offering no ability to scale horizontally or use external storage at all. It is more focused on consumer use than production workloads, reducing operational complexity by eliminating flexibility.
Some solutions aimed at clustering ship their own virtual machine manager implementations, most notably Proxmox VE ("Virtual Environment) backed by kvm, xcp-ng relying on the xen hypervisor. Both use qemu for device emulation.
Clustering solutions
Virtualization for production workloads generally requires a solution that bundles the many virtualization components into a coherent solution that can scale across multiple hosts and includes features for migrating instances across hosts, highly available deployments and typically a web based interface with multi-user access and some form of roles or permissions built in.
There are two broad categories of clustering solutions. The first are service based, meaning they run as a service on a host linux operating system and do not restrict access to the host. These include incus using kvm/qemu directly, and ovirt relying on libvirt underneath. The main benefit of these tools is their use of standardized tooling and retained access to the host machines, preventing vendor lock-in and allowing use in hyperconverged setups, for example by using nodes as virtualization hosts and storage nodes at the same time.
The second category are turnkey linux distributions, providing a locked-down operating system preconfigured for easy cluster creation and maintenance. These include Proxmox VE ("Virtual Environment") for qemu/kvm and xcp-ng for qemu/xen, as well as the immutable incusOS distribution with builtin incus daemon and web ui. Using turnkey solutions means dramatically simpler operations at the cost of some vendor lock-in and loss of control over the underlying host machines. Small to medium companies often favor these deployment types, as relatively inexperienced staff can operate them without steep learning curves or high risk.
Note that cloud-like offerings covering more than simple virtualization needs like software defined networking, block storage and more are excluded from this list for brevity.