* docs/*: start cleanup/revamp of architecture docs

daniel
This commit is contained in:
Daniel Veillard 2009-04-02 12:01:11 +00:00
parent 8b8f4c5cbc
commit 89dd05cc6f
11 changed files with 250 additions and 69 deletions

View File

@ -1,3 +1,7 @@
Thu Apr 2 14:00:14 CEST 2009 Daniel Veillard <veillard@redhat.com>
* docs/*: start cleanup/revamp of architecture docs
Thu Apr 2 11:52:59 CEST 2009 Daniel Veillard <veillard@redhat.com>
* po/*: updated brazilian, spanish, polish and simplified chinese

View File

@ -47,6 +47,10 @@
<div>
<a title="Overview of the logical subsystems in the libvirt API" class="active" href="intro.html">Architecture</a>
<ul class="l2"><li>
<div>
<a title="Terminology and goals of libvirt API" class="inactive" href="goals.html">Goals</a>
</div>
</li><li>
<div>
<span class="active">Domains</span>
</div>

View File

@ -47,6 +47,10 @@
<div>
<a title="Overview of the logical subsystems in the libvirt API" class="active" href="intro.html">Architecture</a>
<ul class="l2"><li>
<div>
<a title="Terminology and goals of libvirt API" class="inactive" href="goals.html">Goals</a>
</div>
</li><li>
<div>
<a title="Managing virtual machines" class="inactive" href="archdomain.html">Domains</a>
</div>

View File

@ -47,6 +47,10 @@
<div>
<a title="Overview of the logical subsystems in the libvirt API" class="active" href="intro.html">Architecture</a>
<ul class="l2"><li>
<div>
<a title="Terminology and goals of libvirt API" class="inactive" href="goals.html">Goals</a>
</div>
</li><li>
<div>
<a title="Managing virtual machines" class="inactive" href="archdomain.html">Domains</a>
</div>

View File

@ -47,6 +47,10 @@
<div>
<a title="Overview of the logical subsystems in the libvirt API" class="active" href="intro.html">Architecture</a>
<ul class="l2"><li>
<div>
<a title="Terminology and goals of libvirt API" class="inactive" href="goals.html">Goals</a>
</div>
</li><li>
<div>
<a title="Managing virtual machines" class="inactive" href="archdomain.html">Domains</a>
</div>

157
docs/goals.html Normal file
View File

@ -0,0 +1,157 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<!--
This file is autogenerated from goals.html.in
Do not edit this file. Changes will be lost.
-->
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
<link rel="stylesheet" type="text/css" href="main.css" />
<link rel="SHORTCUT ICON" href="32favicon.png" />
<title>libvirt: Terminology and goals</title>
<meta name="description" content="libvirt, virtualization, virtualization API" />
</head>
<body>
<div id="header">
<div id="headerLogo"></div>
<div id="headerSearch">
<form action="search.php" enctype="application/x-www-form-urlencoded" method="get"><div>
<input id="query" name="query" type="text" size="12" value="" />
<input id="submit" name="submit" type="submit" value="Search" />
</div></form>
</div>
</div>
<div id="body">
<div id="menu">
<ul class="l0"><li>
<div>
<a title="Front page of the libvirt website" class="inactive" href="index.html">Home</a>
</div>
</li><li>
<div>
<a title="Details of new features and bugs fixed in each release" class="inactive" href="news.html">News</a>
</div>
</li><li>
<div>
<a title="Get the latest source releases, binary builds and get access to the source repository" class="inactive" href="downloads.html">Downloads</a>
</div>
</li><li>
<div>
<a title="Information for users, administrators and developers" class="active" href="docs.html">Documentation</a>
<ul class="l1"><li>
<div>
<a title="Information about deploying and using libvirt" class="inactive" href="deployment.html">Deployment</a>
</div>
</li><li>
<div>
<a title="Overview of the logical subsystems in the libvirt API" class="active" href="intro.html">Architecture</a>
<ul class="l2"><li>
<div>
<span class="active">Goals</span>
</div>
</li><li>
<div>
<a title="Managing virtual machines" class="inactive" href="archdomain.html">Domains</a>
</div>
</li><li>
<div>
<a title="Providing isolated networks and NAT based network connectivity" class="inactive" href="archnetwork.html">Network</a>
</div>
</li><li>
<div>
<a title="Managing storage pools and volumes" class="inactive" href="archstorage.html">Storage</a>
</div>
</li><li>
<div>
<a title="Enumerating host node devices" class="inactive" href="archnode.html">Node Devices</a>
</div>
</li></ul>
</div>
</li><li>
<div>
<a title="Description of the XML formats used in libvirt" class="inactive" href="format.html">XML format</a>
</div>
</li><li>
<div>
<a title="Hypervisor specific driver information" class="inactive" href="drivers.html">Drivers</a>
</div>
</li><li>
<div>
<a title="Reference manual for the C public API" class="inactive" href="html/index.html">API reference</a>
</div>
</li><li>
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li></ul>
</div>
</li><li>
<div>
<a title="User contributed content" class="inactive" href="http://wiki.libvirt.org">Wiki</a>
</div>
</li><li>
<div>
<a title="Frequently asked questions" class="inactive" href="FAQ.html">FAQ</a>
</div>
</li><li>
<div>
<a title="How and where to report bugs and request features" class="inactive" href="bugs.html">Bug reports</a>
</div>
</li><li>
<div>
<a title="How to contact the developers via email and IRC" class="inactive" href="contact.html">Contact</a>
</div>
</li><li>
<div>
<a title="Miscellaneous links of interest related to libvirt" class="inactive" href="relatedlinks.html">Related Links</a>
</div>
</li><li>
<div>
<a title="Overview of all content on the website" class="inactive" href="sitemap.html">Sitemap</a>
</div>
</li></ul>
</div>
<div id="content">
<h1>Terminology and goals</h1>
<p>To avoid ambiguity about the terms used, here are the definitions
for some of the specific concepts used in libvirt documentation:</p>
<ul><li>a <strong>node</strong> is a single physical machine</li><li>an <strong>hypervisor</strong> is a layer of software allowing to
virtualize a node in a set of virtual machines with possibly different
configurations than the node itself</li><li>a <strong>domain</strong> is an instance of an operating system
(or subsystem in the case of container virtualization) running on a
virtualized machine provided by the hypervisor</li></ul>
<p class="image">
<img alt="Hypervisor and domains running on a node" src="node.gif" /></p>
<p>Now we can define the goal of libvirt: to provide a common generic
and stable layer to securely manage domains on a node. The node may be
distant and libvirt should provide all APIs needed to provision, create,
modify, monitor, control, migrate and stop the domains, within the limits
of the support of the hypervisor for those operations. Multiple mode may
be accessed with libvirt simultaneously but the APIs are limited to
single node operations.</p>
<p>This implies the following sub-goals:</p>
<ul><li>the API should not be targeted to a single virtualization environment
which also means 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
needed to manage domains on a node</li><li>the API will not try to provide high level virtualization policies or
multi-nodes management features like load balancing, but the API should be
sufficient so they can be implemented on top of libvirt</li><li>stability of the API is a big concern, libvirt should isolate
applications from the frequent changes expected at the lower level of the
virtualization framework</li><li>the node being managed may be on a different physical machine than
the management program using libvirt, to this effect libvirt supports
remote access, but should only do so by using secure protocols.</li><li>libvirt will provide APIs to enumerate, monitor and use the resources
available on the managed node, including CPUs, memory, storage, networking,
and NUMA partitions.</li></ul>
<p>So libvirt is intended to be a building block for higher level
management tools and for applications focusing on virtualization of a
single node (the only exception being domain migration between node
capabilities which involves more than one node).</p>
</div>
</div>
<div id="footer">
<p id="sponsor">
Sponsored by:<br /><a href="http://et.redhat.com/"><img src="et.png" alt="Project sponsored by Red Hat Emerging Technology" /></a></p>
</div>
</body>
</html>

51
docs/goals.html.in Normal file
View File

@ -0,0 +1,51 @@
<?xml version="1.0"?>
<html>
<body>
<h1>Terminology and goals</h1>
<p>To avoid ambiguity about the terms used, here are the definitions
for some of the specific concepts used in libvirt documentation:</p>
<ul>
<li>a <strong>node</strong> is a single physical machine</li>
<li>an <strong>hypervisor</strong> is a layer of software allowing to
virtualize a node in a set of virtual machines with possibly different
configurations than the node itself</li>
<li>a <strong>domain</strong> is an instance of an operating system
(or subsystem in the case of container virtualization) running on a
virtualized machine provided by the hypervisor</li>
</ul>
<p class="image">
<img alt="Hypervisor and domains running on a node" src="node.gif"/>
</p>
<p>Now we can define the goal of libvirt: to provide a common generic
and stable layer to securely manage domains on a node. The node may be
distant and libvirt should provide all APIs needed to provision, create,
modify, monitor, control, migrate and stop the domains, within the limits
of the support of the hypervisor for those operations. Multiple mode may
be accessed with libvirt simultaneously but the APIs are limited to
single node operations.</p>
<p>This implies the following sub-goals:</p>
<ul>
<li>the API should not be targeted to a single virtualization environment
which also means 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
needed to manage domains on a node</li>
<li>the API will not try to provide high level virtualization policies or
multi-nodes management features like load balancing, but the API should be
sufficient so they can be implemented on top of libvirt</li>
<li>stability of the API is a big concern, libvirt should isolate
applications from the frequent changes expected at the lower level of the
virtualization framework</li>
<li>the node being managed may be on a different physical machine than
the management program using libvirt, to this effect libvirt supports
remote access, but should only do so by using secure protocols.</li>
<li>libvirt will provide APIs to enumerate, monitor and use the resources
available on the managed node, including CPUs, memory, storage, networking,
and NUMA partitions.</li>
</ul>
<p>So libvirt is intended to be a building block for higher level
management tools and for applications focusing on virtualization of a
single node (the only exception being domain migration between node
capabilities which involves more than one node).</p>
</body>
</html>

View File

@ -47,6 +47,10 @@
<div>
<span class="active">Architecture</span>
<ul class="l2"><li>
<div>
<a title="Terminology and goals of libvirt API" class="inactive" href="goals.html">Goals</a>
</div>
</li><li>
<div>
<a title="Managing virtual machines" class="inactive" href="archdomain.html">Domains</a>
</div>
@ -110,36 +114,12 @@
</div>
<div id="content">
<h1>Architecture</h1>
<p>Libvirt is a C toolkit to interact with the virtualization capabilities of
recent versions of Linux (and other OSes), but libvirt won't try to provide
all possible interfaces for interacting with the virtualization features.</p>
<p>To avoid ambiguity about the terms used here here are the definitions for
some of the specific concepts used in libvirt documentation:</p>
<ul><li>a <strong>node</strong> is a single physical machine</li><li>an <strong>hypervisor</strong> is a layer of software allowing to
virtualize a node in a set of virtual machines with possibly different
configurations than the node itself</li><li>a <strong>domain</strong> is an instance of an operating system running
on a virtualized machine provided by the hypervisor</li></ul>
<p class="image">
<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 targeted to a single virtualization environment
though Xen is the current default, which also means 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
needed to manage domains on a node</li><li>the API will not try to provide high level multi-nodes management
features like load balancing, though they could be implemented on top of
libvirt</li><li>stability of the API is a big concern, libvirt should isolate
applications from the frequent changes expected at the lower level of the
virtualization framework</li></ul>
<p>So libvirt should be a building block for higher level management tools
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
(extension for remote access support is being worked on, see <a href="bugs.html">the mailing list</a> discussions about it).</p>
<p>Libvirt is a C toolkit manage the virtualization capabilities
of recent versions of Linux (and other OSes).</p>
<p>To avoid ambiguity about the goals, terms and specific concepts used
in libvirt documentation please see the <a href="goals.html">Goal
section</a>.
</p>
</div>
</div>
<div id="footer">

View File

@ -2,45 +2,11 @@
<html>
<body>
<h1>Architecture</h1>
<p>Libvirt is a C toolkit to interact with the virtualization capabilities of
recent versions of Linux (and other OSes), but libvirt won't try to provide
all possible interfaces for interacting with the virtualization features.</p>
<p>To avoid ambiguity about the terms used here here are the definitions for
some of the specific concepts used in libvirt documentation:</p>
<ul>
<li>a <strong>node</strong> is a single physical machine</li>
<li>an <strong>hypervisor</strong> is a layer of software allowing to
virtualize a node in a set of virtual machines with possibly different
configurations than the node itself</li>
<li>a <strong>domain</strong> is an instance of an operating system running
on a virtualized machine provided by the hypervisor</li>
</ul>
<p class="image">
<img alt="Hypervisor and domains running on a node" src="node.gif"/>
<p>Libvirt is a C toolkit manage the virtualization capabilities
of recent versions of Linux (and other OSes).</p>
<p>To avoid ambiguity about the goals, terms and specific concepts used
in libvirt documentation please see the <a href="goals.html">Goal
section</a>.
</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 targeted to a single virtualization environment
though Xen is the current default, which also means 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
needed to manage domains on a node</li>
<li>the API will not try to provide high level multi-nodes management
features like load balancing, though they could be implemented on top of
libvirt</li>
<li>stability of the API is a big concern, libvirt should isolate
applications from the frequent changes expected at the lower level of the
virtualization framework</li>
</ul>
<p>So libvirt should be a building block for higher level management tools
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
(extension for remote access support is being worked on, see <a href="bugs.html">the mailing list</a> discussions about it).</p>
</body>
</html>

View File

@ -106,6 +106,9 @@
<a href="intro.html">Architecture</a>
<span>Overview of the logical subsystems in the libvirt API</span>
<ul><li>
<a href="goals.html">Goals</a>
<span>Terminology and goals of libvirt API</span>
</li><li>
<a href="archdomain.html">Domains</a>
<span>Managing virtual machines</span>
</li><li>

View File

@ -56,6 +56,10 @@
<a href="intro.html">Architecture</a>
<span>Overview of the logical subsystems in the libvirt API</span>
<ul>
<li>
<a href="goals.html">Goals</a>
<span>Terminology and goals of libvirt API</span>
</li>
<li>
<a href="archdomain.html">Domains</a>
<span>Managing virtual machines</span>