mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-11-09 15:00:07 +00:00
68 lines
7.5 KiB
HTML
68 lines
7.5 KiB
HTML
<?xml version="1.0" encoding="ISO-8859-1"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /><link rel="stylesheet" type="text/css" href="libvirt.css" /><link rel="SHORTCUT ICON" href="/32favicon.png" /><title>libvirt architecture</title></head><body><div id="container"><div id="intro"><div id="adjustments"></div><div id="pageHeader"></div><div id="content2"><h1 class="style1">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><li><a href="#Xen">Xen hypervisor</a></li>
|
|
<li><a href="#QEmu">QEmu and KVM based virtualization</a></li>
|
|
<li><a href="#drivers">the driver architecture</a></li>
|
|
</ul><h3><a name="Xen" id="Xen">Libvirt Xen support</a></h3><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 informations shared by the
|
|
hypervisor, the kernels, the drivers and the xen daemon. Xend. The xen daemon
|
|
supervise the control and execution of the sets of domains. 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 can be initialized in 2 ways depending on the level of
|
|
priviledge of the embedding program. If it runs with root access,
|
|
virConnectOpen() can be used, it will use three different ways to connect to
|
|
the Xen infrastructure:</p><ul><li>a connection to the Xen Daemon though an HTTP RPC layer</li>
|
|
<li>a read/write connection to the Xen Store</li>
|
|
<li>use Xen Hypervisor calls</li>
|
|
<li>when used as non-root libvirt connect to a proxy daemon running
|
|
as root and providing read-only support</li>
|
|
</ul><p>The library will usually interact with the Xen daemon for any operation
|
|
changing the state of the system, but for performance and accuracy reasons
|
|
may talk directly to the hypervisor when gathering state informations at
|
|
least when possible (i.e. when the running program using libvirt has root
|
|
priviledge access).</p><p>If it runs without root access virConnectOpenReadOnly() should be used to
|
|
connect to initialize the library. It will then fork a libvirt_proxy
|
|
program running as root and providing read_only access to the API, this is
|
|
then only useful for reporting and monitoring.</p><h3><a name="QEmu" id="QEmu">Libvirt QEmu and KVM support</a></h3><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 targetted.</p><p>The code controlling the QEmu process is available in the
|
|
<code>qemud/</code> directory.</p><h3><a name="drivers" id="drivers">the driver based architecture</a></h3><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
|
|
maintainance 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 hypvisor drivers
|
|
defining a common set of routines. That way the Xen Daemon accces, 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 availble 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></div></div><div class="linkList2"><div class="llinks2"><h3 class="links2"><span>main menu</span></h3><ul><li><a href="index.html">Home</a></li><li><a href="news.html">Releases</a></li><li><a href="intro.html">Introduction</a></li><li><a href="architecture.html">libvirt architecture</a></li><li><a href="downloads.html">Downloads</a></li><li><a href="format.html">XML Format</a></li><li><a href="python.html">Binding for Python</a></li><li><a href="errors.html">Handling of errors</a></li><li><a href="FAQ.html">FAQ</a></li><li><a href="bugs.html">Reporting bugs and getting help</a></li><li><a href="remote.html">Remote support</a></li><li><a href="uri.html">Connection URIs</a></li><li><a href="hvsupport.html">Hypervisor support</a></li><li><a href="html/index.html">API Menu</a></li><li><a href="examples/index.html">C code examples</a></li><li><a href="ChangeLog.html">Recent Changes</a></li></ul></div><div class="llinks2"><h3 class="links2"><span>related links</span></h3><ul><li><a href="https://www.redhat.com/archives/libvir-list/">Mail archive</a></li><li><a href="https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Fedora+Core&component=libvirt&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=MODIFIED&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr">Open bugs</a></li><li><a href="http://virt-manager.et.redhat.com/">virt-manager</a></li><li><a href="http://search.cpan.org/~danberr/Sys-Virt-0.1.0/">Perl bindings</a></li><li><a href="http://et.redhat.com/~rjones/ocaml-libvirt/">OCaml bindings</a></li><li><a href="http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html">Xen project</a></li><li><form action="search.php" enctype="application/x-www-form-urlencoded" method="get"><input name="query" type="text" size="12" value="Search..." /><input name="submit" type="submit" value="Go" /></form></li><li><a href="http://xmlsoft.org/"><img src="Libxml2-Logo-90x34.gif" alt="Made with Libxml2 Logo" /></a></li></ul><p class="credits">Graphics and design by <a href="mail:dfong@redhat.com">Diana Fong</a></p></div></div><div id="bottom"><p class="p1"></p></div></div></body></html>
|