Understanding libvirt: Open‑Source Virtualization API and Its Architecture

libvirt is a combination of the words lib (library) and virt (virtualization). It is an open‑source API and management toolset for virtualized platforms, supporting KVM, XEN, VMware ESX, QEMU and others, and is the default hypervisor manager in OpenStack Nova (which uses KVM by default).

libvirt is the most widely used tool and API for managing KVM virtual machines. The libvirtd daemon can be invoked locally or remotely by the virsh command‑line client, which in turn uses qemu‑kvm to control VMs. libvirt consists of an API library, the libvirtd daemon, and default command‑line utilities such as virsh . It supports many hypervisors and management tools, as shown in the accompanying diagram.

Although libvirt is written in C, it provides language bindings (via libvirtmod ) for many languages. Before 2014 the Python bindings were part of the main libvirt source tree; after that they were split into the separate libvirt‑python Git repository.

At the lower level, libvirt supports a wide range of hypervisors, essentially covering all major commercial and open‑source hypervisors, as illustrated in the following image.

libvirt also has a vibrant open‑source community. It provides bindings for Ruby, Java, Perl, OCaml, and supports the most popular system languages (C, C++) as well as many scripting languages. Its architecture follows a driver‑based model that allows a generic API to serve different hypervisors uniformly.

The architecture diagram shows two scenarios: (1) when the hypervisor and domain reside on the same node, and (2) when they are on different nodes, in which case a client connects to a remote libvirtd daemon via a common protocol, and the daemon forwards requests to the appropriate hypervisor.

When the hypervisor and domain are on different nodes, the management application uses a generic protocol to connect from a local libvirt client to a remote libvirtd daemon, which then accesses the local domain.

libvirt was first released on 19 December 2005 by Daniel Veillard and is currently maintained mainly by Red Hat, with contributions from SUSE, Fujitsu and others. The maintainer list can be found in the AUTHORS.in file of the source tree.

Communication within the libvirt community occurs via mailing lists and an IRC channel, providing a venue for developers to discuss issues.

Contributing to libvirt requires adhering to its coding style and framework. The libvirt API is divided into eight major groups:

Connection‑related API: functions prefixed with virConnect .

Domain management API: functions prefixed with virDomain .

Node management API: functions prefixed with virNode .

Network management API: functions prefixed with virNetwork (and some virInterface ).

Storage volume management API: functions prefixed with virStorageVol .

Storage pool management API: functions prefixed with virStoragePool .

Event management API: functions prefixed with virEvent .

Stream management API: functions prefixed with virStream .

For example, connection‑related calls start with virConnectOpen , which establishes a client‑server connection to the libvirtd daemon. The typical workflow is:

Client calls virConnectOpen , which contacts libvirtd and obtains a driver handle.

Server side creates a virNetServerClient object to represent the client.

Client’s RPC request is dispatched to libvirtd, which then connects to the actual hypervisor (e.g., QEMU).

Server processes the request, stores the driver pointer, and subsequent API calls use this connection directly.

After the libvirtd connection is established, further API calls can use the connection object directly. In KVM virtualization, KVM handles CPU and memory virtualization, while QEMU emulates I/O devices; together they provide full server‑level virtualization, often referred to as QEMU‑KVM.

Technical article recommendations:

Plain‑language Blockchain and Smart Contract Technology

In‑Depth RDMA Technology and Mainstream Implementations

Warm reminder: Please search for “ICT_Architect” or scan the QR code to follow the public account and click the original link for more technical resources.

Stay hungry, stay foolish.