NuKVM/libvirt
3
0
Fork 0
mirror of https://github.com/libvirt/libvirt.git synced 2025-02-25 18:55:26 -06:00
Code Issues Packages Projects Releases Wiki Activity

* docs/*.html: repair the damages made by Amaya on the content

Browse Source 
of documentation following feedback from Simon Hernandez
Daniel
This commit is contained in:
Daniel Veillard
2007-03-22 15:17:31 +00:00
parent 3d6dbfeab0
commit f39faaa708
13 changed files with 1060 additions and 1090 deletions
Download Patch File Download Diff File Expand all files Collapse all files

115
docs/architecture.html
View File

@@ -1,68 +1,67 @@
<?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
internalstructure is based on a driver model which simplifies adding new
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
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:</p><img src="architecture.gif" alt="The Xen architecture" /><p>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:</p><ul><li>a connection to the Xen Daemon though an HTTP RPC layer</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 runningas root
and providing read-only support</li>
</ul><p>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).</p><p>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.</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 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.</p><p>The code controlling the QEmu process is available in
the<code>qemud/</code>subdirectory.</p><h3><a name="drivers" id="drivers">the driver based architecture</a></h3><p>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</p><ul><li>xend_internal: implements the driver functions though the
XenDaemon.</li>
<li>xs_internal: implements the subset of the driver availble though theXen
Store.</li>
<li>xen_internal: provide the implementation of the functions possible
viadirect Xen hypervisor access.</li>
<li>proxy_internal: provide read-only Xen access via a proxy, the proxycode
is in the <code>proxy/</code>sub directory.</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>
domains.</li>
<li>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.</li>
<li>test: this is a test driver useful for regression tests of thefront-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 possiblethough the Xen Daemon, in that case the driver entry points are
initialized toNULL.</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 Formats</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="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&amp;component=libvirt&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;bug_status=MODIFIED&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;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://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>
KVM virtualization engines. It also uses a qemud/ specific daemon
which interracts 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="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&amp;component=libvirt&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;bug_status=MODIFIED&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;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://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>