5:43 a.m.
Signed-off-by: Erik Skultety <eskultet(a)redhat.com>
---
docs/architecture.html.in | 82 --------------------------------------
docs/architecture.rst | 83 +++++++++++++++++++++++++++++++++++++++
docs/meson.build | 2 +-
3 files changed, 84 insertions(+), 83 deletions(-)
delete mode 100644 docs/architecture.html.in
create mode 100644 docs/architecture.rst
diff --git a/docs/architecture.html.in b/docs/architecture.html.in
deleted file mode 100644
index 7a5cf2dca8..0000000000
--- a/docs/architecture.html.in
+++ /dev/null
@@ -1,82 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
- <body>
- <h1 >libvirt architecture</h1>
-
- <p>
- Currently libvirt supports 2 kind of virtualization, and its
- internal structure is based on a driver model which simplifies
- adding new
- engines:
- </p>
-
- <ul id="toc"></ul>
-
- <h2><a id="Xen">Xen support</a></h2>
-
- <p>When running in a Xen environment, programs using libvirt have to execute
-in "Domain 0", which is the primary Linux OS loaded on the machine. That OS
-kernel provides most if not all of the actual drivers used by the set of
-domains. It also runs the Xen Store, a database of information shared by the
-hypervisor, the backend drivers, any running domains, and libxl (aka libxenlight).
-libxl provides a set of APIs for creating and managing domains, which can be used
-by applications such as the xl tool provided by Xen or libvirt. The hypervisor,
-drivers, kernels and daemons communicate though a shared system bus
-implemented in the hypervisor. The figure below tries to provide a view of
-this environment:</p>
- <img src="architecture.gif" alt="The Xen architecture" />
- <p>The library will interact with libxl for all management operations
-on a Xen system.</p>
- <p>Note that the libvirt libxl driver only supports root access.</p>
-
- <h2><a id="QEMU">QEMU and KVM support</a></h2>
-
- <p>The model for QEMU and KVM is completely similar, basically KVM is based
-on QEMU for the process controlling a new domain, only small details differs
-between the two. In both case the libvirt API is provided by a controlling
-process forked by libvirt in the background and which launch and control the
-QEMU or KVM process. That program called libvirt_qemud talks though a specific
-protocol to the library, and connects to the console of the QEMU process in
-order to control and report on its status. Libvirt tries to expose all the
-emulations models of QEMU, the selection is done when creating the new
-domain, by specifying the architecture and machine type targeted.</p>
- <p>The code controlling the QEMU process is available in the
-<code>qemud/</code> directory.</p>
-
- <h2><a id="drivers">Driver based
architecture</a></h2>
-
- <p>As the previous section explains, libvirt can communicate using different
-channels with the current hypervisor, and should also be able to use
-different kind of hypervisor. To simplify the internal design, code, ease
-maintenance and simplify the support of other virtualization engine the
-internals have been structured as one core component, the libvirt.c module
-acting as a front-end for the library API and a set of hypervisor drivers
-defining a common set of routines. That way the Xen Daemon access, the Xen
-Store one, the Hypervisor hypercall are all isolated in separate C modules
-implementing at least a subset of the common operations defined by the
-drivers present in driver.h:</p>
- <ul>
- <li>xend_internal: implements the driver functions though the Xen
- Daemon</li>
- <li>xs_internal: implements the subset of the driver available though the
- Xen Store</li>
- <li>xen_internal: provide the implementation of the functions possible via
- direct hypervisor access</li>
- <li>proxy_internal: provide read-only Xen access via a proxy, the proxy code
- is in the <code>proxy/</code> directory.</li>
- <li>xm_internal: provide support for Xen defined but not running
- domains.</li>
- <li>qemu_internal: implement the driver functions for QEMU and
- KVM virtualization engines. It also uses a qemud/ specific daemon
- which interacts with the QEMU process to implement libvirt API.</li>
- <li>test: this is a test driver useful for regression tests of the
- front-end part of libvirt.</li>
- </ul>
- <p>Note that a given driver may only implement a subset of those functions,
-(for example saving a Xen domain state to disk and restoring it is only
-possible though the Xen Daemon), in that case the driver entry points for
-unsupported functions are initialized to NULL.</p>
- <p></p>
- </body>
-</html>
diff --git a/docs/architecture.rst b/docs/architecture.rst
new file mode 100644
index 0000000000..f74906d36e
--- /dev/null
+++ b/docs/architecture.rst
@@ -0,0 +1,83 @@
+====================
+libvirt architecture
+====================
+
+Currently libvirt supports 2 kind of virtualization, and its internal
+structure is based on a driver model which simplifies adding new
+engines:
+
+.. contents::
+
+Xen support
+-----------
+
+When running in a Xen environment, programs using libvirt have to
+execute in "Domain 0", which is the primary Linux OS loaded on the
+machine. That OS kernel provides most if not all of the actual drivers
+used by the set of domains. It also runs the Xen Store, a database of
+information shared by the hypervisor, the backend drivers, any running
+domains, and libxl (aka libxenlight). libxl provides a set of APIs for
+creating and managing domains, which can be used by applications such as
+the xl tool provided by Xen or libvirt. The hypervisor, drivers, kernels
+and daemons communicate though a shared system bus implemented in the
+hypervisor. The figure below tries to provide a view of this
+environment:
+
+|The Xen architecture|
+
+The library will interact with libxl for all management operations on a
+Xen system.
+
+Note that the libvirt libxl driver only supports root access.
+
+QEMU and KVM support
+--------------------
+
+The model for QEMU and KVM is completely similar, basically KVM is based
+on QEMU for the process controlling a new domain, only small details
+differs between the two. In both case the libvirt API is provided by a
+controlling process forked by libvirt in the background and which launch
+and control the QEMU or KVM process. That program called libvirt_qemud
+talks though a specific protocol to the library, and connects to the
+console of the QEMU process in order to control and report on its
+status. Libvirt tries to expose all the emulations models of QEMU, the
+selection is done when creating the new domain, by specifying the
+architecture and machine type targeted.
+
+The code controlling the QEMU process is available in the ``qemud/``
+directory.
+
+Driver based architecture
+-------------------------
+
+As the previous section explains, libvirt can communicate using
+different channels with the current hypervisor, and should also be able
+to use different kind of hypervisor. To simplify the internal design,
+code, ease maintenance and simplify the support of other virtualization
+engine the internals have been structured as one core component, the
+libvirt.c module acting as a front-end for the library API and a set of
+hypervisor drivers defining a common set of routines. That way the Xen
+Daemon access, the Xen Store one, the Hypervisor hypercall are all
+isolated in separate C modules implementing at least a subset of the
+common operations defined by the drivers present in driver.h:
+
+- xend_internal: implements the driver functions though the Xen Daemon
+- xs_internal: implements the subset of the driver available though the
+ Xen Store
+- xen_internal: provide the implementation of the functions possible
+ via direct hypervisor access
+- proxy_internal: provide read-only Xen access via a proxy, the proxy
+ code is in the ``proxy/`` directory.
+- xm_internal: provide support for Xen defined but not running domains.
+- qemu_internal: implement the driver functions for QEMU and KVM
+ virtualization engines. It also uses a qemud/ specific daemon which
+ interacts with the QEMU process to implement libvirt API.
+- test: this is a test driver useful for regression tests of the
+ front-end part of libvirt.
+
+Note that a given driver may only implement a subset of those functions,
+(for example saving a Xen domain state to disk and restoring it is only
+possible though the Xen Daemon), in that case the driver entry points
+for unsupported functions are initialized to NULL.
+
+.. |The Xen architecture| image:: architecture.gif
diff --git a/docs/meson.build b/docs/meson.build
index b61377ea8b..0e0c266cb9 100644
--- a/docs/meson.build
+++ b/docs/meson.build
@@ -32,7 +32,6 @@ docs_assets = [
docs_html_in_files = [
'404',
- 'architecture',
'auditlog',
'auth',
'bindings',
@@ -107,6 +106,7 @@ docs_rst_files = [
'api_extension',
'api',
'apps',
+ 'architecture',
'best-practices',
'ci',
'coding-style',
--
2.29.2