Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu

Anthony Liguori
2010-01-27T14:03:24Z

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