[PATCH 4/9] 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(a)redhat.com&gt; --- 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-modu...), - '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-modu...), +'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