qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Paul B. Henson" <henson@acm.org>
To: qemu-devel@nongnu.org
Subject: sr-iov live migration with NET_FAILOVER
Date: Thu, 22 May 2025 15:27:45 -0700	[thread overview]
Message-ID: <b27e86f8-a93f-4b77-a2d6-3a47e23dfb12@acm.org> (raw)

I'm running libvirtd under Debian 12 and trying to set up live migration 
of a linux vm that's using an sr-iov VF as its primary ethernet device. 
I have that device and the corresponding virtio backup device properly 
configured in libvirt, and when the vm starts up everything looks good:

2: nic0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state 
UP mode DEFAULT group default qlen 1000
     link/ether 52:54:00:a1:e0:38 brd ff:ff:ff:ff:ff:ff
3: enp8s0nsby: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc 
fq_codel master nic0 state DOWN mode DEFAULT group default qlen 1000
     link/ether 52:54:00:a1:e0:38 brd ff:ff:ff:ff:ff:ff
5: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master 
nic0 state UP mode DEFAULT group default qlen 1000
     link/ether 52:54:00:a1:e0:38 brd ff:ff:ff:ff:ff:ff

The problem I am having is that when I do a live migration of the box, 
link on the standby virtio interface does not come up when the VF is 
unplugged, so all network traffic to the system is dropped during the 
interval between the source pulling the VF and the destination plugging 
it back in.

It's not clear to me who is responsible for doing that? But from what I 
can tell, it seems like it should be qmeu?

Per the documentation:

https://www.kernel.org/doc/html/latest/networking/net_failover.html

The sequence of events should be:

* bring up link on standby device
* detach sr-iov device
* migrate vm
* attach sr-iov device
* bring down link on standby device

If I do that manually, using virsh to light up the standby device and 
detach the VF before migration and then manually reattach the device and 
bring down standby link, no traffic is lost at all during the migration 
process.

I initially thought perhaps libvirt was supposed to be doing it, but 
reviewing the debug logs and the QMP commands, it is neither detaching 
nor reattaching the VF. It's just telling qmeu there's a failover pair, 
and qemu is doing the detach/attach while migrating:

-device 
{"driver":"virtio-net-pci","failover":true,"netdev":"hostua-sr-iov-backup","id":"ua-sr-iov-backup","mac":"52:54:00:a1:e0:38","bus":"pci.7","addr":"0x0"}

-device 
{"driver":"vfio-pci","host":"0000:37:10.0","id":"hostdev0","failover_pair_id":"ua-sr-iov-backup","bus":"pci.1","addr":"0x0"}


I tried manually bringing up link on the standby device before migrating 
the system and letting qemu deal with the vf detach/attach, but that 
resulted in even more lost traffic than simply letting the standby 
device be down during the migration (the network started sending packets 
to the standby device but the failover device didn't forward them on to 
the virtual nic as long as the VF existed).

Am I missing something? Is there some other configuration I'm supposed 
to do? Any insight on this issue would be most appreciated.

Debian 12 has qemu 7.2 as stable, but I also tried the backport of 9.2 
with the same apparent behavior.

Thanks much...



                 reply	other threads:[~2025-05-22 22:29 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=b27e86f8-a93f-4b77-a2d6-3a47e23dfb12@acm.org \
    --to=henson@acm.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).