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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
