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 for example by installing libvirt debuginfo package on Fedora or Red Hat
Enterprise Linux (with debuginfo-install libvirt) prior to running gdb. Enterprise Linux (with debuginfo-install libvirt) prior to running gdb.
| It may also happen that the libvirt daemon itself crashes or gets stuck, 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 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 to the crash, similarly to a normal program provide the "bt" backtrace
information to where gdb will have stopped. information to where gdb will have stopped.
| But if libvirtd gets stuck, for example seems to stop processing commands, try 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 attach to the faulty daemon and issue a gdb command "thread apply all bt"
to show all the threads backtraces, as in: 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 The next rules depend on the type of connectivity allowed, and go in the main
FORWARD chain: FORWARD chain:
- | type=isolated - type=isolated
| Allow traffic between guests. Deny inbound. Deny outbound.
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
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 - type=nat
| Allow inbound related to an established connection. Allow outbound, but
only from our expected subnet. Allow traffic between guests. Deny all other Allow inbound related to an established connection. Allow outbound, but
inbound. Deny all other outbound. 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
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 - 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 Allow inbound, but only to our expected subnet. Allow outbound, but only
inbound. Deny all other outbound. 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 Direct attachment to physical interface
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| Provides direct attachment of the virtual machine's NIC to the given physical 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)` 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 This setup requires the Linux macvtap driver to be available. :since:`(Since
Aggregator' <https://www.ieee802.org/1/files/public/docs2009/new-evb-congdon-vepa-modular-0709-v01.pdf>`__), Linux 2.6.34.)` One of the modes 'vepa' ( `'Virtual Ethernet Port
'bridge' or 'private' can be chosen for the operation mode of the macvtap Aggregator' <https://www.ieee802.org/1/files/public/docs2009/new-evb-congdon-vepa-modular-0709-v01.pdf>`__),
device, 'vepa' being the default mode. The individual modes cause the delivery 'bridge' or 'private' can be chosen for the operation mode of the macvtap
of packets to behave as follows: 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`` If the model type is set to ``virtio`` and interface's ``trustGuestRxFilters``
attribute is set to ``yes``, changes made to the interface mac address, 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 /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 /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 /etc/libvirt/hooks/daemon - shutdown - shutdown
- | When the libvirt daemon receives the SIGHUP signal, it reloads its - When the libvirt daemon receives the SIGHUP signal, it reloads its
configuration and triggers the hook script as: 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 /etc/libvirt/hooks/qemu
^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^
- | Before a QEMU guest is started, the qemu hook script is called in three - 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 locations; if any location fails, the guest is not started. The first
location, :since:`since 0.9.0` , is before libvirt performs any resource location, :since:`since 0.9.0` , is before libvirt performs any resource
labeling, and the hook can allocate resources not managed by libvirt such labeling, and the hook can allocate resources not managed by libvirt such
as DRBD or missing bridges. This is called as: as DRBD or missing bridges. This is called as:
:: ::
/etc/libvirt/hooks/qemu guest_name prepare begin - /etc/libvirt/hooks/qemu guest_name prepare begin -
| The second location, available :since:`Since 0.8.0` , occurs after libvirt The second location, available :since:`Since 0.8.0` , occurs after libvirt
has finished labeling all resources, but has not yet started the guest, has finished labeling all resources, but has not yet started the guest,
called as: called as:
:: ::
/etc/libvirt/hooks/qemu guest_name start begin - /etc/libvirt/hooks/qemu guest_name start begin -
| The third location, :since:`0.9.13` , occurs after the QEMU process has The third location, :since:`0.9.13` , occurs after the QEMU process has
successfully started up: successfully started up:
:: ::
/etc/libvirt/hooks/qemu guest_name started begin - /etc/libvirt/hooks/qemu guest_name started begin -
- | When a QEMU guest is stopped, the qemu hook script is called in two - 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 locations, to match the startup. First, :since:`since 0.8.0` , the hook is
called before libvirt restores any labels: called before libvirt restores any labels:
:: ::
/etc/libvirt/hooks/qemu guest_name stopped end - /etc/libvirt/hooks/qemu guest_name stopped end -
| Then, after libvirt has released all resources, the hook is called again, Then, after libvirt has released all resources, the hook is called again,
:since:`since 0.9.0` , to allow any additional resource cleanup: :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 /etc/libvirt/hooks/lxc
^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^
- | Before a LXC guest is started, the lxc hook script is called in three - 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 locations; if any location fails, the guest is not started. The first
location, :since:`since 0.9.13` , is before libvirt performs any resource location, :since:`since 0.9.13` , is before libvirt performs any resource
labeling, and the hook can allocate resources not managed by libvirt such labeling, and the hook can allocate resources not managed by libvirt such
as DRBD or missing bridges. This is called as: as DRBD or missing bridges. This is called as:
:: ::
/etc/libvirt/hooks/lxc guest_name prepare begin - /etc/libvirt/hooks/lxc guest_name prepare begin -
| The second location, available :since:`Since 0.8.0` , occurs after libvirt The second location, available :since:`Since 0.8.0` , occurs after libvirt
has finished labeling all resources, but has not yet started the guest, has finished labeling all resources, but has not yet started the guest,
called as: called as:
:: ::
/etc/libvirt/hooks/lxc guest_name start begin - /etc/libvirt/hooks/lxc guest_name start begin -
| The third location, :since:`0.9.13` , occurs after the LXC process has The third location, :since:`0.9.13` , occurs after the LXC process has
successfully started up: successfully started up:
:: ::
/etc/libvirt/hooks/lxc guest_name started begin - /etc/libvirt/hooks/lxc guest_name started begin -
- | When a LXC guest is stopped, the lxc hook script is called in two - 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 locations, to match the startup. First, :since:`since 0.8.0` , the hook is
called before libvirt restores any labels: called before libvirt restores any labels:
:: ::
/etc/libvirt/hooks/lxc guest_name stopped end - /etc/libvirt/hooks/lxc guest_name stopped end -
| Then, after libvirt has released all resources, the hook is called again, Then, after libvirt has released all resources, the hook is called again,
:since:`since 0.9.0` , to allow any additional resource cleanup: :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 /etc/libvirt/hooks/libxl
^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^
- | Before a Xen guest is started using libxl driver, the libxl hook script is - 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. 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 The first location, :since:`since 2.1.0` , is before libvirt performs any
resource labeling, and the hook can allocate resources not managed by resource labeling, and the hook can allocate resources not managed by
libvirt. This is called as: libvirt. This is called as:
:: ::
/etc/libvirt/hooks/libxl guest_name prepare begin - /etc/libvirt/hooks/libxl guest_name prepare begin -
| The second location, available :since:`Since 2.1.0` , occurs after libvirt The second location, available :since:`Since 2.1.0` , occurs after libvirt
has finished labeling all resources, but has not yet started the guest, has finished labeling all resources, but has not yet started the guest,
called as: called as:
:: ::
/etc/libvirt/hooks/libxl guest_name start begin - /etc/libvirt/hooks/libxl guest_name start begin -
| The third location, :since:`2.1.0` , occurs after the domain has The third location, :since:`2.1.0` , occurs after the domain has
successfully started up: successfully started up:
:: ::
/etc/libvirt/hooks/libxl guest_name started begin - /etc/libvirt/hooks/libxl guest_name started begin -
- | When a libxl-handled Xen guest is stopped, the libxl hook script is called - 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 in two locations, to match the startup. First, :since:`since 2.1.0` , the
hook is called before libvirt restores any labels: hook is called before libvirt restores any labels:
:: ::
/etc/libvirt/hooks/libxl guest_name stopped end - /etc/libvirt/hooks/libxl guest_name stopped end -
| Then, after libvirt has released all resources, the hook is called again, Then, after libvirt has released all resources, the hook is called again,
:since:`since 2.1.0` , to allow any additional resource cleanup: :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 /etc/libvirt/hooks/bhyve
^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^
- | Before an bhyve guest is started, the bhyve hook script is called in three - 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 locations; if any location fails, the guest is not started. The first
location, :since:`since 6.1.0` , is before libvirt performs any resource 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 labeling, and the hook can allocate resources not managed by libvirt. This is
called as: called as:
:: ::
/etc/libvirt/hooks/bhyve guest_name prepare begin - /etc/libvirt/hooks/bhyve guest_name prepare begin -
| The second location, available :since:`Since 6.1.0` , occurs after libvirt The second location, available :since:`Since 6.1.0` , occurs after libvirt
has finished labeling all resources, but has not yet started the guest, has finished labeling all resources, but has not yet started the guest,
called as: called as:
:: ::
/etc/libvirt/hooks/bhyve guest_name start begin - /etc/libvirt/hooks/bhyve guest_name start begin -
| The third location, :since:`6.1.0` , occurs after the bhyve process has The third location, :since:`6.1.0` , occurs after the bhyve process has
successfully started up: successfully started up:
:: ::
/etc/libvirt/hooks/bhyve guest_name started begin - /etc/libvirt/hooks/bhyve guest_name started begin -
- | When an bhyve guest is stopped, the bhyve hook script is called in two - 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 locations, to match the startup. First, :since:`since 6.1.0` , the hook is
called before libvirt restores any labels: called before libvirt restores any labels:
:: ::
/etc/libvirt/hooks/bhyve guest_name stopped end - /etc/libvirt/hooks/bhyve guest_name stopped end -
| Then, after libvirt has released all resources, the hook is called again, Then, after libvirt has released all resources, the hook is called again,
:since:`since 6.1.0` , to allow any additional resource cleanup: :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 /etc/libvirt/hooks/network
^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^
- | :since:`Since 1.2.2` , before a network is started, this script is called - :since:`Since 1.2.2` , before a network is started, this script is called
as: as:
:: ::
/etc/libvirt/hooks/network network_name start begin - /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 - /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 - /etc/libvirt/hooks/network network_name stopped end -
- | Later, when network is started and there's an interface from a domain to be - 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: 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 Please note, that in this case, the script is passed both network and port
XMLs on its stdin. 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 - /etc/libvirt/hooks/network network_name updated begin -
- | When the domain from previous case is shutting down, the interface is - When the domain from previous case is shutting down, the interface is
unplugged. This leads to another script invocation: unplugged. This leads to another script invocation:
:: ::