External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-07-06 18:05:45 +00:00
Code Issues Packages Projects Releases Wiki Activity

* src/virsh.c src/xen_internal.c: applied patch from Atsushi SAKAI

Browse Source 
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 2007-03-15 14:27:09 +00:00
parent 181ce1fdc6
commit 6f7f84a772
7 changed files with 135 additions and 50 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
ChangeLog
View File

@ -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

56
docs/architecture.html
View File

@ -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&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>
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&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>

10
docs/format.html
View File

@ -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>&lt;domain type='xen' <span style="color: #0071FF; background-color: #FFFFFF">id='18'</span>&gt;
@ -175,4 +179,4 @@ systems:</p><pre>&lt;domain type='xen' id='3'&gt;
</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&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>
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&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>

8
docs/intro.html
View File

@ -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&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>
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&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>

91
docs/libvir.html
View File

@ -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

7
src/virsh.c
View File

@ -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);

4
src/xen_internal.c
View File

@ -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);
}