From nobody Sun Feb 8 22:49:33 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) client-ip=170.10.133.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 170.10.133.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=1654009768; cv=none; d=zohomail.com; s=zohoarc; b=ehwuPhv9+eRYsvk4Z+o5n+ldNEJB1jNvbe3h35CkEKAl7/vMg4foYMs2RWy6Vc/pCK0+Ad21I2v3KhwQ2NbROJ7PpZZp2MKY6mJd9mBACqgCczlHfXjPey11CqZaMhlTo7s6MzYWDODyJk4q0ZIF+y1CYGO9UHWfqfM6oncXldo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1654009768; h=Content-Type:Content-Transfer-Encoding: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=hpiwmogNZWaflyBdW3pIH/JUNpH+S4ApERlBNlqfZH4=; b=bwaKQiG8wR3ulIzCugdOh6gDET0+QGpancSGyVkpdMi7vXXKpWlS+kAKbDFA+/YWcGesg808fT1Qht602u/0x/+kNKhU19fE9GPPKwhRBG2rGRGgoUrP0rxKXk1bxoEIudn3BWJvEvH7EBLaRzh7lDBTe2HO2XjNLO7IhoTY/ys= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.zohomail.com with SMTPS id 1654009768051656.4384344058088; Tue, 31 May 2022 08:09:28 -0700 (PDT) Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-558-MbmWb6vHMT6ZlYu3108fXQ-1; Tue, 31 May 2022 11:07:57 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6BA1139796B1; Tue, 31 May 2022 15:07:04 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (unknown [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3F9DA2026D07; Tue, 31 May 2022 15:07:04 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 0EA481947073; Tue, 31 May 2022 15:07:04 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 097B51947062 for ; Tue, 31 May 2022 15:07:01 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id EF6261731B; Tue, 31 May 2022 15:07:00 +0000 (UTC) Received: from speedmetal.lan (unknown [10.40.208.21]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7D2F610725 for ; Tue, 31 May 2022 15:07:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1654009767; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=hpiwmogNZWaflyBdW3pIH/JUNpH+S4ApERlBNlqfZH4=; b=a4f5HpHJM5VrQYGxM/jE+oAZ0jpakWazRcmvyuk6XSPozg2Uc7lfG7gzIcRf5McqnfnPMa ZH7+dFHMSrHJShaca4ksJ5111O2LEiQ+6WCSTAwh0dZN73J83d5jQSNTsXS+DISL5V4WO2 T2BOrXTVgxegJg4hV0Sx9iCViaL13vI= X-MC-Unique: MbmWb6vHMT6ZlYu3108fXQ-1 X-Original-To: libvir-list@listman.corp.redhat.com From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH 20/67] docs: formatdomain: Remove 'elementsDisks' anchor Date: Tue, 31 May 2022 17:05:55 +0200 Message-Id: <74dcc83fb7b0bed2b7d9c8b4ea6e8dd578d6b3c6.1654008136.git.pkrempa@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libvir-list-bounces@redhat.com Sender: "libvir-list" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 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) X-ZM-MESSAGEID: 1654009769711100006 Content-Type: text/plain; charset="utf-8" Two paragraphs containing local links were reformulated and rewrapped. Signed-off-by: Peter Krempa --- docs/formatbackup.rst | 6 +++--- docs/formatcheckpoint.rst | 2 +- docs/formatdomain.rst | 21 +++++++++++---------- docs/formatsecret.rst | 10 +++++----- docs/formatsnapshot.rst | 6 +++--- docs/storage.rst | 6 +++--- 6 files changed, 26 insertions(+), 25 deletions(-) diff --git a/docs/formatbackup.rst b/docs/formatbackup.rst index c378ad9d9a..02847fd5d4 100644 --- a/docs/formatbackup.rst +++ b/docs/formatbackup.rst @@ -37,7 +37,7 @@ were supplied). The following child elements and attribut= es are supported: ``server`` Present only for a pull mode backup. Contains the same attributes as the - ```protocol`` element of a disk `__ at= tached + ```protocol`` element of a disk `__ attached via NBD in the domain (such as transport, socket, name, port, or tls), necessary to set up an NBD server that exposes the content of each disk= at the time the backup is started. @@ -61,7 +61,7 @@ were supplied). The following child elements and attribut= es are supported: ``name`` A mandatory attribute which must match the ```` of - one of the `disk devices `__ spe= cified + one of the `disk devices `__ specified for the domain at the time of the checkpoint. ``backup`` @@ -122,7 +122,7 @@ were supplied). The following child elements and attrib= utes are supported: file is not deleted after the backup but the contents of the file= don't make sense outside of the backup. The same applies for the block = device which must be formatted appropriately. Similarly to the domain - ```disk`` `__ definition ``scrat= ch`` + ```disk`` `__ = definition ``scratch`` and ``target`` can contain ``seclabel`` and/or ``encryption`` subelements to configure the corresponding properties. diff --git a/docs/formatcheckpoint.rst b/docs/formatcheckpoint.rst index ff3f1e8c00..496de4e1ff 100644 --- a/docs/formatcheckpoint.rst +++ b/docs/formatcheckpoint.rst @@ -69,7 +69,7 @@ The top-level ``domaincheckpoint`` element may contain th= e following elements: ``name`` A mandatory attribute which must match either the ```` or an unambiguous ```` of - one of the `disk devices `__ spe= cified + one of the `disk devices `__ specified for the domain at the time of the checkpoint. ``checkpoint`` diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 4f85366c9d..d1134c523f 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -239,7 +239,7 @@ harddisk, cdrom, network) determining where to obtain/f= ind the boot image. (the sorted list is vda, vdb, hda, hdc). Similar domain with hdc, vda, = vdb, and hda disks will boot from hda (sorted disks are: hda, hdc, vda, vdb)= . It can be tricky to configure in the desired way, which is why per-device = boot - elements (see `disks <#elementsDisks>`__, `network + elements (see `Hard drives, floppy disks, CDROMs`_, `network interfaces <#elementsNICS>`__, and `USB and PCI devices <#elementsHostD= ev>`__ sections below) were introduced and they are the preferred way providin= g full control over booting order. The ``boot`` element and per-device boot el= ements @@ -1186,12 +1186,13 @@ Block I/O Tuning ``device`` The domain may have multiple ``device`` elements that further tune the weights for each host block device in use by the domain. Note that mult= iple - `guest disks <#elementsDisks>`__ can share a single host block device, = if - they are backed by files within the same host file system, which is why= this - tuning parameter is at the global domain level rather than associated w= ith - each guest disk device (contrast this to the ` <#elementsDisks>= `__ - element which can apply to an individual ````). Each ``device`` e= lement - has two mandatory sub-elements, ``path`` describing the absolute path o= f the + disks (See `Hard drives, floppy disks, CDROMs`_) can share a single host + block device, if they are backed by files within the same host file sys= tem, + which is why this tuning parameter is at the global domain level rather= than + associated with each guest disk device (contrast this to the + element of a disk definition (See `Hard drives, floppy disks, CDROMs`_) + which can applies to an individual disk). Each ``device`` element has + two mandatory sub-elements, ``path`` describing the absolute path of the device, and ``weight`` giving the relative weight of that device, in the range [100, 1000]. After kernel 2.6.39, the value could be in the range= [10, 1000]. :since:`Since 0.9.8` @@ -2331,7 +2332,6 @@ following characters: ``[a-zA-Z0-9_-]``. :since:`Sinc= e 3.9.0` ... -:anchor:`` Hard drives, floppy disks, CDROMs ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -4118,7 +4118,7 @@ or: "unfiltered", where the default is "filtered". The optional ``rawio`= ` ( :since:`since 1.2.9` ) attribute indicates whether the lun needs the= rawio capability. Valid settings are "yes" or "no". See the rawio descript= ion - within the `disk <#elementsDisks>`__ section. If a disk lun in the d= omain + within the `Hard drives, floppy disks, CDROMs`_ section. If a disk l= un in the domain already has the rawio capability, then this setting not required. ``scsi_host`` :since:`since 2.5.0` For SCSI devices, user is responsible to make s= ure @@ -4197,7 +4197,8 @@ or: :since:`Since 1.2.8` , the ``source`` element of a SCSI device may c= ontain the ``protocol`` attribute. When the attribute is set to "iscsi", th= e host - device XML follows the network `disk <#elementsDisks>`__ device usin= g the + device XML follows the network disk device + (See `Hard drives, floppy disks, CDROMs`_) using the same ``name`` attribute and optionally using the ``auth`` element to provide the authentication credentials to the iSCSI server. diff --git a/docs/formatsecret.rst b/docs/formatsecret.rst index 03c2836843..0327430078 100644 --- a/docs/formatsecret.rst +++ b/docs/formatsecret.rst @@ -65,7 +65,7 @@ using ``virsh secret-set-value``. The volume type secret can be supplied either in volume XML during creatio= n of a `storage volume `__ in order to pro= vide the passphrase to encrypt the volume or in domain XML -`disk device `__ in order to provide the +`disk device `__ in ord= er to provide the passphrase to decrypt the volume, :since:`since 2.1.0` . An example follow= s: :: @@ -101,7 +101,7 @@ This secret is associated with a Ceph RBD (rados block = device). The ```` element must contain a single ``name`` element t= hat specifies a usage name for the secret. The Ceph secret can then be used by= UUID or by this usage name via the ```` element of a `disk -device `__ or a `storage pool +device `__ or a `storag= e pool (rbd) `__. :since:`Since 0.9.7` . The following is an example of the steps to be taken. First create a ceph-secret.xml file: @@ -132,7 +132,7 @@ See `Setting secret values in virsh`_ on how to set the= value of the secret using ``virsh secret-set-value``. The ceph secret can then be used by UUID or by the usage name via the ```` -element in a domain's ` `__ element= as +element in a domain's ` `__ element as follows: :: @@ -157,7 +157,7 @@ This secret is associated with an iSCSI target for CHAP= authentication. The ```` element must contain a single ``target`` elemen= t that specifies a usage name for the secret. The iSCSI secret can then be used b= y UUID or by this usage name via the ```` element of a `disk -device `__ or a `storage pool +device `__ or a `storag= e pool (iscsi) `__. :since:`Since 1.0.4` . The following is an example of the XML that may be used to generate a secret for iSCSI CHAP authentication. Assume the following sample entry in an iSCSI authenticati= on @@ -207,7 +207,7 @@ See `Setting secret values in virsh`_ on how to set the= value of the secret using ``virsh secret-set-value``. The iSCSI secret can then be used by UUID or by the usage name via the -```` element in a domain's ` = `__ +```` element in a domain's ` `__ element as follows: :: diff --git a/docs/formatsnapshot.rst b/docs/formatsnapshot.rst index dd742a3063..07aa03c0a7 100644 --- a/docs/formatsnapshot.rst +++ b/docs/formatsnapshot.rst @@ -115,11 +115,11 @@ The top-level ``domainsnapshot`` element may contain = the following elements: This sub-element describes the snapshot properties of a specific dis= k. The attribute ``name`` is mandatory, and must match either the ```` (recommended) or an unambiguous ```` - of one of the `disk devices `__ + of one of the `disk devices `__ specified for the domain at the time of the snapshot. The attribute ``snapshot`` is optional, and the possible values are the same as the ``snapshot`` attribute for `disk devices - `__ (``no``, ``internal``, or + `__ (``no``, ``in= ternal``, or ``external``). Some hypervisors like ESX require that if specified, = the snapshot mode must not override any snapshot mode attached to the corresponding domain disk, while others like qemu allow this field to @@ -140,7 +140,7 @@ The top-level ``domainsnapshot`` element may contain th= e following elements: overwrite the default ``file`` type. The ``type`` attribute along wi= th the format of the ``source`` sub-element is identical to the ``sourc= e`` element used in domain disk definitions. See the `disk devices - `__ section documentation for furth= er + `__ section docum= entation for further information. Libvirt currently supports the ``type`` element in the = qemu driver and supported values are ``file``, ``block`` and ``network`` :since:`(since 1.2.2)`. diff --git a/docs/storage.rst b/docs/storage.rst index b860648628..9d5b193e31 100644 --- a/docs/storage.rst +++ b/docs/storage.rst @@ -557,7 +557,7 @@ Example RBD disk attachment RBD images can be attached to QEMU guests when QEMU is built with RBD supp= ort. Information about attaching a RBD image to a guest can be found at `format -domain `__ page. +domain `__ page. Valid RBD pool format types ~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -618,7 +618,7 @@ Example Sheepdog disk attachment Sheepdog images can be attached to QEMU guests. Information about attachin= g a Sheepdog image to a guest can be found at the `format -domain `__ page. +domain `__ page. Valid Sheepdog pool format types ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -698,7 +698,7 @@ Example Gluster disk attachment Files within a gluster volume can be attached to QEMU guests. Information = about attaching a Gluster image to a guest can be found at the `format -domain `__ page. +domain `__ page. Valid Gluster pool format types ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --=20 2.35.3