Re: [virtio-dev] [PATCH v4] content: Introduce VIRTIO_NET_F_STANDBY feature

["Michael S. Tsirkin" <mst@redhat.com>]

Great to see you making progress on this!
Some comments below:

On Wed, Nov 21, 2018 at 05:39:38PM +0200, Sameeh Jubran wrote:
> I have created a setup which has two hosts (host A and host B) with X710 10G
> cards connected back to back. On one host (I'll refer to this host as host A) I
> have configured a bridge with the PF interface as well as vitio-net's interface
> (standby) both attached to it. 

...

> The command line I used:
> 
> /root/qemu/x86_64-softmmu/qemu-system-x86_64 \
> -netdev tap,id=hostnet0,script=world_bridge_standalone.sh,downscript=no,ifname=
> cc17 \
> -device e1000,netdev=hostnet0,mac=56:cc:c1:01:cc:21,id=cc17 \

What's e1000 doing here?
Can this be reason you can not talk to host?

> -netdev tap,vhost=on,id=hostnet1,script=test_bridge_standalone.sh,downscript=
> no,ifname=cc1_72,queues=4 \
> -device virtio-net,host_mtu=1500,netdev=hostnet1,mac=8a:f7:20:29:3b:cb,id=
> cc1_72,vectors=10,mq=on,primary=cc1_71 \
> -device vfio-pci,host=65:02.1,id=cc1_71,standby=cc1_72 \
> -enable-kvm \
> -name netkvm \
> -m 3000M \
> -drive file=/dev/shm/fedora_29.qcow2,if=ide,id=drivex \
> -smp 4 \
> -vga qxl \
> -spice port=6110,disable-ticketing \
> -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x7 \
> -chardev spicevmc,name=vdagent,id=vdagent \
> -device virtserialport,nr=1,bus=virtio-serial0.0,chardev=vdagent,name=
> com.redhat.spice.0 \
> -chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0 \
> -device virtio-serial \
> -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 \
> -monitor stdio


...

> Since I couldn't ping from VM to host B, I did an iperf test between the VM and
> host A with the feature enabled and during the test I have unplugged the sriov
> device, the device was unplugged successfully and no drops where observed as
> you can see in the results below:
> 
> [root@dhcp156-44 ~]# ifconfig

Well I suspect this won't tell you anything, this shows packet drops at
the hardware level. When e.g. link is down linux won't send any packets
out. The simplest test is to monitor latency and throughput and see that
while it is lower for the duration of migration, there are no huge
spikes around the switch.

-- 
MST