Signed-off-by: Erik Skultety <eskultet@xxxxxxxxxx> --- 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
