It slipped in during the conversion to reStructuredText. In one case, part of the preformatted text shouldn't have been marked as such, so that's addressed too. A spurious opening parenthesis is dropped as well. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com&gt; --- docs/drvnodedev.rst | 2 +- docs/formatdomain.rst | 16 ++++++++-------- docs/formatnetwork.rst | 2 +- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/drvnodedev.rst b/docs/drvnodedev.rst index 115d52ca02..2f050bb9d3 100644 --- a/docs/drvnodedev.rst +++ b/docs/drvnodedev.rst @@ -335,7 +335,7 @@ To start an instance of this device definition, use the following command: $ virsh nodedev-start <device-name> Active mediated device instances can be stopped using -``virsh nodedev-destroy``, and persistent device definitions can be +``virsh nodedev-destroy``, and persistent device definitions can be removed using ``virsh nodedev-undefine``. If a mediated device is defined persistently, it can also be set to be diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 3e7dfb7f26..fa42883809 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -2238,7 +2238,7 @@ are: Possible values for the ``value`` attribute are ``broken`` (no protection), ``workaround`` (count cache flush), ``fixed-ibs`` (fixed by serializing indirect branches), ``fixed-ccd`` (fixed by disabling the cache count) and - ``fixed-na (fixed in hardware - no longer applicable)``. If the + ``fixed-na`` (fixed in hardware - no longer applicable). If the attribute is not defined, the hypervisor default will be used. :since:`Since 6.3.0` (QEMU/KVM only) ``tcg`` @@ -4725,7 +4725,7 @@ behaves like a physical USB CCID (Chip/Smart Card Interface Device) card. Rather than requiring a smartcard to be plugged into the host, it is possible to provide three NSS certificate names residing in a database on the host. These certificates can be generated via the command - ``certutil -d /etc/pki/nssdb -x -t CT,CT,CT -S -s CN=cert1 -n cert1``, + ``certutil -d /etc/pki/nssdb -x -t CT,CT,CT -S -s CN=cert1 -n cert1``, and the resulting three certificate names must be supplied as the content of each of three ``<certificate>`` sub-elements. An additional sub-element ``<database>`` can specify the absolute path to an alternate directory @@ -4810,7 +4810,7 @@ network may be totally isolated (no ``<forward>`` element given), NAT'ing to an explicit network device or to the default route (``<forward mode='nat'>``), routed with no NAT (``<forward mode='route'/>``), or connected directly to one of the host's network interfaces (via macvtap) or bridge devices -((``<forward mode='bridge|private|vepa|passthrough'/>`` :since:`Since +(``<forward mode='bridge|private|vepa|passthrough'/>`` :since:`Since 0.9.4` ) For networks with a forward mode of bridge, private, vepa, and passthrough, it @@ -5363,11 +5363,11 @@ domain, or ``transient`` to indicate a device that may periodically be removed, then later re-added to the domain. When type="transient", there should be a second attribute to ``<teaming>`` called ``persistent`` - this attribute should be set to the alias name of the other device in the pair (the one that -has ``<teaming type="persistent'/>``). +has ``<teaming type="persistent'/>``). In the particular case of QEMU, libvirt's ``<teaming>`` element is used to setup a virtio-net "failover" device pair. For this setup, the persistent device must -be an interface with ``<model type="virtio"/>``, and the transient device +be an interface with ``<model type="virtio"/>``, and the transient device must be ``<interface type='hostdev'/>`` (or ``<interface type='network'/>`` where the referenced network defines a pool of SRIOV VFs). The guest will then have a simple network team/bond device made of the virtio NIC + hostdev NIC @@ -5927,7 +5927,7 @@ connection types, including standard linux bridges and libvirt's own virtual networks, **do not** support it. 802.1Qbh (vn-link) and 802.1Qbg (VEPA) switches provide their own way (outside of libvirt) to tag guest traffic onto a specific VLAN. Each tag is given in a separate ``<tag>`` subelement of ``<vlan>`` (for -example: ``<tag id='42'/>``). For VLAN trunking of multiple tags (which is +example: ``<tag id='42'/>``). For VLAN trunking of multiple tags (which is supported only on Open vSwitch connections), multiple ``<tag>`` subelements can be specified, which implies that the user wants to do VLAN trunking on the interface for all the specified tags. In the case that VLAN trunking of a single @@ -7921,9 +7921,9 @@ Example: manually added device with static PCI slot 2 requested ``period`` The optional ``period`` allows the QEMU virtio memory balloon driver to - provide statistics through the ``virsh dommemstat [domain]`` + provide statistics through the ``virsh dommemstat [domain]`` command. By default, collection is not enabled. In order to enable, use the - ``virsh dommemstat [domain] --period [number]`` command or + ``virsh dommemstat [domain] --period [number]`` command or ``virsh edit`` command to add the option to the XML definition. The ``virsh dommemstat`` will accept the options ``--live``, ``--current``, or ``--config``. If an option is not provided, the change for a running domain diff --git a/docs/formatnetwork.rst b/docs/formatnetwork.rst index dcdaf1e5a5..c875d35982 100644 --- a/docs/formatnetwork.rst +++ b/docs/formatnetwork.rst @@ -529,7 +529,7 @@ connection types, including standard linux bridges and libvirt's own virtual networks, **do not** support it. 802.1Qbh (vn-link) and 802.1Qbg (VEPA) switches provide their own way (outside of libvirt) to tag guest traffic onto a specific VLAN. Each tag is given in a separate ``<tag>`` subelement of ``<vlan>`` (for -example: ``<tag id='42'/>``). For VLAN trunking of multiple tags (which is +example: ``<tag id='42'/>``). For VLAN trunking of multiple tags (which is supported only on Open vSwitch connections), multiple ``<tag>`` subelements can be specified, which implies that the user wants to do VLAN trunking on the interface for all the specified tags. In the case that VLAN trunking of a single -- 2.43.2

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

Tweak things so that the required kernel version is still listed, just not as part of the :since: tag. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com&gt; --- docs/formatdomain.rst | 4 ++-- docs/formatnetwork.rst | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 10aa0bcebe..da6a920089 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -5119,8 +5119,8 @@ 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 +This setup requires the Linux macvtap driver (introduced in 2.6.34) +to be available. 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 diff --git a/docs/formatnetwork.rst b/docs/formatnetwork.rst index c875d35982..e65570038d 100644 --- a/docs/formatnetwork.rst +++ b/docs/formatnetwork.rst @@ -127,8 +127,7 @@ to the physical LAN (if at all). bridge (in particular, the port attaching the bridge to the physical network). However, it can also cause some networking setups to stop working (e.g. vlan tagging, multicast, guest-initiated changes to MAC address) and is - not supported by older kernels. :since:`Since 1.2.11, requires kernel 3.17 or - newer` + not supported by kernels older than 3.17. :since:`Since 1.2.11` The optional ``zone`` attribute of the ``bridge`` element is used to specify the `firewalld <https://firewalld.org>`__ zone for the bridge of a network @@ -1110,7 +1109,8 @@ will be no restrictions on inbound or outbound connections). Using a macvtap "direct" connection ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -:since:`Since 0.9.4, QEMU and KVM only, requires Linux kernel 2.6.34 or newer` +:since:`Since 0.9.4, QEMU and KVM only`. Requires Linux kernel 2.6.34 or newer. + This shows how to use macvtap to connect to the physical network directly through one of a group of physical devices (without using a host bridge device). As with the host bridge network, the guests will effectively be directly -- 2.43.2

Make sure that they're entirely contained within a single line and that punctuation is used in a way that doesn't make the resulting HTML look weird. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com&gt; --- docs/drvbhyve.rst | 30 +-- docs/drvesx.rst | 19 +- docs/drvqemu.rst | 2 +- docs/drvxen.rst | 2 +- docs/formatcaps.rst | 8 +- docs/formatdomain.rst | 370 ++++++++++++++++--------------- docs/formatnetwork.rst | 55 ++--- docs/formatnetworkport.rst | 2 +- docs/formatnode.rst | 6 +- docs/formatnwfilter.rst | 112 +++++----- docs/formatsecret.rst | 10 +- docs/formatsnapshot.rst | 4 +- docs/formatstorage.rst | 29 +-- docs/formatstorageencryption.rst | 8 +- docs/hooks.rst | 64 +++--- 15 files changed, 367 insertions(+), 354 deletions(-) diff --git a/docs/drvbhyve.rst b/docs/drvbhyve.rst index 214bc2e76e..f9cb99006e 100644 --- a/docs/drvbhyve.rst +++ b/docs/drvbhyve.rst @@ -268,7 +268,7 @@ these commands manually, most likely you might want to tweak them. Using ZFS volumes ~~~~~~~~~~~~~~~~~ -It's possible to use ZFS volumes as disk devices :since:`since 1.2.8` . An +It's possible to use ZFS volumes as disk devices :since:`since 1.2.8`. An example of domain XML device entry for that will look like: :: @@ -307,7 +307,7 @@ not have spaces or they will be tokenized incorrectly. Using UEFI bootrom, VNC, and USB tablet ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -:since:`Since 3.2.0` , in addition to +:since:`Since 3.2.0`, in addition to `Using grub2-bhyve or Alternative Bootloaders`_, non-FreeBSD guests could be also booted using an UEFI boot ROM, provided both guest OS and installed ``bhyve(1)`` version support UEFI. To use that, ``loader`` should be @@ -349,7 +349,7 @@ Please note that the tablet device requires to have a USB controller of the ``nec-xhci`` model. Currently, only a single controller of this type and a single tablet are supported per domain. -:since:`Since 3.5.0` , it's possible to configure how the video device is +:since:`Since 3.5.0`, it's possible to configure how the video device is exposed to the guest using the ``vgaconf`` attribute: :: @@ -375,7 +375,7 @@ refer to the manual page and the `bhyve wiki <https://wiki.freebsd.org/bhyve>`__ for more details on using the ``vgaconf`` option. -:since:`Since 3.7.0` , it's possible to use ``autoport`` to let libvirt allocate +:since:`Since 3.7.0`, it's possible to use ``autoport`` to let libvirt allocate VNC port automatically (instead of explicitly specifying it with the ``port`` attribute): @@ -383,7 +383,7 @@ attribute): <graphics type='vnc' autoport='yes'> -:since:`Since 6.8.0` , it's possible to set framebuffer resolution using the +:since:`Since 6.8.0`, it's possible to set framebuffer resolution using the ``resolution`` sub-element: :: @@ -394,7 +394,7 @@ attribute): </model> </video> -:since:`Since 6.8.0` , VNC server can be configured to use password based +:since:`Since 6.8.0`, VNC server can be configured to use password based authentication: :: @@ -414,7 +414,7 @@ Originally bhyve supported only localtime for RTC. Support for UTC time was introduced in `FreeBSD changeset r284894 <https://svnweb.freebsd.org/changeset/base/284894>`__ for *10-STABLE* and in `changeset r279225 <https://svnweb.freebsd.org/changeset/base/279225>`__ -for *-CURRENT*. It's possible to use this in libvirt :since:`since 1.2.18` , +for *-CURRENT*. It's possible to use this in libvirt :since:`since 1.2.18`, just place the following to domain XML: :: @@ -443,8 +443,8 @@ e1000 NIC As of `FreeBSD changeset r302504 <https://svnweb.freebsd.org/changeset/base/302504>`__ bhyve supports -Intel e1000 network adapter emulation. It's supported in libvirt :since:`since -3.1.0` and could be used as follows: +Intel e1000 network adapter emulation. It's supported in libvirt +:since:`since 3.1.0` and could be used as follows: :: @@ -460,7 +460,7 @@ Sound device As of `FreeBSD changeset r349355 <https://svnweb.freebsd.org/changeset/base/349355>`__ bhyve supports -sound device emulation. It's supported in libvirt :since:`since 6.7.0` . +sound device emulation. It's supported in libvirt :since:`since 6.7.0`. :: @@ -484,7 +484,7 @@ Virtio-9p filesystem As of `FreeBSD changeset r366413 <https://svnweb.freebsd.org/changeset/base/366413>`__ bhyve supports sharing arbitrary directory tree between the guest and the host. It's supported -in libvirt :since:`since 6.9.0` . +in libvirt :since:`since 6.9.0`. :: @@ -506,7 +506,7 @@ In the Linux guest, this could be mounted using: Wiring guest memory ~~~~~~~~~~~~~~~~~~~ -:since:`Since 4.4.0` , it's possible to specify that guest memory should be +:since:`Since 4.4.0`, it's possible to specify that guest memory should be wired and cannot be swapped out as follows: :: @@ -522,7 +522,7 @@ wired and cannot be swapped out as follows: CPU topology ~~~~~~~~~~~~ -:since:`Since 4.5.0` , it's possible to specify guest CPU topology, if bhyve +:since:`Since 4.5.0`, it's possible to specify guest CPU topology, if bhyve supports that. Support for specifying guest CPU topology was added to bhyve in `FreeBSD changeset r332298 <https://svnweb.freebsd.org/changeset/base/332298>`__ for *-CURRENT*. Example: @@ -540,7 +540,7 @@ for *-CURRENT*. Example: Ignoring unknown MSRs reads and writes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -:since:`Since 5.1.0` , it's possible to make bhyve ignore accesses to +:since:`Since 5.1.0`, it's possible to make bhyve ignore accesses to unimplemented Model Specific Registers (MSRs). Example: :: @@ -558,7 +558,7 @@ unimplemented Model Specific Registers (MSRs). Example: Pass-through of arbitrary bhyve commands ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -:since:`Since 5.1.0` , it's possible to pass additional command-line arguments +:since:`Since 5.1.0`, it's possible to pass additional command-line arguments to the bhyve process when starting the domain using the ``<bhyve:commandline>`` element under ``domain``. To supply an argument, use the element ``<bhyve:arg>`` with the attribute ``value`` set to additional argument to be added. The arg ... -- 2.43.2