~nova-coresec/ubuntu/maverick/libvirt/nova-ppa

« back to all changes in this revision

Viewing changes to docs/intro.html.in

Tags: 0.4.4-3
* upload to unstable
* [96c6727] add /var/cache/libvirt needed by qemuDriver for temporary
  storage
* [794f95c] bump standards version to 3.8.0
* [05184af] add README.source

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
<?xml version="1.0"?>
 
2
<html>
 
3
  <body>
 
4
    <h1>Architecture</h1>
 
5
    <p>Libvirt is a C toolkit to interact with the virtualization capabilities of
 
6
recent versions of Linux (and other OSes), but libvirt won't try to provide
 
7
all possible interfaces for interacting with the virtualization features.</p>
 
8
    <p>To avoid ambiguity about the terms used here here are the definitions for
 
9
some of the specific concepts used in libvirt documentation:</p>
 
10
    <ul>
 
11
      <li>a <strong>node</strong> is a single physical machine</li>
 
12
      <li>an <strong>hypervisor</strong> is a layer of software allowing to
 
13
    virtualize a node in a set of virtual machines with possibly different
 
14
    configurations than the node itself</li>
 
15
      <li>a <strong>domain</strong> is an instance of an operating system running
 
16
    on a virtualized machine provided by the hypervisor</li>
 
17
    </ul>
 
18
    <p class="image">
 
19
      <img alt="Hypervisor and domains running on a node" src="node.gif"/>
 
20
    </p>
 
21
    <p>Now we can define the goal of libvirt: to provide the lowest possible
 
22
generic and stable layer to manage domains on a node.</p>
 
23
    <p>This implies the following:</p>
 
24
    <ul>
 
25
      <li>the API should not be targeted to a single virtualization environment
 
26
    though Xen is the current default, which also means that some very
 
27
    specific capabilities which are not generic enough may not be provided as
 
28
    libvirt APIs</li>
 
29
      <li>the API should allow to do efficiently and cleanly all the operations
 
30
    needed to manage domains on a node</li>
 
31
      <li>the API will not try to provide high level multi-nodes management
 
32
    features like load balancing, though they could be implemented on top of
 
33
    libvirt</li>
 
34
      <li>stability of the API is a big concern, libvirt should isolate
 
35
    applications from the frequent changes expected at the lower level of the
 
36
    virtualization framework</li>
 
37
    </ul>
 
38
    <p>So libvirt should be a building block for higher level management tools
 
39
and for applications focusing on virtualization of a single node (the only
 
40
exception being domain migration between node capabilities which may need to
 
41
be added at the libvirt level). Where possible libvirt should be extendable
 
42
to be able to provide the same API for remote nodes, however this is not the
 
43
case at the moment, the code currently handle only local node accesses
 
44
(extension for remote access support is being worked on, see <a href="bugs.html">the mailing list</a> discussions about it).</p>
 
45
  </body>
 
46
</html>