Re: [Qemu-devel] [PATCH 6/7] virtio-net: Add new RX filter controls

["Daniel P. Berrange" <berrange@redhat.com>]

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 :|