On 01/27/2010 03:44 AM, Michael S. Tsirkin wrote:
On Wed, Jan 27, 2010 at 10:34:35AM +0100, Arnd Bergmann wrote:
On Wednesday 27 January 2010, Michael S. Tsirkin wrote:
I am not sure I agree with this sentiment. The main issue being that
macvtap doesn't exist on all kernels :). macvlan also requires hardware
support, packet socket can work with any network card in promisc mode.
To be clear, macvlan does not require hardware support, it will happily
put cards into promiscous mode if they don't support multiple mac addresses.
I agree to that. People don't even seem to agree whether it's a raw
socket or a packet socket :) We need a better name for this option: what
it really does is rely on an external device to loopback a packet to us,
so how about -net loopback or -net extbridge?
I think -net socket,fd should just be (trivially) extended to work with raw
sockets out of the box, with no support for opening it. Then you can have
libvirt or some wrapper open a raw socket and a private namespace and just pass it
down.
That'd work. Anthony?
What functionality are we trying to achieve? Let's be very specific
about use-cases here. If it's VEPA, like you mentioned earlier, why
isn't macvtap a better solution from a security perspective?
The fundamental problem that I have with all of this is that we should
not be introducing new network backends that are based around something
only a developer is going to understand. If I'm a user and I want to
use an external switch in VEPA mode, how in the world am I going to know
that I'm supposed to use the -net raw backend or the -net socket
backend? It might as well be the -net butterflies backend as far as a
user is concerned.
Networking in QEMU is already hard enough for users, we shouldn't make
it worse than it already is.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
