libvirt architecture

Currently libvirt supports 2 kind of virtualization, and its internalstructure is based on a driver model which simplifies adding new engines:

• Xen hypervisor
• QEmu and KVM based virtualization
• the driver architecture

Libvirt Xen support

When running in a Xen environment, programs using libvirt have to executein "Domain 0", which is the primary Linux OS loaded on the machine. That OSkernel provides most if not all of the actual drivers used by the set ofdomains. It also runs the Xen Store, a database of informations shared by thehypervisor, the kernels, the drivers and the xen daemon. Xend. The xen daemonsupervise the control and execution of the sets of domains. The hypervisor,drivers, kernels and daemons communicate though a shared system busimplemented in the hypervisor. The figure below tries to provide a view ofthis environment:

The library can be initialized in 2 ways depending on the level ofpriviledge of the embedding program. If it runs with root access,virConnectOpen() can be used, it will use different ways to connect tothe Xen infrastructure:

• a connection to the Xen Daemon though an HTTP RPC layer
• a read/write connection to the Xen Store
• use Xen Hypervisor calls
• when used as non-root libvirt connect to a proxy daemon runningas root and providing read-only support

The library will usually interact with the Xen daemon for any operationchanging the state of the system, but for performance and accuracy reasonsmay talk directly to the hypervisor when gathering state informations atleast when possible (i.e. when the running program using libvirt has rootpriviledge access).

If it runs without root access virConnectOpenReadOnly() should be used toconnect to initialize the library. It will then fork a libvirt_proxy programrunning as root and providing read_only access to the API, this is thenonly useful for reporting and monitoring.

Libvirt QEmu and KVM support

The model for QEmu and KVM is completely similar, basically KVM isbased on QEmu for the process controlling a new domain, only small detailsdiffers between the two. In both case the libvirt API is providedby a controlling process forked by libvirt in the background andwhich launch and control the QEmu or KVM process. That program calledlibvirt_qemud talks though a specific protocol to the library, andconnects to the console of the QEmu process in order to control andreport on its status. Libvirt tries to expose all the emulationsmodels of QEmu, the selection is done when creating the new domain,by specifying the architecture and machine type targetted.

The code controlling the QEmu process is available in theqemud/subdirectory.

the driver based architecture

As the previous section explains, libvirt can communicate using differentchannels with the Xen hypervisor, and is also able to use different kindof hypervisor. To simplify the internal design, code, easemaintainance and simplify the support of other virtualization engine theinternals have been structured as one core component, the libvirt.c moduleacting as a front-end for the library API and a set of hypvisor driversdefining a common set of routines. That way the Xen Daemon accces, the XenStore one, the Hypervisor hypercall are all isolated in separate C modulesimplementing at least a subset of the common operations defined by thedrivers present in driver.h. The driver architecture is used to add supportfor other virtualization engines and

• xend_internal: implements the driver functions though the XenDaemon.
• xs_internal: implements the subset of the driver availble though theXen Store.
• xen_internal: provide the implementation of the functions possible viadirect Xen hypervisor access.
• proxy_internal: provide read-only Xen access via a proxy, the proxycode is in the proxy/sub directory.
• xm_internal: provide support for Xen defined but not running domains.
• qemu_internal: implement the driver functions for QEmu and KVMvirtualization engines. It also uses a qemud/ specific daemon whichinterracts with the QEmu process to implement libvirt API.
• test: this is a test driver useful for regression tests of thefront-end part of libvirt.

Note that a given driver may only implement a subset of those functions,for example saving a Xen domain state to disk and restoring it is only possiblethough the Xen Daemon, in that case the driver entry points are initialized toNULL.