From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MDy4z-0007Ub-8N for qemu-devel@nongnu.org; Tue, 09 Jun 2009 05:57:17 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MDy4u-0007UH-H4 for qemu-devel@nongnu.org; Tue, 09 Jun 2009 05:57:16 -0400 Received: from [199.232.76.173] (port=47077 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MDy4u-0007UE-Af for qemu-devel@nongnu.org; Tue, 09 Jun 2009 05:57:12 -0400 Received: from mx1.redhat.com ([66.187.233.31]:58900) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MDy4t-0006MO-V8 for qemu-devel@nongnu.org; Tue, 09 Jun 2009 05:57:12 -0400 Date: Tue, 9 Jun 2009 10:57:01 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH 6/7] virtio-net: Add new RX filter controls Message-ID: <20090609095701.GC1480@redhat.com> References: <20090605204647.3355.81929.stgit@kvm.aw> <20090605204718.3355.28647.stgit@kvm.aw> <20090606204845.GC26877@redhat.com> <7162ab20906081201y4c598899mdfd5d42c42e17038@mail.gmail.com> <4A2D63EC.9040003@codemonkey.ws> <20090608192911.GA32168@redhat.com> <4A2D7CB6.5060101@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A2D7CB6.5060101@codemonkey.ws> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, Alex Williamson , "Michael S. Tsirkin" On Mon, Jun 08, 2009 at 04:03:50PM -0500, Anthony Liguori wrote: > Daniel P. Berrange wrote: > >On Mon, Jun 08, 2009 at 02:18:04PM -0500, Anthony Liguori wrote: > > > >>Alex Williamson wrote: > >> > >>>e1000 also allows the driver to selectively enable/disable RX of > >>>packets to the broadcast address. This is replicated with the > >>>all/no-bcast options. Finally, there may be cases where we want to > >>>receive only unicast or only multicast address for special purpose > >>>network devices. This is provided by the nouni and nomulti options. > >>>A proprietary guest know as DMX intends to make use of these extra > >>>modes. Are there any other interesting, useful and lightweight packet > >>>filters we could implement? Thanks, > >>> > >>> > >>I've been thinking about whether doing VLAN filtering/tagging within > >>QEMU would make sense. It could potentially simplify bridge setups > >>tremendously. Today, if you want to isolate VMs on separate vlans, it > >>involves creating multiple bridges which gets ugly quickly. > >> > > > >The downside of that would be that you're trusting the integrity of > >QEMU for VLAN filtering. If QEMU got compromised then it could get > >outside the configured VLAN, which is not possible if the VLAN stuff > >is done by the kernel (assuming the QEMU process does not have the > >capabilities to add itself to other bridges). > > > > I guess that you can do: > > tunctl -p -t tap0 > ifconfig tap0 0.0.0.0 up > vconfig add tap0 32 > brctl addif br0 tap0 > > And then use tap0.32 as your device for QEMU. The awkward thing though > is that I don't think you can use TUNSETIFF to set the tun device name > to tap0.32. > > But basically, this is the level of functionality that I think is need. > The current mechanism of: > > vconfig add eth0 32 > brctl addif br0 eth0.32 > tunctl -p -t tap0 > ifconfig tap0 0.0.0.0 up > brctl addif br0 tap0 > > Is a pain because then you need a bridge for every possible vlan. > Things get even more complicated when you have to deal with live > migration and nested vlan tags. Yeah, one bridge per VLAN is the way most people I know currently do VLANs with Xen/KVM. In fact they're typically more complicated, because they'll first put a couple of NICs into a bonding device, Then create VLAN devices on the the bond, then put each into a bridge, before finally adding the TAP devices. Personally I'd just say the bridge config task is the management tool's problem to deal with. A mgmt tool UI shouldn't really need to expose the raw details of physical NICs, bond devices, VLAN devices & bridge devices to the user. Instead allow them to say 'create a network sharing two physical NICs on VLAN 53', and then have it automagically setup the neccessary individal devices behind the scenes. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|