From nobody Fri Dec 19 07:20:11 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 216.205.24.124 as permitted sender) client-ip=216.205.24.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 216.205.24.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1615549512; cv=none; d=zohomail.com; s=zohoarc; b=e+CxLC3FyB3wH939Gt2Unp/RnEiKRvjW1rcyjk5ilKY8WvFvladre3kuaBUDbajvN93FbduudqZQ0RD1PZnclQThHo/3ed3xHcpFMrTEafc5OdRejA7O8g6M8ec7QL3ZtzqfWCETbhGYCSuqS5rYNSC77BCdGjhAx3+nvLR/JAU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1615549512; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=yfOkgjfPU3yfSJ2iTppR4YrtcGfvHOto/y/JpXYtNvY=; b=E5lLG/ApX5aYzFMZBAE7uts6JEcsINxcjT1l5V0POWBUUfHTGuc4CNXQD6A3Y/T2jfJb3bcI7IplDLQeWAsJI2kejyZNrRGHmBHOpzz+bAQ5xy61TFzfL/aZhQ/8La11eoF87cQ40tWgRnNMgFkCuurT9dBIxJmQEkQM3nhej8U= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 216.205.24.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.zohomail.com with SMTPS id 1615549512754182.7388161172571; Fri, 12 Mar 2021 03:45:12 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-381-fqlGEBAkMg6QcjQ3z4uNMQ-1; Fri, 12 Mar 2021 06:45:09 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E6A701084C99; Fri, 12 Mar 2021 11:45:02 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B8A1260C03; Fri, 12 Mar 2021 11:45:02 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 7136A57DC8; Fri, 12 Mar 2021 11:45:02 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 12CBhMXo024873 for ; Fri, 12 Mar 2021 06:43:22 -0500 Received: by smtp.corp.redhat.com (Postfix) id 1522919813; Fri, 12 Mar 2021 11:43:22 +0000 (UTC) Received: from nautilus.redhat.com (unknown [10.40.192.123]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6145350EDF; Fri, 12 Mar 2021 11:43:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615549511; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=yfOkgjfPU3yfSJ2iTppR4YrtcGfvHOto/y/JpXYtNvY=; b=CUU9H5wH5Yag6/AN6qEEGH57NCAjh0zJoTjb8Y6a8yaBTGDZft5T1a/Wt1Ne8NM1EG2bT8 UXbf3TeSbs/Dm6Do2I7ddlGhu0pq/1CHyn+qWlgOo07ob55XS2VPOkEfZExjoZ46sxjLTy fK33HuKjgsnuJ4TV0u/azun1Tt4PGA8= X-MC-Unique: fqlGEBAkMg6QcjQ3z4uNMQ-1 From: Erik Skultety To: libvir-list@redhat.com Subject: [libvirt PATCH 5/9] docs: html.in: Convert architecture to rst Date: Fri, 12 Mar 2021 12:43:08 +0100 Message-Id: In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-loop: libvir-list@redhat.com Cc: eskultet@redhat.com X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=libvir-list-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" Signed-off-by: Erik Skultety --- 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 @@ - - - - -

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 e= xecute -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 t= he -hypervisor, the backend drivers, any running domains, and libxl (aka libxe= nlight). -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 hyperv= isor, -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:

    - 3D"The -

    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 diffe= rs -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 t= he -QEMU or KVM process. That program called libvirt_qemud talks though a spec= ific -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 dif= ferent -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 thoug= h the - Xen Store
      • -
    • xen_internal: provide the implementation of the functions possib= le via - direct hypervisor access
      • -
    • proxy_internal: provide read-only Xen access via a proxy, the pr= oxy 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 funct= ions, -(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.rst b/docs/architecture.rst new file mode 100644 index 0000000000..f74906d36e --- /dev/null +++ b/docs/architecture.rst @@ -0,0 +1,83 @@ +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +libvirt architecture +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +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 =3D [ =20 docs_html_in_files =3D [ '404', - 'architecture', 'auditlog', 'auth', 'bindings', @@ -107,6 +106,7 @@ docs_rst_files =3D [ 'api_extension', 'api', 'apps', + 'architecture', 'best-practices', 'ci', 'coding-style', --=20 2.29.2