docs: Don't use "line blocks"

It's unclear why the conversion process decided to insert
them, but they don't seem to do much.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>

diff --git a/docs/bugs.rst b/docs/bugs.rst
index b5d2e42b0c8d012f3ca466da6a4596ce73debef9..5fd1970caffa75142c740193f9809fdbf5218f4a 100644 (file)
--- a/docs/bugs.rst
+++ b/docs/bugs.rst
@@ -99,13 +99,13 @@ that for the data to be really useful libvirt debug information must be present
 for example by installing libvirt debuginfo package on Fedora or Red Hat
 Enterprise Linux (with debuginfo-install libvirt) prior to running gdb.
 
-| It may also happen that the libvirt daemon itself crashes or gets stuck, in
-  the first case run it (as root) under gdb, and reproduce the sequence leading
-  to the crash, similarly to a normal program provide the "bt" backtrace
-  information to where gdb will have stopped.
-| But if libvirtd gets stuck, for example seems to stop processing commands, try
-  to attach to the faulty daemon and issue a gdb command "thread apply all bt"
-  to show all the threads backtraces, as in:
+It may also happen that the libvirt daemon itself crashes or gets stuck, in
+the first case run it (as root) under gdb, and reproduce the sequence leading
+to the crash, similarly to a normal program provide the "bt" backtrace
+information to where gdb will have stopped.
+But if libvirtd gets stuck, for example seems to stop processing commands, try
+to attach to the faulty daemon and issue a gdb command "thread apply all bt"
+to show all the threads backtraces, as in:
 
 ::
 

diff --git a/docs/firewall.rst b/docs/firewall.rst
index eff9de5a89db1f92adb9d401f9da3fe4090aeac8..26474d3317102449063fe14d29bc961162163c29 100644 (file)
--- a/docs/firewall.rst
+++ b/docs/firewall.rst
@@ -77,8 +77,9 @@ LAN/WAN.
 The next rules depend on the type of connectivity allowed, and go in the main
 FORWARD chain:
 
--  | type=isolated
-   | Allow traffic between guests. Deny inbound. Deny outbound.
+-  type=isolated
+
+   Allow traffic between guests. Deny inbound. Deny outbound.
 
    ::
 
@@ -87,10 +88,11 @@ FORWARD chain:
       REJECT     all  --  *      virbr1  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
       REJECT     all  --  virbr1 *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
 
--  | type=nat
-   | Allow inbound related to an established connection. Allow outbound, but
-     only from our expected subnet. Allow traffic between guests. Deny all other
-     inbound. Deny all other outbound.
+-  type=nat
+
+   Allow inbound related to an established connection. Allow outbound, but
+   only from our expected subnet. Allow traffic between guests. Deny all other
+   inbound. Deny all other outbound.
 
    ::
 
@@ -101,10 +103,11 @@ FORWARD chain:
       REJECT     all  --  *      virbr0  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
       REJECT     all  --  virbr0 *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
 
--  | type=routed
-   | Allow inbound, but only to our expected subnet. Allow outbound, but only
-     from our expected subnet. Allow traffic between guests. Deny all other
-     inbound. Deny all other outbound.
+-  type=routed
+
+   Allow inbound, but only to our expected subnet. Allow outbound, but only
+   from our expected subnet. Allow traffic between guests. Deny all other
+   inbound. Deny all other outbound.
 
    ::
 

diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index fa42883809dfd6fd732380f4a2023deae25a858b..f56f40d5cc640ecc9b74efed13a93c82949753e5 100644 (file)
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -5118,14 +5118,15 @@ integration is required.
 Direct attachment to physical interface
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-| Provides direct attachment of the virtual machine's NIC to the given physical
-  interface of the host. :since:`Since 0.7.7 (QEMU and KVM only)`
-| This setup requires the Linux macvtap driver to be available. :since:`(Since
-  Linux 2.6.34.)` One of the modes 'vepa' ( `'Virtual Ethernet Port
-  Aggregator' <https://www.ieee802.org/1/files/public/docs2009/new-evb-congdon-vepa-modular-0709-v01.pdf>`__),
-  'bridge' or 'private' can be chosen for the operation mode of the macvtap
-  device, 'vepa' being the default mode. The individual modes cause the delivery
-  of packets to behave as follows:
+Provides direct attachment of the virtual machine's NIC to the given physical
+interface of the host. :since:`Since 0.7.7 (QEMU and KVM only)`
+
+This setup requires the Linux macvtap driver to be available. :since:`(Since
+Linux 2.6.34.)` One of the modes 'vepa' ( `'Virtual Ethernet Port
+Aggregator' <https://www.ieee802.org/1/files/public/docs2009/new-evb-congdon-vepa-modular-0709-v01.pdf>`__),
+'bridge' or 'private' can be chosen for the operation mode of the macvtap
+device, 'vepa' being the default mode. The individual modes cause the delivery
+of packets to behave as follows:
 
 If the model type is set to ``virtio`` and interface's ``trustGuestRxFilters``
 attribute is set to ``yes``, changes made to the interface mac address,

diff --git a/docs/hooks.rst b/docs/hooks.rst
index bd197c0d6e3319f356ddaa2534f106307c1c4101..4a0454a454d472db1ba0fb9495c59086822b9c56 100644 (file)
--- a/docs/hooks.rst
+++ b/docs/hooks.rst
@@ -151,20 +151,20 @@ This translates to the following specifics for each hook script:
 /etc/libvirt/hooks/daemon
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
--  | When the libvirt daemon is started, this script is called as:
+-  When the libvirt daemon is started, this script is called as:
 
    ::
 
       /etc/libvirt/hooks/daemon - start - start
 
--  | When the libvirt daemon is shut down, this script is called as:
+-  When the libvirt daemon is shut down, this script is called as:
 
    ::
 
       /etc/libvirt/hooks/daemon - shutdown - shutdown
 
--  | When the libvirt daemon receives the SIGHUP signal, it reloads its
-     configuration and triggers the hook script as:
+-  When the libvirt daemon receives the SIGHUP signal, it reloads its
+   configuration and triggers the hook script as:
 
    ::
 
@@ -177,41 +177,41 @@ operation. There is no specific operation to indicate a "restart" is occurring.
 /etc/libvirt/hooks/qemu
 ^^^^^^^^^^^^^^^^^^^^^^^
 
--  | Before a QEMU guest is started, the qemu hook script is called in three
-     locations; if any location fails, the guest is not started. The first
-     location, :since:`since 0.9.0` , is before libvirt performs any resource
-     labeling, and the hook can allocate resources not managed by libvirt such
-     as DRBD or missing bridges. This is called as:
+-  Before a QEMU guest is started, the qemu hook script is called in three
+   locations; if any location fails, the guest is not started. The first
+   location, :since:`since 0.9.0` , is before libvirt performs any resource
+   labeling, and the hook can allocate resources not managed by libvirt such
+   as DRBD or missing bridges. This is called as:
 
    ::
 
       /etc/libvirt/hooks/qemu guest_name prepare begin -
 
-   | The second location, available :since:`Since 0.8.0` , occurs after libvirt
-     has finished labeling all resources, but has not yet started the guest,
-     called as:
+   The second location, available :since:`Since 0.8.0` , occurs after libvirt
+   has finished labeling all resources, but has not yet started the guest,
+   called as:
 
    ::
 
       /etc/libvirt/hooks/qemu guest_name start begin -
 
-   | The third location, :since:`0.9.13` , occurs after the QEMU process has
-     successfully started up:
+   The third location, :since:`0.9.13` , occurs after the QEMU process has
+   successfully started up:
 
    ::
 
       /etc/libvirt/hooks/qemu guest_name started begin -
 
--  | When a QEMU guest is stopped, the qemu hook script is called in two
-     locations, to match the startup. First, :since:`since 0.8.0` , the hook is
-     called before libvirt restores any labels:
+-  When a QEMU guest is stopped, the qemu hook script is called in two
+   locations, to match the startup. First, :since:`since 0.8.0` , the hook is
+   called before libvirt restores any labels:
 
    ::
 
       /etc/libvirt/hooks/qemu guest_name stopped end -
 
-   | Then, after libvirt has released all resources, the hook is called again,
-     :since:`since 0.9.0` , to allow any additional resource cleanup:
+   Then, after libvirt has released all resources, the hook is called again,
+   :since:`since 0.9.0` , to allow any additional resource cleanup:
 
    ::
 
@@ -274,41 +274,41 @@ operation. There is no specific operation to indicate a "restart" is occurring.
 /etc/libvirt/hooks/lxc
 ^^^^^^^^^^^^^^^^^^^^^^
 
--  | Before a LXC guest is started, the lxc hook script is called in three
-     locations; if any location fails, the guest is not started. The first
-     location, :since:`since 0.9.13` , is before libvirt performs any resource
-     labeling, and the hook can allocate resources not managed by libvirt such
-     as DRBD or missing bridges. This is called as:
+-  Before a LXC guest is started, the lxc hook script is called in three
+   locations; if any location fails, the guest is not started. The first
+   location, :since:`since 0.9.13` , is before libvirt performs any resource
+   labeling, and the hook can allocate resources not managed by libvirt such
+   as DRBD or missing bridges. This is called as:
 
    ::
 
       /etc/libvirt/hooks/lxc guest_name prepare begin -
 
-   | The second location, available :since:`Since 0.8.0` , occurs after libvirt
-     has finished labeling all resources, but has not yet started the guest,
-     called as:
+   The second location, available :since:`Since 0.8.0` , occurs after libvirt
+   has finished labeling all resources, but has not yet started the guest,
+   called as:
 
    ::
 
       /etc/libvirt/hooks/lxc guest_name start begin -
 
-   | The third location, :since:`0.9.13` , occurs after the LXC process has
-     successfully started up:
+   The third location, :since:`0.9.13` , occurs after the LXC process has
+   successfully started up:
 
    ::
 
       /etc/libvirt/hooks/lxc guest_name started begin -
 
--  | When a LXC guest is stopped, the lxc hook script is called in two
-     locations, to match the startup. First, :since:`since 0.8.0` , the hook is
-     called before libvirt restores any labels:
+-  When a LXC guest is stopped, the lxc hook script is called in two
+   locations, to match the startup. First, :since:`since 0.8.0` , the hook is
+   called before libvirt restores any labels:
 
    ::
 
       /etc/libvirt/hooks/lxc guest_name stopped end -
 
-   | Then, after libvirt has released all resources, the hook is called again,
-     :since:`since 0.9.0` , to allow any additional resource cleanup:
+   Then, after libvirt has released all resources, the hook is called again,
+   :since:`since 0.9.0` , to allow any additional resource cleanup:
 
    ::
 
@@ -325,41 +325,41 @@ operation. There is no specific operation to indicate a "restart" is occurring.
 /etc/libvirt/hooks/libxl
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
--  | Before a Xen guest is started using libxl driver, the libxl hook script is
-     called in three locations; if any location fails, the guest is not started.
-     The first location, :since:`since 2.1.0` , is before libvirt performs any
-     resource labeling, and the hook can allocate resources not managed by
-     libvirt. This is called as:
+-  Before a Xen guest is started using libxl driver, the libxl hook script is
+   called in three locations; if any location fails, the guest is not started.
+   The first location, :since:`since 2.1.0` , is before libvirt performs any
+   resource labeling, and the hook can allocate resources not managed by
+   libvirt. This is called as:
 
    ::
 
       /etc/libvirt/hooks/libxl guest_name prepare begin -
 
-   | The second location, available :since:`Since 2.1.0` , occurs after libvirt
-     has finished labeling all resources, but has not yet started the guest,
-     called as:
+   The second location, available :since:`Since 2.1.0` , occurs after libvirt
+   has finished labeling all resources, but has not yet started the guest,
+   called as:
 
    ::
 
       /etc/libvirt/hooks/libxl guest_name start begin -
 
-   | The third location, :since:`2.1.0` , occurs after the domain has
-     successfully started up:
+   The third location, :since:`2.1.0` , occurs after the domain has
+   successfully started up:
 
    ::
 
       /etc/libvirt/hooks/libxl guest_name started begin -
 
--  | When a libxl-handled Xen guest is stopped, the libxl hook script is called
-     in two locations, to match the startup. First, :since:`since 2.1.0` , the
-     hook is called before libvirt restores any labels:
+-  When a libxl-handled Xen guest is stopped, the libxl hook script is called
+   in two locations, to match the startup. First, :since:`since 2.1.0` , the
+   hook is called before libvirt restores any labels:
 
    ::
 
       /etc/libvirt/hooks/libxl guest_name stopped end -
 
-   | Then, after libvirt has released all resources, the hook is called again,
-     :since:`since 2.1.0` , to allow any additional resource cleanup:
+   Then, after libvirt has released all resources, the hook is called again,
+   :since:`since 2.1.0` , to allow any additional resource cleanup:
 
    ::
 
@@ -399,41 +399,41 @@ operation. There is no specific operation to indicate a "restart" is occurring.
 /etc/libvirt/hooks/bhyve
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
--  | Before an bhyve guest is started, the bhyve hook script is called in three
-     locations; if any location fails, the guest is not started. The first
-     location, :since:`since 6.1.0` , is before libvirt performs any resource
-     labeling, and the hook can allocate resources not managed by libvirt. This is
-     called as:
+-  Before an bhyve guest is started, the bhyve hook script is called in three
+   locations; if any location fails, the guest is not started. The first
+   location, :since:`since 6.1.0` , is before libvirt performs any resource
+   labeling, and the hook can allocate resources not managed by libvirt. This is
+   called as:
 
    ::
 
       /etc/libvirt/hooks/bhyve guest_name prepare begin -
 
-   | The second location, available :since:`Since 6.1.0` , occurs after libvirt
-     has finished labeling all resources, but has not yet started the guest,
-     called as:
+   The second location, available :since:`Since 6.1.0` , occurs after libvirt
+   has finished labeling all resources, but has not yet started the guest,
+   called as:
 
    ::
 
       /etc/libvirt/hooks/bhyve guest_name start begin -
 
-   | The third location, :since:`6.1.0` , occurs after the bhyve process has
-     successfully started up:
+   The third location, :since:`6.1.0` , occurs after the bhyve process has
+   successfully started up:
 
    ::
 
       /etc/libvirt/hooks/bhyve guest_name started begin -
 
--  | When an bhyve guest is stopped, the bhyve hook script is called in two
-     locations, to match the startup. First, :since:`since 6.1.0` , the hook is
-     called before libvirt restores any labels:
+-  When an bhyve guest is stopped, the bhyve hook script is called in two
+   locations, to match the startup. First, :since:`since 6.1.0` , the hook is
+   called before libvirt restores any labels:
 
    ::
 
       /etc/libvirt/hooks/bhyve guest_name stopped end -
 
-   | Then, after libvirt has released all resources, the hook is called again,
-     :since:`since 6.1.0` , to allow any additional resource cleanup:
+   Then, after libvirt has released all resources, the hook is called again,
+   :since:`since 6.1.0` , to allow any additional resource cleanup:
 
    ::
 
@@ -442,27 +442,27 @@ operation. There is no specific operation to indicate a "restart" is occurring.
 /etc/libvirt/hooks/network
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
--  | :since:`Since 1.2.2` , before a network is started, this script is called
-     as:
+-  :since:`Since 1.2.2` , before a network is started, this script is called
+   as:
 
    ::
 
       /etc/libvirt/hooks/network network_name start begin -
 
--  | After the network is started, up & running, the script is called as:
+-  After the network is started, up & running, the script is called as:
 
    ::
 
       /etc/libvirt/hooks/network network_name started begin -
 
--  | When a network is shut down, this script is called as:
+-  When a network is shut down, this script is called as:
 
    ::
 
       /etc/libvirt/hooks/network network_name stopped end -
 
--  | Later, when network is started and there's an interface from a domain to be
-     plugged into the network, the hook script is called as:
+-  Later, when network is started and there's an interface from a domain to be
+   plugged into the network, the hook script is called as:
 
    ::
 
@@ -471,14 +471,14 @@ operation. There is no specific operation to indicate a "restart" is occurring.
    Please note, that in this case, the script is passed both network and port
    XMLs on its stdin.
 
--  | When network is updated, the hook script is called as:
+-  When network is updated, the hook script is called as:
 
    ::
 
       /etc/libvirt/hooks/network network_name updated begin -
 
--  | When the domain from previous case is shutting down, the interface is
-     unplugged. This leads to another script invocation:
+-  When the domain from previous case is shutting down, the interface is
+   unplugged. This leads to another script invocation:
 
    ::