On Fri, 24 Jan 2020, 17:54 Laine Stump, <laine@xxxxxxxxxx> wrote:
V1: https://www.redhat.com/archives/libvir-list/2020-January/msg00813.html
This all used different names in V1 - in that incarnation the
configuration was done using "failover" and "backupAlias" attributes
added to the <driver> subelement of <interface>. But the resulting
code was cumbersome and had little bits scattered all over the place
due to needing it in both hostdev and interface parsing/formatting.
In his review of V1, danpb suggesting just adding a new subelement for
this configuration to free ourselves from the constraints of <driver>
parsing/formatting. This ended up dramatically simplifying the code
(hence the lack of V1's refactoring patches in V2, and a decrease in
patch count from 12 to 6).
During further discussion in email and on IRC, we decided that naming
the element <failover> was too limiting, as it implied the behavior of
what is, to libvirt, just two network devices that should be
teamed/bonded together - it's completely up to the hypervisor and
guest what is done with this information. In light of that, we decided
to name the new subelement <teaming>, and to specify the two
interfaces as "persistent" (an interface that will always remain
plugged in) and "transient" (an interface that may be periodically
unplugged (during migration, in the case of QEMU). So the virtio
device will have
<teaming type='persistent'/>
and the hostdev device will have
<teaming type='transient' persistent='ua-myvirtio'/>
(note that the persistent interface must have <alias name='ua-myvirtio'/>)
Given this config, libvirt will add "failover=on" to the device
commandline arg for the virtio device, and
"failover_pair_id=ua-myvirtio" to the arg for the hostdev device (and
when a migration is requested, it will notice if there is a hostdev
that has <teaming type='transient'/> set, and will allow the migration
in this case, but still disallow migrations of domains with normal
hostdevs).
In response to these extra commandline options, QEMU will set some
extra capabilities in the virtio device PCI capabilities data, and
will also automatically unplug/re-plug the hostdev device before and
after migration.
In the guest, the virtio-net driver will notice the extra PCI
capabilities and use this as a clue that it should search for another
device with matching MAC address (NB: the guest driver requires the
two devices to have matching MAC addresses) to join into a bond with
the virtio-net device.
I like the <teaming/> abstraction.
As I wrote earlier, as a virt-manager user I'd like to specify that two interfaces are teamed; I would not care to copy the mac address of one onto the other. I prefer that libvirt hides this virtio awkwardness by passing the "persistent" mac address to both qemu nics. Would libvirt do this service to its multiple clients?
This bond is hard-wired to always prefer the
hostdev device whenever it is present, and use the virtio device as
backup when the hostdev is unplugged.
----
As mentioned in a followup to the V1 cover letter, there is a
regression in QEMU 4.2.0 that causes QEMU to segv when a hostdev is
unplugged. That bug is fixed with this upstream QEMU patch:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0446f8121723b134ca1d1ed0b73e96d4a0a8689d;hp=48008198270e3ebcc9394401d676c54ed5ac139c
Be sure to use a qemu build with this patch applied, or you may not
even be able to start the guest! Also we've found that the
DEVICE_DELETED event is never sent to libvirt when one of these
hostdevs is manually unplugged, meaning that libvirt keeps the device marked as
"in-use", and it therefore cannot be re-plugged to the guest until
after a complete guest "power cycle". AFAIK there isn't yet a fix for
that bug, so don't expect manual unplug of the device to work.
Laine Stump (6):
qemu: add capabilities flag for failover feature
conf: parse/format <teaming> subelement of <interface>
qemu: support interface <teaming> functionality
qemu: allow migration with assigned PCI hostdev if <teaming> is set
qemu: add wait-unplug to qemu migration status enum
docs: document <interface> subelement <teaming>
docs/formatdomain.html.in | 100 ++++++++++++++++++
docs/news.xml | 28 +++++
docs/schemas/domaincommon.rng | 19 ++++
src/conf/domain_conf.c | 45 ++++++++
src/conf/domain_conf.h | 14 +++
src/qemu/qemu_capabilities.c | 4 +
src/qemu/qemu_capabilities.h | 3 +
src/qemu/qemu_command.c | 9 ++
src/qemu/qemu_domain.c | 36 ++++++-
src/qemu/qemu_migration.c | 53 +++++++++-
src/qemu/qemu_monitor.c | 1 +
src/qemu/qemu_monitor.h | 1 +
src/qemu/qemu_monitor_json.c | 1 +
.../caps_4.2.0.aarch64.xml | 1 +
.../caps_4.2.0.x86_64.xml | 1 +
.../net-virtio-teaming-network.xml | 37 +++++++
.../qemuxml2argvdata/net-virtio-teaming.args | 40 +++++++
tests/qemuxml2argvdata/net-virtio-teaming.xml | 50 +++++++++
tests/qemuxml2argvtest.c | 4 +
.../net-virtio-teaming-network.xml | 51 +++++++++
.../qemuxml2xmloutdata/net-virtio-teaming.xml | 66 ++++++++++++
tests/qemuxml2xmltest.c | 6 ++
22 files changed, 563 insertions(+), 7 deletions(-)
create mode 100644 tests/qemuxml2argvdata/net-virtio-teaming-network.xml
create mode 100644 tests/qemuxml2argvdata/net-virtio-teaming.args
create mode 100644 tests/qemuxml2argvdata/net-virtio-teaming.xml
create mode 100644 tests/qemuxml2xmloutdata/net-virtio-teaming-network.xml
create mode 100644 tests/qemuxml2xmloutdata/net-virtio-teaming.xml
--
2.24.1
