mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-21 21:25:25 +00:00
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:
parent
93e546baff
commit
4abadea48d
@ -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:
|
||||
|
||||
::
|
||||
|
||||
|
@ -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.
|
||||
|
||||
::
|
||||
|
||||
|
@ -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,
|
||||
|
146
docs/hooks.rst
146
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:
|
||||
|
||||
::
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user