mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-22 17:34:18 +03:00
* src/virsh.c src/xen_internal.c: applied patch from Atsushi SAKAI
to better handle the case where there is no limit in the domain upper memory size * docs/architecture.html docs/format.html docs/intro.html docs/libvir.html: started to update the documentation to reflect the current state Daniel
This commit is contained in:
Daniel Veillard
parent
181ce1fdc6
commit
6f7f84a772
@ -1,3 +1,12 @@
|
||||
Thu Mar 15 15:26:20 CET 2007 Daniel Veillard <veillard@redhat.com>
|
||||
|
||||
* src/virsh.c src/xen_internal.c: applied patch from Atsushi SAKAI
|
||||
to better handle the case where there is no limit in the domain
|
||||
upper memory size
|
||||
* docs/architecture.html docs/format.html docs/intro.html
|
||||
docs/libvir.html: started to update the documentation to reflect
|
||||
the current state
|
||||
|
||||
Thu Mar 15 08:40:33 CET 2007 Daniel Veillard <veillard@redhat.com>
|
||||
|
||||
* configure.in proxy/Makefile.am proxy/libvirt_proxy.c
|
||||
|
||||
@ -1,7 +1,10 @@
|
||||
<?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><h3>This is in a large part Xen specific since this is the only hypervisor
|
||||
supported at the moment</h3><p>When running in a Xen environment, programs using libvirt have to execute
|
||||
<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
|
||||
@ -11,35 +14,54 @@ 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
|
||||
virConnectOpen() can be used, it will use 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 try to open the read-only socket
|
||||
<code>/var/run/xenstored/socket_ro</code> to connect to the Xen Store and
|
||||
also try to use the RPC to the Xen daemon. In this case use of hypervisor
|
||||
calls and write to the Xen Store will not be possible, restraining the amount
|
||||
of APIs available and slowing down information gathering about domains.</p><h3>Internal architecture</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
|
||||
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> subdirectory.</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 Xen hypervisor, and is also 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>
|
||||
drivers present in driver.h. The driver architecture is used to add support
|
||||
for other virtualization engines and </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>
|
||||
Xen Store.</li>
|
||||
<li>xen_internal: provide the implementation of the functions possible via
|
||||
direct hypervisor access</li>
|
||||
direct Xen hypervisor access.</li>
|
||||
<li>proxy_internal: provide read-only Xen access via a proxy, the proxy
|
||||
code is in the <code>proxy/</code> sub 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
|
||||
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 domain state to disk and restoring it is only possible
|
||||
though the Xen Daemon, on the other hand all interfaces allow to query the
|
||||
runtime state of a given domain.</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&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://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>
|
||||
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 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&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://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>
|
||||
|
||||
@ -2,9 +2,13 @@
|
||||
<!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>XML Format</title></head><body><div id="container"><div id="intro"><div id="adjustments"></div><div id="pageHeader"></div><div id="content2"><h1 class="style1">XML Format</h1><p>This section describes the XML format used to represent domains, there are
|
||||
variations on the format based on the kind of domains run and the options
|
||||
used to launch them:</p><p><a href="#Normal1">Normal paravirtualized Xen domains</a></p><p><a href="#Fully1">Fully virtualized Xen domains</a></p><p>The formats try as much as possible to follow the same structure and reuse
|
||||
used to launch them:</p><ul><li><a href="#Normal1">Normal paravirtualized Xen domains</a></li>
|
||||
<li><a href="#Fully1">Fully virtualized Xen domains</a></li>
|
||||
<li><a href="#KVM1">KVM domains</a></li>
|
||||
<li><a href="#QEmu1">QEmu domains</a></li>
|
||||
</ul><p>The formats try as much as possible to follow the same structure and reuse
|
||||
elements and attributes where it makes sense.</p><h3 id="Normal"><a name="Normal1" id="Normal1">Normal paravirtualized Xen
|
||||
guests</a>:</h3><p>The library use an XML format to describe domains, as input to <a href="html/libvirt-libvirt.html#virDomainCreateLinux">virDomainCreateLinux()</a>
|
||||
domains</a>:</h3><p>The library use an XML format to describe domains, as input to <a href="html/libvirt-libvirt.html#virDomainCreateLinux">virDomainCreateLinux()</a>
|
||||
and as the output of <a href="html/libvirt-libvirt.html#virDomainGetXMLDesc">virDomainGetXMLDesc()</a>,
|
||||
the following is an example of the format as returned by the shell command
|
||||
<code>virsh xmldump fc4</code> , where fc4 was one of the running domains:</p><pre><domain type='xen' <span style="color: #0071FF; background-color: #FFFFFF">id='18'</span>>
|
||||
@ -175,4 +179,4 @@ systems:</p><pre><domain type='xen' id='3'>
|
||||
</ul><p>It is likely that the HVM description gets additional optional elements
|
||||
and attributes as the support for fully virtualized domain expands,
|
||||
especially for the variety of devices emulated and the graphic support
|
||||
options offered.</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&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://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>
|
||||
options offered.</p><h3><a name="KVM1" id="KVM1">KVM domain</a></h3><p></p><h3><a name="QEmu1" id="QEmu1">QEmu domain</a></h3><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&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://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>
|
||||
|
||||
@ -10,8 +10,8 @@ some of the specific concepts used in libvirt documentation:</p><ul><li>a <stron
|
||||
<li>a <strong>domain</strong> is an instance of an operating system running
|
||||
on a virtualized machine provided by the hypervisor</li>
|
||||
</ul><p style="text-align: center"><img alt="Hypervisor and domains running on a node" src="node.gif" /></p><p>Now we can define the goal of libvirt: to provide the lowest possible
|
||||
generic and stable layer to manage domains on a node.</p><p>This implies the following:</p><ul><li>the API should not be targetted to a single virtualization environment
|
||||
though Xen is the current default, which also means that some very
|
||||
generic and stable layer to manage domains on a node.</p><p>This implies the following:</p><ul><li>the API is not targetted to a single virtualization environment, it
|
||||
currently supports Xen and QEmu/KVM. This also implies that some very
|
||||
specific capabilities which are not generic enough may not be provided as
|
||||
libvirt APIs</li>
|
||||
<li>the API should allow to do efficiently and cleanly all the operations
|
||||
@ -27,4 +27,6 @@ and for applications focusing on virtualization of a single node (the only
|
||||
exception being domain migration between node capabilities which may need to
|
||||
be added at the libvirt level). Where possible libvirt should be extendable
|
||||
to be able to provide the same API for remote nodes, however this is not the
|
||||
case at the moment, the code currently handle only local node accesses.</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&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://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>
|
||||
case at the moment, the code currently handle only local node accesses
|
||||
(extension for remote access support is being worked on, see
|
||||
<a href="bugs.html">the mailing list</a> discussions about it).</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&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://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>
|
||||
|
||||
@ -277,8 +277,8 @@ generic and stable layer to manage domains on a node.</p>
|
||||
|
||||
<p>This implies the following:</p>
|
||||
<ul>
|
||||
<li>the API should not be targetted to a single virtualization environment
|
||||
though Xen is the current default, which also means that some very
|
||||
<li>the API is not targetted to a single virtualization environment, it
|
||||
currently supports Xen and QEmu/KVM. This also implies that some very
|
||||
specific capabilities which are not generic enough may not be provided as
|
||||
libvirt APIs</li>
|
||||
<li>the API should allow to do efficiently and cleanly all the operations
|
||||
@ -296,12 +296,21 @@ and for applications focusing on virtualization of a single node (the only
|
||||
exception being domain migration between node capabilities which may need to
|
||||
be added at the libvirt level). Where possible libvirt should be extendable
|
||||
to be able to provide the same API for remote nodes, however this is not the
|
||||
case at the moment, the code currently handle only local node accesses.</p>
|
||||
case at the moment, the code currently handle only local node accesses
|
||||
(extension for remote access support is being worked on, see
|
||||
<a href="bugs.html">the mailing list</a> discussions about it).</p>
|
||||
|
||||
<h2><a name="architecture">libvirt architecture</a></h2>
|
||||
|
||||
<h3>This is in a large part Xen specific since this is the only hypervisor
|
||||
supported at the moment</h3>
|
||||
<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">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
|
||||
@ -316,12 +325,14 @@ this environment:</p>
|
||||
|
||||
<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
|
||||
virConnectOpen() can be used, it will use 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
|
||||
@ -331,37 +342,58 @@ 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 try to open the read-only socket
|
||||
<code>/var/run/xenstored/socket_ro</code> to connect to the Xen Store and
|
||||
also try to use the RPC to the Xen daemon. In this case use of hypervisor
|
||||
calls and write to the Xen Store will not be possible, restraining the amount
|
||||
of APIs available and slowing down information gathering about domains.</p>
|
||||
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>Internal architecture</h3>
|
||||
<h3><a name="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> subdirectory.</p>
|
||||
|
||||
<h3><a name="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
|
||||
channels with the Xen hypervisor, and is also 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>
|
||||
drivers present in driver.h. The driver architecture is used to add support
|
||||
for other virtualization engines and </p>
|
||||
<ul>
|
||||
<li>xend_internal: implements the driver functions though the Xen
|
||||
Daemon</li>
|
||||
Daemon.</li>
|
||||
<li>xs_internal: implements the subset of the driver availble though the
|
||||
Xen Store</li>
|
||||
Xen Store.</li>
|
||||
<li>xen_internal: provide the implementation of the functions possible via
|
||||
direct hypervisor access</li>
|
||||
direct Xen hypervisor access.</li>
|
||||
<li>proxy_internal: provide read-only Xen access via a proxy, the proxy
|
||||
code is in the <code>proxy/</code> sub 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
|
||||
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 domain state to disk and restoring it is only possible
|
||||
though the Xen Daemon, on the other hand all interfaces allow to query the
|
||||
runtime state of a given domain.</p>
|
||||
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 are initialized to
|
||||
NULL.</p>
|
||||
|
||||
<p></p>
|
||||
|
||||
@ -396,15 +428,18 @@ available except commiting to the base.</p>
|
||||
variations on the format based on the kind of domains run and the options
|
||||
used to launch them:</p>
|
||||
|
||||
<p><a href="#Normal1">Normal paravirtualized Xen domains</a></p>
|
||||
|
||||
<p><a href="#Fully1">Fully virtualized Xen domains</a></p>
|
||||
<ul>
|
||||
<li><a href="#Normal1">Normal paravirtualized Xen domains</a></li>
|
||||
<li><a href="#Fully1">Fully virtualized Xen domains</a></li>
|
||||
<li><a href="#KVM1">KVM domains</a></li>
|
||||
<li><a href="#QEmu1">QEmu domains</a></li>
|
||||
</ul>
|
||||
|
||||
<p>The formats try as much as possible to follow the same structure and reuse
|
||||
elements and attributes where it makes sense.</p>
|
||||
|
||||
<h3 id="Normal"><a name="Normal1" id="Normal1">Normal paravirtualized Xen
|
||||
guests</a>:</h3>
|
||||
domains</a>:</h3>
|
||||
|
||||
<p>The library use an XML format to describe domains, as input to <a
|
||||
href="html/libvirt-libvirt.html#virDomainCreateLinux">virDomainCreateLinux()</a>
|
||||
@ -625,6 +660,12 @@ and attributes as the support for fully virtualized domain expands,
|
||||
especially for the variety of devices emulated and the graphic support
|
||||
options offered.</p>
|
||||
|
||||
<h3><a name="KVM1">KVM domain</a></h3>
|
||||
<p></p>
|
||||
|
||||
<h3><a name="QEmu1">QEmu domain</a></h3>
|
||||
<p></p>
|
||||
|
||||
<h2><a name="Python" id="Python">Binding for Python</a></h2>
|
||||
|
||||
<p>Libvirt comes with direct support for the Python language (just make sure
|
||||
|
||||
@ -1186,8 +1186,13 @@ cmdDominfo(vshControl * ctl, vshCmd * cmd)
|
||||
vshPrint(ctl, "%-15s %.1lfs\n", _("CPU time:"), cpuUsed);
|
||||
}
|
||||
|
||||
vshPrint(ctl, "%-15s %lu kB\n", _("Max memory:"),
|
||||
if (info.maxMem != UINT_MAX)
|
||||
vshPrint(ctl, "%-15s %lu kB\n", _("Max memory:"),
|
||||
info.maxMem);
|
||||
else
|
||||
vshPrint(ctl, "%-15s %-15s\n", _("Max memory:"),
|
||||
_("no limit"));
|
||||
|
||||
vshPrint(ctl, "%-15s %lu kB\n", _("Used memory:"),
|
||||
info.memory);
|
||||
|
||||
|
||||
@ -1598,7 +1598,9 @@ xenHypervisorGetDomInfo(virConnectPtr conn, int id, virDomainInfoPtr info)
|
||||
*/
|
||||
info->cpuTime = XEN_GETDOMAININFO_CPUTIME(dominfo);
|
||||
info->memory = XEN_GETDOMAININFO_TOT_PAGES(dominfo) * kb_per_pages;
|
||||
info->maxMem = XEN_GETDOMAININFO_MAX_PAGES(dominfo) * kb_per_pages;
|
||||
info->maxMem = XEN_GETDOMAININFO_MAX_PAGES(dominfo);
|
||||
if(info->maxMem != UINT_MAX)
|
||||
info->maxMem *= kb_per_pages;
|
||||
info->nrVirtCpu = XEN_GETDOMAININFO_CPUCOUNT(dominfo);
|
||||
return (0);
|
||||
}
|
||||
|
||||
Loading…
Reference in New Issue
Block a user