From nobody Mon Feb 9 13:21:17 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) client-ip=207.211.31.81; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1579490763; cv=none; d=zohomail.com; s=zohoarc; b=eDeeqDtJaKxHki8D3jxsmmcjQK58frwVXf9QKLg5waR1sDZ+IxogFnUMIPP5OigJUN+DDj+yX3LZp389JzC0xV10+UzoQ2zZ2jSaeEgMKFbIgRwwoIyo5KWqFHlflOxmwJkF5TE5kaQWpYJGZiNO1ov+U2WFdGzBw5lpKivUPes= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1579490763; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=/esAeU5xpvSYVVOi4OiOTkd31d16XTZMZugA4fn33pw=; b=kop5hUSsYIl0L1k5YONEYpXGYu4FbUUFa28lzXMa1h+x09nQw9tFlpsEHGagxGh1gctmaztDB4LrUK+4QBv7m+MH71eYKZueXuhkTLnwNZY/wuhUmLJi9gT9eEItq9WRpigv8xtCj+XClHr2U6QCroSr6f6H+yHuz6CyzeCqOV4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by mx.zohomail.com with SMTPS id 1579490763145790.7860493874801; Sun, 19 Jan 2020 19:26:03 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-329-GHA764kRM2uad96Gqp6FKA-1; Sun, 19 Jan 2020 22:25:06 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D838B1084432; Mon, 20 Jan 2020 03:24:58 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B46DE84D99; Mon, 20 Jan 2020 03:24:58 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 731B08197B; Mon, 20 Jan 2020 03:24:58 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 00K3OaVP002471 for ; Sun, 19 Jan 2020 22:24:36 -0500 Received: by smtp.corp.redhat.com (Postfix) id A79695C299; Mon, 20 Jan 2020 03:24:36 +0000 (UTC) Received: from tilapia.redhat.com (ovpn-121-72.rdu2.redhat.com [10.10.121.72]) by smtp.corp.redhat.com (Postfix) with ESMTP id 090EA5C1BB; Mon, 20 Jan 2020 03:24:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579490762; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=/esAeU5xpvSYVVOi4OiOTkd31d16XTZMZugA4fn33pw=; b=MfjLgYL7Jeuwy7xi09YHb1p4gAijwrzxjandnMVraMwe+jHtv2pNDnHgTHXEQPR7/U8n8i 3W/0GBSagFV9RmhuLsoNKLhX53rs57r7d5xH4F4Cw8+VcB+pABHmCICXOZei9kUJf2lS4z W+wBXnCUwF/iLbIkfB55ulIySEFZKMo= From: Laine Stump To: libvir-list@redhat.com Subject: [libvirt PATCH 11/12] docs: document virtio failover / QEMU auto-plug of hostdev during migration Date: Sun, 19 Jan 2020 22:24:18 -0500 Message-Id: <20200120032419.448310-12-laine@redhat.com> In-Reply-To: <20200120032419.448310-1-laine@redhat.com> References: <20200120032419.448310-1-laine@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-loop: libvir-list@redhat.com Cc: Jens Freimann X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-MC-Unique: GHA764kRM2uad96Gqp6FKA-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" The information in formatdomain.html seems too detailed, but it also didn't seem right to put that information in a wiki page before the patches are even pushed... Signed-off-by: Laine Stump --- docs/formatdomain.html.in | 70 +++++++++++++++++++++++++++++++++++++++ docs/news.xml | 27 +++++++++++++++ 2 files changed, 97 insertions(+) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 6e86d057a8..e3ea89fe25 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -5871,6 +5871,76 @@ </devices> ... =20 +
Using virtio "failover" to bond a= n emulated/hostdev NIC pair
+ +

+ Since 6.1.0 (QEMU and KVM only, requires + QEMU 4.2.0 or newer) If the virtio-net driver in the + guest OS supports the virtio "failover" feature, it is possible + to setup a simple bond device comprised of one emulated virtio + NIC and one SRIOV VF "hostdev" NIC. In this configuration, the + higher-performing hostdev NIC will normally be preferred for all + network traffic, but when the VM is migrated, QEMU will + automatically unplug the VF from the VM, and then hotplug a + similar device once migration is completed; while migration is + taking place, network traffic will use the virtio NIC. (Of + course the emulated virtio NIC and the hostdev NIC must be + connected to the same subnet for bonding to work properly). The + interface <driver> subelement + attributes failover and backupAlias + are used to set this up - the virtio NIC will need to + have failover=3D'on' set in + its <driver>, and the hostdev NIC will + use backupAlias to indicate the alias name of the + virtio NIC. +

+

+ NB1: Since you must know the alias name of the virtio + NIC when configuring the hostdev NIC, it will need to be + manually set in the virtio NIC's configuration (as with all + other manually set alias names, it must start with "ua-". +

+

+ NB2: Currently the only known implementation of failover in a + guest OS virtio-net driver requires that the MAC addresses of + the virtio and hostdev NIC must match. Since that may not always + be a requirement, libvirt doesn't enforce this limitation - it + is up to the person/management application that is creating the + configuration. +

+

+ NB3: Since the PCI addresses of the SRIOV VFs on the hosts that + are the source and destination of the migration will almost + certainly be different, either higher level management software + will need to modify the <source> of the + hostdev NIC (<interface type=3D'hostdev'>) at + the start of migration, or (a simpler solution) the + configuration will need to use a libvirt "hostdev" virtual + network that maintains a pool of such devices, as is implied in + the following example's use of the libvirt network named + "hostdev-pool" - as long as the hostdev network pools on both + hosts have the same name, libvirt itself will take care of + allocating an appropriate device on both ends of the migration. +

+ +
+...
+<devices>
+  <interface type=3D'network'>
+    <source network=3D'mybridge'/>
+    <mac address=3D'00:11:22:33:44:55'/>
+    <model type=3D'virtio'/>
+    <driver failover=3D'on'/>
+    <alias name=3D'ua-backup0'/>
+  </interface>
+  <interface type=3D'network'>
+    <source network=3D'hostdev-pool'/>
+    <mac address=3D'00:11:22:33:44:55'/>
+    <model type=3D'virtio'/>
+    <driver backupAlias=3D'ua-backup0'/>
+  </interface>
+</devices>
+...
=20
Multicast tunnel
=20 diff --git a/docs/news.xml b/docs/news.xml index 056c7ef026..051b6b3a54 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -44,6 +44,33 @@
+ + + support for virtio "failover" / QEMU auto-unplug of vfio devices + + + QEMU 4.2.0 and later, combined with a sufficiently recent + guest virtio-net driver, supports setting up a simple + network bond device comprised of one virtio emulated NIC and + one hostdev NIC (which must be an SRIOV VF). The allure of + this setup is that the bond will always favor the hostdev + device, providing better performance, until the guest is + migrated - at that time QEMU will automatically unplug the + hostdev NIC and the bond will send all traffic via the + virtio NIC until migration is completed, then QEMU on the + destination side will hotplug a new hostdev NIC and the bond + will switch back to using the hostdev for network + traffic. The result is that guests desiring the extra + performance of a hostdev NIC are now migratable without + network downtime (performance is just degraded during + migration) and without requiring a complicated bonding + configuration in the guest OS network config and complicated + unplug/replug logic in the management application on the + host - it can instead all be accomplished in libvirt with + the interface <driver> subelement "failover" and + "backupAlias" attributes. + +
--=20 2.24.1