mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-11-03 20:01:16 +00:00
e2e76de055
Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
83 lines
4.0 KiB
XML
83 lines
4.0 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE html>
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<body>
|
|
<h1 >libvirt architecture</h1>
|
|
|
|
<p>
|
|
Currently libvirt supports 2 kind of virtualization, and its
|
|
internal structure is based on a driver model which simplifies
|
|
adding new
|
|
engines:
|
|
</p>
|
|
|
|
<ul id="toc"></ul>
|
|
|
|
<h2><a id="Xen">Xen support</a></h2>
|
|
|
|
<p>When running in a Xen environment, programs using libvirt have to execute
|
|
in "Domain 0", which is the primary Linux OS loaded on the machine. That OS
|
|
kernel provides most if not all of the actual drivers used by the set of
|
|
domains. It also runs the Xen Store, a database of information shared by the
|
|
hypervisor, the backend drivers, any running domains, and libxl (aka libxenlight).
|
|
libxl provides a set of APIs for creating and managing domains, which can be used
|
|
by applications such as the xl tool provided by Xen or libvirt. The hypervisor,
|
|
drivers, kernels and daemons communicate though a shared system bus
|
|
implemented in the hypervisor. The figure below tries to provide a view of
|
|
this environment:</p>
|
|
<img src="architecture.gif" alt="The Xen architecture" />
|
|
<p>The library will interact with libxl for all management operations
|
|
on a Xen system.</p>
|
|
<p>Note that the libvirt libxl driver only supports root access.</p>
|
|
|
|
<h2><a id="QEMU">QEMU and KVM support</a></h2>
|
|
|
|
<p>The model for QEMU and KVM is completely similar, basically KVM is based
|
|
on QEMU for the process controlling a new domain, only small details differs
|
|
between the two. In both case the libvirt API is provided by a controlling
|
|
process forked by libvirt in the background and which launch and control the
|
|
QEMU or KVM process. That program called libvirt_qemud talks though a specific
|
|
protocol to the library, and connects to the console of the QEMU process in
|
|
order to control and report on its status. Libvirt tries to expose all the
|
|
emulations models of QEMU, the selection is done when creating the new
|
|
domain, by specifying the architecture and machine type targeted.</p>
|
|
<p>The code controlling the QEMU process is available in the
|
|
<code>qemud/</code> directory.</p>
|
|
|
|
<h2><a id="drivers">Driver based architecture</a></h2>
|
|
|
|
<p>As the previous section explains, libvirt can communicate using different
|
|
channels with the current hypervisor, and should also be able to use
|
|
different kind of hypervisor. To simplify the internal design, code, ease
|
|
maintenance and simplify the support of other virtualization engine the
|
|
internals have been structured as one core component, the libvirt.c module
|
|
acting as a front-end for the library API and a set of hypervisor drivers
|
|
defining a common set of routines. That way the Xen Daemon access, the Xen
|
|
Store one, the Hypervisor hypercall are all isolated in separate C modules
|
|
implementing at least a subset of the common operations defined by the
|
|
drivers present in driver.h:</p>
|
|
<ul>
|
|
<li>xend_internal: implements the driver functions though the Xen
|
|
Daemon</li>
|
|
<li>xs_internal: implements the subset of the driver available though the
|
|
Xen Store</li>
|
|
<li>xen_internal: provide the implementation of the functions possible via
|
|
direct hypervisor access</li>
|
|
<li>proxy_internal: provide read-only Xen access via a proxy, the proxy code
|
|
is in the <code>proxy/</code> directory.</li>
|
|
<li>xm_internal: provide support for Xen defined but not running
|
|
domains.</li>
|
|
<li>qemu_internal: implement the driver functions for QEMU and
|
|
KVM virtualization engines. It also uses a qemud/ specific daemon
|
|
which interacts with the QEMU process to implement libvirt API.</li>
|
|
<li>test: this is a test driver useful for regression tests of the
|
|
front-end part of libvirt.</li>
|
|
</ul>
|
|
<p>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
|
|
possible though the Xen Daemon), in that case the driver entry points for
|
|
unsupported functions are initialized to NULL.</p>
|
|
<p></p>
|
|
</body>
|
|
</html>
|