Bug 1757796 - RFE: support for net failover devices in qemu
Summary: RFE: support for net failover devices in qemu
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux Advanced Virtualization
Classification: Red Hat
Component: qemu-kvm
Version: 8.1
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: 8.1
Assignee: Jens Freimann
QA Contact: Yanghang Liu
URL:
Whiteboard:
Depends On: 1718673
Blocks: 1615123 1688177 1693587 1760395 1848983
TreeView+ depends on / blocked
 
Reported: 2019-10-02 13:16 UTC by Jens Freimann
Modified: 2020-06-19 12:36 UTC (History)
17 users (show)

Fixed In Version: qemu-kvm-4.1.0-18.module+el8.1.1+5150+45ce6c40
Doc Type: Enhancement
Doc Text:
Clone Of: 1718673
Environment:
Last Closed: 2020-02-04 18:28:50 UTC
Type: Feature Request
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:0404 0 None None None 2020-02-04 18:29:46 UTC

Comment 3 Jens Freimann 2019-11-01 12:21:17 UTC
Patches are upstream in QEMU

Comment 11 Yanghang Liu 2020-01-03 05:55:40 UTC
Verification:

Versions:
Host:
4.18.0-147.3.1.el8_1.x86_64
qemu-kvm-4.1.0-20.module+el8.1.1+5309+6d656f05.x86_64
Guest:
4.18.0-147.3.1.el8_1.x86_64

Steps:
1.On source host,create 82599ES VF and set the mac address of the VF
ip link set enp6s0f0  vf 0  mac 22:2b:62:bb:a9:82

2.start a source guest with 82599ES VF which enables failover 
/usr/libexec/qemu-kvm -name rhel811 -M q35 -enable-kvm \
-monitor stdio \
-nodefaults \
-m 4G \
-boot menu=on \
-cpu Haswell-noTSX-IBRS \
-device pcie-root-port,id=root.1,chassis=1,addr=0x2.0,multifunction=on \
-device pcie-root-port,id=root.2,chassis=2,addr=0x2.1 \
-device pcie-root-port,id=root.3,chassis=3,addr=0x2.2 \
-device pcie-root-port,id=root.4,chassis=4,addr=0x2.3 \
-device pcie-root-port,id=root.5,chassis=5,addr=0x2.4 \
-device pcie-root-port,id=root.6,chassis=6,addr=0x2.5 \
-device pcie-root-port,id=root.7,chassis=7,addr=0x2.6 \
-device pcie-root-port,id=root.8,chassis=8,addr=0x2.7 \
-smp 2,sockets=1,cores=2,threads=2,maxcpus=4 \
-qmp tcp:0:6666,server,nowait \
-blockdev node-name=back_image,driver=file,cache.direct=on,cache.no-flush=off,filename=/nfsmount/migra_test/rhel811_q35.qcow2,aio=threads \
-blockdev node-name=drive-virtio-disk0,driver=qcow2,cache.direct=on,cache.no-flush=off,file=back_image \
-device virtio-blk-pci,drive=drive-virtio-disk0,id=disk0,bus=root.1 \
-device VGA,id=video1,bus=root.2  \
-vnc :0 \
-netdev tap,id=hostnet0,vhost=on \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=22:2b:62:bb:a9:82,bus=root.3,failover=on \
-device vfio-pci,host=0000:06:10.0,id=hostdev0,bus=root.4,failover_pair_id=net0 \




3.check the network info in source guest
# ifconfig 
enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.73.33.236  netmask 255.255.254.0  broadcast 10.73.33.255
        ether 22:2b:62:bb:a9:82  txqueuelen 1000  (Ethernet)
        RX packets 28683  bytes 1961744 (1.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 93  bytes 13770 (13.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp3s0nsby: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 22:2b:62:bb:a9:82  txqueuelen 1000  (Ethernet)
        RX packets 28345  bytes 1924974 (1.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 22:2b:62:bb:a9:82  txqueuelen 1000  (Ethernet)
        RX packets 339  bytes 36836 (35.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 95  bytes 14406 (14.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

# ip link show 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 22:2b:62:bb:a9:82 brd ff:ff:ff:ff:ff:ff
3: enp3s0nsby: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master enp3s0 state UP mode DEFAULT group default qlen 1000
    link/ether 22:2b:62:bb:a9:82 brd ff:ff:ff:ff:ff:ff
4: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master enp3s0 state UP mode DEFAULT group default qlen 1000
    link/ether 22:2b:62:bb:a9:82 brd ff:ff:ff:ff:ff:ff


4.On target host,create NetXtreme BCM57810 VF and set the mac address of the VF 
ip link set enp131s0f0 vf 0  mac 22:2b:62:bb:a9:82


5.start a target guest in listening mode in order to  wait for migrating from source guest
...
-incoming tcp:0:5800 \

6.keep pinging the vm during the migration
# ping 10.73.33.236

7.Migrate guest from source host to target host. 
(qemu) migrate -d tcp:10.73.73.73:5800
migrate guest successfully.

8.check ping output
# ping 10.73.33.236 
64 bytes from 10.73.33.236: icmp_seq=59 ttl=61 time=3.07 ms
64 bytes from 10.73.33.236: icmp_seq=60 ttl=61 time=4.35 ms
64 bytes from 10.73.33.236: icmp_seq=61 ttl=61 time=2.10 ms
64 bytes from 10.73.33.236: icmp_seq=62 ttl=61 time=4.53 ms[1]
64 bytes from 10.73.33.236: icmp_seq=88 ttl=61 time=7.39 ms[2]  
64 bytes from 10.73.33.236: icmp_seq=89 ttl=61 time=4.35 ms
64 bytes from 10.73.33.236: icmp_seq=90 ttl=61 time=5.82 ms
64 bytes from 10.73.33.236: icmp_seq=91 ttl=61 time=4.39 ms

[1]
when "virtio_net virtio1 enp3s0: failover primary slave:enp4s0 unregistered" is outputed in source guest vm dmesg,ping will not work until the migration is completed.
[2]
when migration is completed,ping works again.

9.check the target guest network status, everything works well.

10. migrate vm back from target host to source host,repeat step4-step7 
migrate guest successfully

11.check the ping output
get the same result as step8


I think the expected test result is ping should always work during migration, because hypervisor will fail over to the virtio netdev datapath when the VF is unplugged.

But from the test result that I got in step8 and step11, I can not get ping reply from guest immediately after the VF is hot-unplugged.(the vm didn't reach downtime at this time).

The cause of this problem needs to be further traced.

Comment 12 Yanghang Liu 2020-01-09 05:04:28 UTC
According to test result in step 7 and step 10,this bug has been fixed to live migrate vm with VF.
Move the bug status to 'VERIFIED'.

I have opened a new bug to track the ping-not-working problem mentioned in Comment 10.
Bug 1789206 - ping can not always work during live migration of vm with VF.

Comment 14 errata-xmlrpc 2020-02-04 18:28:50 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:0404


Note You need to log in before you can comment on or make changes to this bug.