On Wednesday 27 January 2010, Anthony Liguori wrote:
> >>>
> >> Introducing something that is known to be problematic from a security
> >> perspective without any clear idea of what the use-case for it is is a
> >> bad idea IMHO.
> >>
> > vepa on existing kernels is one use-case.
> >
>
> Considering VEPA enabled hardware doesn't exist today and the standards
> aren't even finished being defined, I don't think it's a really strong
> use case ;-)
The hairpin turn (the part that is required on the bridge) was implemented
in the Linux bridge in 2.6.32, so that is one existing implementation you
can use as a peer.
The VEPA mode in macvlan only made it into 2.6.33, so using the raw socket
on older kernels does not give you actual VEPA semantics.
The part of the standard that is still under discussion is the management
side, which is almost entirely unrelated to this question though. With
Linux-2.6.33 on both sides using raw/macvlan and bridge respectively,
you can have a working VEPA setup. The only thing missing is that the
hypervisor will not be able to tell the bridge to automatically enable
hairpin mode (you need to do that on the bridge on a per-port basis).
Now, the most important use case I see for the raw socket interface
in qemu is to get vhost-net and the qemu user implementation to
support the same feature set. If you ask for a network setup involving
a raw socket and vhost-net and the kernel can support raw sockets
but for some reason fails to set up vhost-net, you should have a
fallback that has the exact same semantics at a possibly significant
performance loss.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
