From 89dd05cc6ff5829c063df1abd6d028ba28fa512c Mon Sep 17 00:00:00 2001 From: Daniel Veillard Date: Thu, 2 Apr 2009 12:01:11 +0000 Subject: [PATCH] * docs/*: start cleanup/revamp of architecture docs daniel --- ChangeLog | 4 ++ docs/archdomain.html | 4 ++ docs/archnetwork.html | 4 ++ docs/archnode.html | 4 ++ docs/archstorage.html | 4 ++ docs/goals.html | 157 ++++++++++++++++++++++++++++++++++++++++++ docs/goals.html.in | 51 ++++++++++++++ docs/intro.html | 40 +++-------- docs/intro.html.in | 44 ++---------- docs/sitemap.html | 3 + docs/sitemap.html.in | 4 ++ 11 files changed, 250 insertions(+), 69 deletions(-) create mode 100644 docs/goals.html create mode 100644 docs/goals.html.in diff --git a/ChangeLog b/ChangeLog index 52a94369d3..9fc5bacf13 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,7 @@ +Thu Apr 2 14:00:14 CEST 2009 Daniel Veillard + + * docs/*: start cleanup/revamp of architecture docs + Thu Apr 2 11:52:59 CEST 2009 Daniel Veillard * po/*: updated brazilian, spanish, polish and simplified chinese diff --git a/docs/archdomain.html b/docs/archdomain.html index 4948813dd6..a6b65b8e95 100644 --- a/docs/archdomain.html +++ b/docs/archdomain.html @@ -47,6 +47,10 @@
Architecture
  • +
    + Goals +
    +
  • Domains
    diff --git a/docs/archnetwork.html b/docs/archnetwork.html index 111f7a9c59..7498da7b5f 100644 --- a/docs/archnetwork.html +++ b/docs/archnetwork.html @@ -47,6 +47,10 @@
    Architecture
    • +
      + Goals +
      +
    • diff --git a/docs/archnode.html b/docs/archnode.html index 6ac0ee5d14..ee75ee98cd 100644 --- a/docs/archnode.html +++ b/docs/archnode.html @@ -47,6 +47,10 @@
      Architecture
      • +
        + Goals +
        +
      • diff --git a/docs/archstorage.html b/docs/archstorage.html index 590a780e1f..f3e6b54cd1 100644 --- a/docs/archstorage.html +++ b/docs/archstorage.html @@ -47,6 +47,10 @@
        Architecture
        • +
          + Goals +
          +
        • diff --git a/docs/goals.html b/docs/goals.html new file mode 100644 index 0000000000..1f45e2d520 --- /dev/null +++ b/docs/goals.html @@ -0,0 +1,157 @@ + + + + + + + + + libvirt: Terminology and goals + + + + +
          + +
          +

          Terminology and goals

          +

          To avoid ambiguity about the terms used, here are the definitions + for some of the specific concepts used in libvirt documentation:

          +
          • a node is a single physical machine
          • an hypervisor is a layer of software allowing to + virtualize a node in a set of virtual machines with possibly different + configurations than the node itself
          • a domain is an instance of an operating system + (or subsystem in the case of container virtualization) running on a + virtualized machine provided by the hypervisor
          +

          + Hypervisor and domains running on a node

          +

          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.

          +

          This implies the following sub-goals:

          +
          • 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
          • the API should allow to do efficiently and cleanly all the operations + needed to manage domains on a node
          • 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
          • 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
          • 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.
          • libvirt will provide APIs to enumerate, monitor and use the resources + available on the managed node, including CPUs, memory, storage, networking, + and NUMA partitions.
          +

          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).

          +
          +
          + + + diff --git a/docs/goals.html.in b/docs/goals.html.in new file mode 100644 index 0000000000..8e70f104d5 --- /dev/null +++ b/docs/goals.html.in @@ -0,0 +1,51 @@ + + + +

          Terminology and goals

          +

          To avoid ambiguity about the terms used, here are the definitions + for some of the specific concepts used in libvirt documentation:

          +
            +
          • a node is a single physical machine
            • +
          • an hypervisor is a layer of software allowing to + virtualize a node in a set of virtual machines with possibly different + configurations than the node itself
            • +
          • a domain is an instance of an operating system + (or subsystem in the case of container virtualization) running on a + virtualized machine provided by the hypervisor
            • +
          +

          + Hypervisor and domains running on a node +

          +

          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.

          +

          This implies the following sub-goals:

          +
            +
          • 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
            • +
          • the API should allow to do efficiently and cleanly all the operations + needed to manage domains on a node
            • +
          • 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
            • +
          • 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
            • +
          • 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.
            • +
          • libvirt will provide APIs to enumerate, monitor and use the resources + available on the managed node, including CPUs, memory, storage, networking, + and NUMA partitions.
            • +
          +

          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).

          + + diff --git a/docs/intro.html b/docs/intro.html index 48f7a386bb..3a453859c6 100644 --- a/docs/intro.html +++ b/docs/intro.html @@ -47,6 +47,10 @@
          Architecture

          Architecture

          -

          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.

          -

          To avoid ambiguity about the terms used here here are the definitions for -some of the specific concepts used in libvirt documentation:

          -
          • a node is a single physical machine
          • an hypervisor is a layer of software allowing to - virtualize a node in a set of virtual machines with possibly different - configurations than the node itself
          • a domain is an instance of an operating system running - on a virtualized machine provided by the hypervisor
          -

          - Hypervisor and domains running on a node

          -

          Now we can define the goal of libvirt: to provide the lowest possible -generic and stable layer to manage domains on a node.

          -

          This implies the following:

          -
          • 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
          • the API should allow to do efficiently and cleanly all the operations - needed to manage domains on a node
          • 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
          • 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
          -

          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 the mailing list discussions about it).

          +

          Libvirt is a C toolkit manage the virtualization capabilities + of recent versions of Linux (and other OSes).

          +

          To avoid ambiguity about the goals, terms and specific concepts used + in libvirt documentation please see the Goal + section. +