qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 6/7] virtio-net: Add new RX filter controls
Date: Mon, 08 Jun 2009 16:03:50 -0500
User-agent: Thunderbird 2.0.0.21 (X11/20090320)

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.

Regards,

Anthony Liguori





reply via email to

[Prev in Thread] Current Thread [Next in Thread]