<htmlxmlns="http://www.w3.org/1999/xhtml"><head><metahttp-equiv="Content-Type"content="text/html; charset=ISO-8859-1"/><linkrel="stylesheet"type="text/css"href="libvirt.css"/><linkrel="SHORTCUT ICON"href="/32favicon.png"/><title>libvirt architecture</title></head><body><divid="container"><divid="intro"><divid="adjustments"></div><divid="pageHeader"></div><divid="content2"><h1class="style1">libvirt architecture</h1><p>Currently libvirt supports 2 kind of virtualization, and its
<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><aname="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><aname="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
unsupported functions are initialized to NULL.</p><p></p></div></div><divclass="linkList2"><divclass="llinks2"><h3class="links2"><span>main menu</span></h3><ul><li><ahref="index.html">Home</a></li><li><ahref="news.html">Releases</a></li><li><ahref="intro.html">Introduction</a></li><li><ahref="architecture.html">libvirt architecture</a></li><li><ahref="downloads.html">Downloads</a></li><li><ahref="format.html">XML Format</a></li><li><ahref="python.html">Binding for Python</a></li><li><ahref="errors.html">Handling of errors</a></li><li><ahref="FAQ.html">FAQ</a></li><li><ahref="bugs.html">Reporting bugs and getting help</a></li><li><ahref="remote.html">Remote support</a></li><li><ahref="html/index.html">API Menu</a></li><li><ahref="examples/index.html">C code examples</a></li><li><ahref="ChangeLog.html">Recent Changes</a></li></ul></div><divclass="llinks2"><h3class="links2"><span>related links</span></h3><ul><li><ahref="https://www.redhat.com/archives/libvir-list/">Mail archive</a></li><li><ahref="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><ahref="http://virt-manager.et.redhat.com/">virt-manager</a></li><li><ahref="http://search.cpan.org/~danberr/Sys-Virt-0.1.0/">Perl bindings</a></li><li><ahref="http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html">Xen project</a></li><li><formaction="search.php"enctype="application/x-www-form-urlencoded"method="get"><inputname="query"type="text"size="12"value="Search..."/><inputname="submit"type="submit"value="Go"/></form></li><li><ahref="http://xmlsoft.org/"><imgsrc="Libxml2-Logo-90x34.gif"alt="Made with Libxml2 Logo"/></a></li></ul><pclass="credits">Graphics and design by <ahref="mail:dfong@redhat.com">Diana Fong</a></p></div></div><divid="bottom"><pclass="p1"></p></div></div></body></html>
