From: "Alex Bennée" <alex.bennee@linaro.org>
To: qemu-devel@nongnu.org
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
"Manos Pitsidianakis" <manos.pitsidianakis@linaro.org>,
"Jason Wang" <jasowang@redhat.com>
Subject: [PULL 7/8] docs/system: clean-up formatting of virtio-net-failover
Date: Mon, 14 Jul 2025 13:02:33 +0100 [thread overview]
Message-ID: <20250714120234.1524401-8-alex.bennee@linaro.org> (raw)
In-Reply-To: <20250714120234.1524401-1-alex.bennee@linaro.org>
We didn't clean-up the rst formatting when we moved this into the
docs so lets do that now:
- un-indent the usage/hotplug/migration paragraphs
- properly wrap the command line fragments in code-block
- highlight parameters in text with ``double quotes``
No changes to the actual text.
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-ID: <20250710104531.3099313-8-alex.bennee@linaro.org>
diff --git a/docs/system/virtio-net-failover.rst b/docs/system/virtio-net-failover.rst
index 6002dc5d96..0cc465454c 100644
--- a/docs/system/virtio-net-failover.rst
+++ b/docs/system/virtio-net-failover.rst
@@ -26,43 +26,48 @@ and standby devices are not plugged into the same PCIe slot.
Usecase
-------
- Virtio-net standby allows easy migration while using a passed-through fast
- networking device by falling back to a virtio-net device for the duration of
- the migration. It is like a simple version of a bond, the difference is that it
- requires no configuration in the guest. When a guest is live-migrated to
- another host QEMU will unplug the primary device via the PCIe based hotplug
- handler and traffic will go through the virtio-net device. On the target
- system the primary device will be automatically plugged back and the
- net_failover module registers it again as the primary device.
+Virtio-net standby allows easy migration while using a passed-through
+fast networking device by falling back to a virtio-net device for the
+duration of the migration. It is like a simple version of a bond, the
+difference is that it requires no configuration in the guest. When a
+guest is live-migrated to another host QEMU will unplug the primary
+device via the PCIe based hotplug handler and traffic will go through
+the virtio-net device. On the target system the primary device will be
+automatically plugged back and the net_failover module registers it
+again as the primary device.
Usage
-----
- The primary device can be hotplugged or be part of the startup configuration
+The primary device can be hotplugged or be part of the startup configuration
- -device virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:6f:55:cc, \
- bus=root2,failover=on
+.. code-block:: shell
- With the parameter failover=on the VIRTIO_NET_F_STANDBY feature will be enabled.
+ -device virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:6f:55:cc,bus=root2,failover=on
+
+With the parameter ``failover=on`` the VIRTIO_NET_F_STANDBY feature will be enabled.
+
+.. code-block:: shell
-device vfio-pci,host=5e:00.2,id=hostdev0,bus=root1,failover_pair_id=net1
- failover_pair_id references the id of the virtio-net standby device. This
- is only for pairing the devices within QEMU. The guest kernel module
- net_failover will match devices with identical MAC addresses.
+``failover_pair_id`` references the id of the virtio-net standby device.
+This is only for pairing the devices within QEMU. The guest kernel
+module net_failover will match devices with identical MAC addresses.
Hotplug
-------
- Both primary and standby device can be hotplugged via the QEMU monitor. Note
- that if the virtio-net device is plugged first a warning will be issued that it
- couldn't find the primary device.
+Both primary and standby device can be hotplugged via the QEMU
+monitor. Note that if the virtio-net device is plugged first a warning
+will be issued that it couldn't find the primary device.
Migration
---------
- A new migration state wait-unplug was added for this feature. If failover primary
- devices are present in the configuration, migration will go into this state.
- It will wait until the device unplug is completed in the guest and then move into
- active state. On the target system the primary devices will be automatically hotplugged
- when the feature bit was negotiated for the virtio-net standby device.
+A new migration state wait-unplug was added for this feature. If
+failover primary devices are present in the configuration, migration
+will go into this state. It will wait until the device unplug is
+completed in the guest and then move into active state. On the target
+system the primary devices will be automatically hotplugged when the
+feature bit was negotiated for the virtio-net standby device.
--
2.47.2
next prev parent reply other threads:[~2025-07-14 13:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-14 12:02 [PULL 0/8] maintainer updates for rc0 (gitlab, gdbstub, plugins, docs) Alex Bennée
2025-07-14 12:02 ` [PULL 1/8] gitlab: use argparse in check-units script Alex Bennée
2025-07-14 12:02 ` [PULL 2/8] gitlab: add -n option to " Alex Bennée
2025-07-14 12:02 ` [PULL 3/8] contrib/plugins/execlog: Add tab to the separator search of insn_disas Alex Bennée
2025-07-14 12:02 ` [PULL 4/8] target/alpha: Add GDB XML feature file Alex Bennée
2025-07-14 12:02 ` [PULL 5/8] plugins: fix inclusion of user-mode APIs Alex Bennée
2025-07-14 12:02 ` [PULL 6/8] docs: use :kbd: role in sphinx docs Alex Bennée
2025-07-14 12:02 ` Alex Bennée [this message]
2025-07-14 12:02 ` [PULL 8/8] gdbstub: add the GDB register XML files for sparc64 Alex Bennée
2025-07-15 19:50 ` [PULL 0/8] maintainer updates for rc0 (gitlab, gdbstub, plugins, docs) Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250714120234.1524401-8-alex.bennee@linaro.org \
--to=alex.bennee@linaro.org \
--cc=jasowang@redhat.com \
--cc=manos.pitsidianakis@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).