Re: [Qemu-discuss] qemu network question/problem

[Jakob Bohm]

On 15/02/2016 16:25, Bruce R JONES wrote:
> I am running several qemu/kvm guests on my server.  Both server and 
> guests are running Linux.  The guests images all need to be able to 
> communicate with each other, the server and other machines on the 
> network.  Because of that I chose to setup a bridged network using 
> tun/tap interfaces.  On the server I created a bridge interface.  The 
> server interface eth0 is placed in that bridge.  I also created tunnel 
> endpoints with the tunctl command.  Those tunnel endpoints also go 
> into the bridge.  The args to qemu include the following:
> -netdev type=tap,id=eth0,ifname=tun0,script=no,downscript=no –device 
> virtio-net-pci,netdev=eth0
> I assign IP addresses to the various interfaces.   The network runs 
> fine and I have the necessary connectivity everywhere.
> The problem is when there is a large amount of traffic on the server 
> network.  We have had several broadcast storms, or other heavy blasts 
> of traffic.  This seems to bring the qemu guests to their knees.  I 
> suspect it is because the qemu guests receive all of that traffic and 
> have a hard time handling it.  Since the server eth0 is part of a 
> bridge it is in promiscuous mode, so instead of filtering traffic in 
> the NIC by MAC address all traffic is received and sent to the 
> bridge.  The bridge has to handle it all and flood it to each of the 
> qemu guests.  Each of those guests in turn have to handle all that 
> traffic in software.
> Just wondering if there is a better way to design the network, or some 
> recommendations on how to prevent or reduce the impact of such traffic.
I don't know, what you are doing is actually the usually
"best" setup.

Some possibilities:

1. Check if there is a bug in the qemu virtio-net-pci
  emulation which fails to emulate the "not promiscuous"
  setting as set by the Guest OS.  In other words, does
  the qemu code on host fail to drop incoming packets
  that are not supposed to be delivered to the Guest
  (because the MAC destination is wrong and the Guest
  has not set the virtual NIC in promiscuous mode)?

2. Check if there is a bug in the Host linux kernel bridge
  code which fails to do the packet limitation work that a
  real Ethernet switch would do.

3. Check if the traffic blasts are actually
  broadcasts/multicasts that are (from an Ethernet
  perspective) supposed to reach the Guests.

4. If 1 or 2 is the problem, set up ebtables on the Host
  with rules that simply emulate the missing MAC
  filtering.  For example packets to 12:34:56:78:9A:BC
  should only be delivered to the VM tap interface whose
  corresponding Guest NIC has that MAC address,

5. Check if there is some kind of add-on for the Linux
  Bridge subsystem (on the Host) to do the missing MAC
  filtering (similar to how the ARP subsystem can be
  supplemented with an ARP daemon).

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded