3
<h1 >libvirt architecture</h1>
4
<p>Currently libvirt supports 2 kind of virtualization, and its
5
internal structure is based on a driver model which simplifies adding new
9
<a href="#Xen">Xen hypervisor</a>
12
<a href="#QEmu">QEmu and KVM based virtualization</a>
15
<a href="#drivers">the driver architecture</a>
19
<a name="Xen" id="Xen">Libvirt Xen support</a>
21
<p>When running in a Xen environment, programs using libvirt have to execute
22
in "Domain 0", which is the primary Linux OS loaded on the machine. That OS
23
kernel provides most if not all of the actual drivers used by the set of
24
domains. It also runs the Xen Store, a database of information shared by the
25
hypervisor, the kernels, the drivers and the xen daemon. Xend. The xen daemon
26
supervise the control and execution of the sets of domains. The hypervisor,
27
drivers, kernels and daemons communicate though a shared system bus
28
implemented in the hypervisor. The figure below tries to provide a view of
30
<img src="architecture.gif" alt="The Xen architecture" />
31
<p>The library can be initialized in 2 ways depending on the level of
32
privilege of the embedding program. If it runs with root access,
33
virConnectOpen() can be used, it will use three different ways to connect to
34
the Xen infrastructure:</p>
36
<li>a connection to the Xen Daemon though an HTTP RPC layer</li>
37
<li>a read/write connection to the Xen Store</li>
38
<li>use Xen Hypervisor calls</li>
39
<li>when used as non-root libvirt connect to a proxy daemon running
40
as root and providing read-only support</li>
42
<p>The library will usually interact with the Xen daemon for any operation
43
changing the state of the system, but for performance and accuracy reasons
44
may talk directly to the hypervisor when gathering state information at
45
least when possible (i.e. when the running program using libvirt has root
46
privilege access).</p>
47
<p>If it runs without root access virConnectOpenReadOnly() should be used to
48
connect to initialize the library. It will then fork a libvirt_proxy
49
program running as root and providing read_only access to the API, this is
50
then only useful for reporting and monitoring.</p>
52
<a name="QEmu" id="QEmu">Libvirt QEmu and KVM support</a>
54
<p>The model for QEmu and KVM is completely similar, basically KVM is based
55
on QEmu for the process controlling a new domain, only small details differs
56
between the two. In both case the libvirt API is provided by a controlling
57
process forked by libvirt in the background and which launch and control the
58
QEmu or KVM process. That program called libvirt_qemud talks though a specific
59
protocol to the library, and connects to the console of the QEmu process in
60
order to control and report on its status. Libvirt tries to expose all the
61
emulations models of QEmu, the selection is done when creating the new
62
domain, by specifying the architecture and machine type targeted.</p>
63
<p>The code controlling the QEmu process is available in the
64
<code>qemud/</code> directory.</p>
66
<a name="drivers" id="drivers">the driver based architecture</a>
68
<p>As the previous section explains, libvirt can communicate using different
69
channels with the current hypervisor, and should also be able to use
70
different kind of hypervisor. To simplify the internal design, code, ease
71
maintenance and simplify the support of other virtualization engine the
72
internals have been structured as one core component, the libvirt.c module
73
acting as a front-end for the library API and a set of hypervisor drivers
74
defining a common set of routines. That way the Xen Daemon access, the Xen
75
Store one, the Hypervisor hypercall are all isolated in separate C modules
76
implementing at least a subset of the common operations defined by the
77
drivers present in driver.h:</p>
79
<li>xend_internal: implements the driver functions though the Xen
81
<li>xs_internal: implements the subset of the driver available though the
83
<li>xen_internal: provide the implementation of the functions possible via
84
direct hypervisor access</li>
85
<li>proxy_internal: provide read-only Xen access via a proxy, the proxy code
86
is in the <code>proxy/</code>directory.</li>
87
<li>xm_internal: provide support for Xen defined but not running
89
<li>qemu_internal: implement the driver functions for QEmu and
90
KVM virtualization engines. It also uses a qemud/ specific daemon
91
which interacts with the QEmu process to implement libvirt API.</li>
92
<li>test: this is a test driver useful for regression tests of the
93
front-end part of libvirt.</li>
95
<p>Note that a given driver may only implement a subset of those functions,
96
(for example saving a Xen domain state to disk and restoring it is only
97
possible though the Xen Daemon), in that case the driver entry points for
98
unsupported functions are initialized to NULL.</p>
added
removed
docs/architecture.html.in
