From: Erik Skultety Date: Fri, 12 Mar 2021 07:34:15 +0000 (+0100) Subject: docs: html.in: Drop the architecture page X-Git-Tag: v7.2.0-rc1~21 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=3bd8c779f487f7f592207ab05f815d4f85b6920b;p=thirdparty%2Flibvirt.git docs: html.in: Drop the architecture page The page isn't linked from anywhere and the contents is dated. Images related to the page are also dropped. Signed-off-by: Erik Skultety Reviewed-by: Pavel Hrdina --- diff --git a/docs/architecture.gif b/docs/architecture.gif deleted file mode 100644 index 9b820eef18..0000000000 Binary files a/docs/architecture.gif and /dev/null differ 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 @@ - - - - -

libvirt architecture

- -

- Currently libvirt supports 2 kind of virtualization, and its - internal structure is based on a driver model which simplifies - adding new - engines: -

- -

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

- - diff --git a/docs/architecture.svg b/docs/architecture.svg deleted file mode 100644 index 1e1555156b..0000000000 --- a/docs/architecture.svg +++ /dev/null @@ -1,239 +0,0 @@ - - - - - diff --git a/docs/meson.build b/docs/meson.build index d2e685f673..ab0932ceb4 100644 --- a/docs/meson.build +++ b/docs/meson.build @@ -7,7 +7,6 @@ docs_assets = [ 'android-chrome-192x192.png', 'android-chrome-256x256.png', 'apple-touch-icon.png', - 'architecture.gif', 'browserconfig.xml', 'favicon.ico', 'favicon-16x16.png', @@ -32,7 +31,6 @@ docs_assets = [ docs_html_in_files = [ '404', - 'architecture', 'bugs', 'cgroups', 'contact',