libvirt

A stable API, daemon and virsh command line for managing virtual machines, storage and networks, with drivers for QEMU/KVM, Xen, LXC, Cloud Hypervisor, VMware ESX, Hyper-V and more.

What it is: Hypervisors
Used for: Virtual machines
Type: Open source
Made by: libvirt project (started at Red Hat)
License: LGPL 2.1 or later (library); some tools GPL 2.0 or later
Facts checked: 11 October 2026

What it is

libvirt sits between management tools and hypervisors. A program, or the virsh shell, opens a connection with a URI that names a driver and an instance: qemu:///system reaches the root-owned daemon that runs server VMs with access to host devices and networks, qemu:///session a per-user daemon whose VMs have only that user’s privileges, qemu+ssh://host/system the same on another machine, and test:///default an in-memory fake driver for trying the API. The documented hypervisor drivers are QEMU/KVM/HVF, Xen, LXC, Cloud Hypervisor, bhyve, VirtualBox, VMware ESX and Workstation/Player, Microsoft Hyper-V, OpenVZ and Virtuozzo. Most run inside a libvirt daemon on the host; the ESX and Hyper-V drivers instead run in the client and talk to the vSphere SOAP API or to WS-Management over HTTPS.

A VM is a domain, described in XML: <domain type='kvm'> (or qemu, xen, hvf), its vCPUs, memory, disks, network interfaces and consoles. virsh define stores the definition and virsh start runs it. For QEMU, libvirt turns the XML into a QEMU command line, starts the process, and then controls it over QMP, QEMU’s JSON protocol. Around domains, libvirt manages storage pools (directories, LVM, NFS, iSCSI, Ceph RBD, ZFS and more), split into volumes that become guest disks, and virtual networks in NAT, routed, open or isolated modes with DHCP and DNS. The original single daemon, libvirtd, is being replaced by one daemon per driver: virtqemud, virtxend, virtlxcd, virtnetworkd, virtstoraged and others.

The C library is LGPL 2.1 or later, with official bindings for Python, Go, Perl, Java, OCaml, PHP, Ruby and C#. Releases come out on the 1st of each month (11 a year), and the version number tracks time, not features: 12.0.0 came out in January 2026 and the latest is 12.8.0 (October 1, 2026). It is the layer under virt-manager, OpenStack Nova’s default libvirt driver and KubeVirt, where every VM pod runs its own libvirt daemon.

Why teams pick it

One API and one XML format for many hypervisors, with an API and ABI the project guarantees to keep stable forever
More than VMs: storage pools, virtual networks, firewall filters, host device and secret management, snapshots and live migration through the same API
Remote management built in, over SSH or TLS, plus a read-only socket for monitoring tools
The common foundation of the Linux virtualization stack: virt-manager, OpenStack Nova and KubeVirt all use it, and bindings exist for most languages

Watch out for

Drivers are uneven: the ESX driver’s documentation still names ESX 3.5 to 5.x, and the Hyper-V driver is client-side only and can’t use libvirt’s remote transport
Manages one host at a time: there is no scheduler or cluster view, so fleets need a platform such as OpenStack or KubeVirt on top
A read-write connection to a system-mode daemon is equivalent to a root shell, so access must be locked down
Two deployment styles coexist while the monolithic libvirtd gives way to modular daemons, which changes the services and config files a host needs

Alternatives

What all hypervisors have in common →

Cloud HypervisorOpen sourceA Rust virtual machine monitor for modern cloud VMs on KVM or Microsoft’s hypervisor: virtio devices only, plus hotplug, VFIO passthrough, live migration, snapshots and Windows guests.KVM (Kernel-based Virtual Machine)Open sourceThe hypervisor built into the Linux kernel: it runs guest code directly on the CPU through `/dev/kvm`, and leaves device emulation to a user-space program such as QEMU or Firecracker.

Microsoft Hyper-VCommercialMicrosoft’s type-1 hypervisor, built into Windows Server and Windows 10 and 11 Pro and Enterprise: a thin hypervisor under a Windows root partition, which also underpins Azure’s hypervisor and Windows features like VBS, WSL 2 and Windows Sandbox.

Oracle VirtualBoxOpen sourceOracle’s free, open-source desktop hypervisor: a type-2 hypervisor that runs VMs as an application on Windows, macOS, Linux and Solaris, scriptable with `VBoxManage` and the default provider for Vagrant.

Proxmox Virtual EnvironmentOpen sourceA Debian-based server platform from Vienna that runs KVM virtual machines and LXC containers, with clustering, high availability, Ceph and ZFS storage, backups and a web interface in one free ISO.

QEMUOpen sourceThe open-source machine emulator and virtualizer: it emulates whole computers in software, or runs them at native speed on a hypervisor such as KVM, and supplies the virtual devices either way.

VMware ESXiCommercialVMware’s bare-metal hypervisor (called ESX again since VCF 9), whose own kernel runs VMs directly on servers while vCenter adds vMotion, HA, DRS and vSAN; since Broadcom bought VMware in 2023 it is sold only as per-core subscriptions.

Xen Project hypervisorOpen sourceThe open-source type-1 hypervisor from Cambridge that ran the first Amazon EC2 instances: a small microkernel-style core that boots first, with drivers and management in a privileged VM called dom0.

How it fits with other technologies

What libvirt uses

Define and start a VM as a normal user with `qemu:///session` (libvirt 11.3.0 and QEMU 10.0.13 in a Debian 13 container; no KVM, so `type='qemu'`, software emulation) · bash

virsh -c test:///default list --all      # the built-in fake driver needs no hypervisor
#  Id   Name   State
# ----------------------
#  1    test   running

cat > cirros.xml <<'EOF'
<domain type='qemu'>
  <name>cirros</name>
  <memory unit='MiB'>256</memory>
  <vcpu>1</vcpu>
  <os><type arch='x86_64' machine='q35'>hvm</type></os>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/home/dev/cirros.qcow2'/>
      <target dev='vda' bus='virtio'/>
    </disk>
    <interface type='user'><model type='virtio'/></interface>
    <serial type='pty'/>
    <console type='pty'/>
  </devices>
</domain>
EOF
qemu-img create -q -f qcow2 -b cirros-0.6.2-x86_64-disk.img -F qcow2 cirros.qcow2 1G

virsh -c qemu:///session define cirros.xml
# Domain 'cirros' defined from cirros.xml
virsh -c qemu:///session start cirros
# Domain 'cirros' started
virsh -c qemu:///session list --all
#  Id   Name     State
# ------------------------
#  1    cirros   running
virsh -c qemu:///session dominfo cirros
# OS Type:        hvm
# State:          running
# CPU(s):         1
# Max memory:     262144 KiB
# Persistent:     yes

virsh -c qemu:///session qemu-monitor-command cirros --pretty '{"execute":"query-status"}'
# { "return": { "status": "running", "running": true }, "id": "libvirt-478" }
# The QEMU process libvirt started: qemu-system-x86_64 -name guest=cirros ...
#   -machine pc-q35-10.0,... -accel tcg ... -mon chardev=charmonitor,id=monitor,mode=control ...

Hypervisor drivers and their connection URIs#

A few of the drivers listed in libvirt’s documentation, with the URI a client uses to reach each one.

QEMU/KVM

qemu:///system, qemu:///session

Runs QEMU processes, with KVM acceleration on Linux or HVF on macOS, in system or session mode, served by virtqemud.

Xen

xen:///system

Manages VMs on the Xen hypervisor, in system mode only, through virtxend.

LXC

lxc:///system

Runs Linux containers, isolated with namespaces and limited with cgroups, through the same API, served by virtlxcd.

Cloud Hypervisor

ch:///system, ch:///session

Manages VMs on the Cloud Hypervisor VMM; recent releases added disk and NIC hotplug and SEV-SNP guests.

VMware ESX

esx://host, vpx://vcenter

Client-side: talks to ESX(i) or vCenter over the SOAP-based vSphere API, with nothing installed on the server.

Microsoft Hyper-V

hyperv://host

Client-side: talks to Hyper-V 2012 R2 and newer over WS-Management (HTTPS or HTTP).

See it in a real stack

No architecture uses libvirt yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2005–2026

In 2005 Xen had brought virtualization to open-source systems, managed through its own daemon, xend. On November 2, 2005, Daniel Veillard at Red Hat made the first commit of a small C library to give programs a stable API to Xen. It was called libxen, then libvir, and in February 2006 it was renamed libvirt. Version 0.0.1 came out on December 19, 2005.

That goal became real in February 2007, when Daniel P. Berrangé added QEMU support, released in 0.2.0, just as KVM was arriving in Linux. Drivers for LXC, VirtualBox, VMware ESX, Hyper-V, bhyve and Cloud Hypervisor followed, along with storage pools, virtual networks and remote access, so desktop tools like virt-manager and cloud platforms like OpenStack could manage VMs without knowing each hypervisor’s details.

libvirt 1.0.0 shipped in November 2012. From 2.0.0 in July 2016 version numbers became time-based, with the major version going up at each January release; it reached 12.0.0 in January 2026, and it now ships 11 releases a year.

Why it’s built this way

A stable API in front of every hypervisor: Management tools outlive hypervisor versions. libvirt promises its API and ABI stay stable forever, and each driver maps the same calls and XML onto its own hypervisor.
XML documents to describe guests: A domain, network or storage pool is one declarative document that can be stored, edited, diffed and passed to define, rather than a long series of API calls or a hypervisor-specific command line.
A privileged daemon, reached by URI: Starting VMs, creating bridges and opening disks need root, so that work happens in a daemon and clients connect by URI, locally or over SSH or TLS. Session mode adds a per-user daemon whose VMs get no extra privileges, and the newer modular daemons give each driver its own process.
LGPL for the library: The C API is LGPL 2.1 or later, so management applications under any license can link to it.

Timeline

2005
First commit by Daniel Veillard (November 2), as libxen; 0.0.1 in December
2006
Renamed libvirt (February); 0.1.0 in April
2007
QEMU support added by Daniel P. Berrangé, released in 0.2.0 (February 14)
2012
libvirt 1.0.0 (November 2)
2016
2.0.0 (July 1): version numbers become time-based
2026
12.0.0 in January; 12.8.0 on October 1

Sources22 · facts checked 11 October 2026

Improve this page on GitHub