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@xxxxxxxxxx>
---
docs/bugs.rst | 14 ++--
docs/firewall.rst | 23 ++++---
docs/formatdomain.rst | 17 ++---
docs/hooks.rst | 146 +++++++++++++++++++++---------------------
4 files changed, 102 insertions(+), 98 deletions(-)
diff --git a/docs/bugs.rst b/docs/bugs.rst
index b5d2e42b0c..5fd1970caf 100644
--- 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 eff9de5a89..26474d3317 100644
--- 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 fa42883809..f56f40d5cc 100644
--- 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 bd197c0d6e..4a0454a454 100644
--- 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:
::
--
2.43.2
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
