From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lukas Kolbe Subject: tun/tap and Vlans (was: Re: Network I/O performance) Date: Tue, 19 May 2009 09:18:11 +0200 Message-ID: <1242717491.28272.12.camel@larosa> References: <0199E0D51A61344794750DC57738F58E66BBF927A9@GVW1118EXC.americas.hpqcorp.net> <4A0A7556.4070406@redhat.com> <0199E0D51A61344794750DC57738F58E66BC980A2D@GVW1118EXC.americas.hpqcorp.net> <4A107E3A.9050209@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: "kvm@vger.kernel.org" To: Avi Kivity Return-path: Received: from core.mokelbu.de ([85.10.222.94]:55889 "EHLO core.mokelbu.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751482AbZESHvs (ORCPT ); Tue, 19 May 2009 03:51:48 -0400 In-Reply-To: <4A107E3A.9050209@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Hi all, On a sidenote: > > I have also realized that when using the tun/tap configuration with > > a bridge, packets are replicated on all tap devices when QEMU writes > > packets to the tun interface. I guess this is a limitation of > > tun/tap as it does not know to which tap device the packet has to go > > to. The tap device then eventually drops packets when the > > destination MAC is not its own, but it still receives the packet > > which causes more overhead in the system overall. > > Right, I guess you'd see this with a real switch as well? Maybe have > your guest send a packet out once in a while so the bridge can learn its > MAC address (we do this after migration, for example). Does this mean that it is not possible for having each tun device in a seperate bridge that serves a seperate Vlan? We have experienced a strange problem that we couldn't yet explain. Given this setup: Guest Host kvm1 --- eth0 -+- bridge0 --- vlan1 \ | +-- eth0 kvm2 -+- eth0 -/ / \- eth1 --- bridge1 --- vlan2 + When sending packets through kvm2/eth0, they appear on both bridges and also vlans, also when sending packets through kvm2/eth1. When the guest has only one interface, the packets only appear on one bridge and one vlan as it's supposed to be. Can this be worked around? -- Lukas