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>
This commit is contained in:
Andrea Bolognani 2024-02-19 18:14:46 +01:00
parent 93e546baff
commit 4abadea48d
4 changed files with 102 additions and 98 deletions

View File

@ -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:
::

View File

@ -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.
::

View File

@ -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,

View File

@ -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:
::