+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
<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>
<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>
<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>
<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>
--- /dev/null
+<?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>
--- /dev/null
+<?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>
<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>
</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">
<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>
<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>
<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>
projects / libvirt.git / commitdiff