Relatively small update done in the train yesterday, currently this just updates the project description, makes a spearate page for goals and terminology. I intent to continue to revamp the architecture pages with an user view of the architecture, presenting the library/daemon dichotomy, and then a separate page more on the driver internals. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
Index: docs/goals.html =================================================================== RCS file: docs/goals.html diff -N docs/goals.html --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ docs/goals.html 2 Apr 2009 09:44:38 -0000 @@ -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 manage domains on a node. The node may be distant + and libvirt should provide all APIs needed to provision, create, modify, + monitor, 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 do so only 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 may need to be added at the libvirt level).</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> Index: docs/goals.html.in =================================================================== RCS file: docs/goals.html.in diff -N docs/goals.html.in --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ docs/goals.html.in 2 Apr 2009 09:44:38 -0000 @@ -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> Index: docs/intro.html =================================================================== RCS file: /data/cvs/libxen/docs/intro.html,v retrieving revision 1.47 diff -u -r1.47 intro.html --- docs/intro.html 15 May 2008 06:12:32 -0000 1.47 +++ docs/intro.html 2 Apr 2009 09:44:38 -0000 @@ -48,6 +48,10 @@ <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> </li><li> @@ -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 to interact with 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"> Index: docs/intro.html.in =================================================================== RCS file: /data/cvs/libxen/docs/intro.html.in,v retrieving revision 1.2 diff -u -r1.2 intro.html.in --- docs/intro.html.in 15 May 2008 06:12:32 -0000 1.2 +++ docs/intro.html.in 2 Apr 2009 09:44:38 -0000 @@ -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> Index: docs/sitemap.html =================================================================== RCS file: /data/cvs/libxen/docs/sitemap.html,v retrieving revision 1.11 diff -u -r1.11 sitemap.html --- docs/sitemap.html 23 Dec 2008 13:47:10 -0000 1.11 +++ docs/sitemap.html 2 Apr 2009 09:44:38 -0000 @@ -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</span> + </li>> <a href="archdomain.html">Domains</a> <span>Managing virtual machines</span> </li><li> Index: docs/sitemap.html.in =================================================================== RCS file: /data/cvs/libxen/docs/sitemap.html.in,v retrieving revision 1.4 diff -u -r1.4 sitemap.html.in --- docs/sitemap.html.in 23 Dec 2008 13:47:10 -0000 1.4 +++ docs/sitemap.html.in 2 Apr 2009 09:44:38 -0000 @@ -57,6 +57,10 @@ <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>
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list