On 04/18/2011 09:20 PM, Arnd Bergmann wrote: > On Monday 18 April 2011, Ingo Molnar wrote: >>> Only in VEPA mode. Note that a similar restriction applies when using the >>> bridge device, for the same technical reasons. >> >> Just to sum things up, our goal is to allow the tools/kvm/ unprivileged tool to >> provide TCP connectivity to Linux guests transparently, with the following >> parameters: >> >> - the kvm tool runs unprivileged - as ordinary user >> >> - without having to configure much (preferably zero configuration: without >> having to configure anything) on the guest Linux side >> >> - multiple guests should just work without interfering with each other >> >> - the kvm tool wants to be stateless - i.e. it does not want to allocate or >> manage host side devices - it just wants to provide the kind of TCP/IP >> connectivity host unprivileged user-space has, to the guest. The tool wants >> to be a generic tool with no global state, not a daemon. >> >> So it wants to be a stateless, unprivileged and zero-configuration solution. >> >> Is this possible with macvtap, and if yes, what kind of macvtap mode and usage >> would you recommend for that goal? > > With the above requirements, I would suggest using something like the the qemu > user networking. This is slower and does not allow servers to be present in > the guest, but those are not your goal as it seems. > > The primary goals of macvtap are to allow efficient networking (zero-copy, > multi-queue, although we're not completely there yet) and proper security > abstractions. > > If you want a guest to appear on the same network as the host, you can not > do that without privileges to manage the host network setup, and I guess that > will have to stay that way. We do need "guest appearing on the same network as the host" support as well. The reason I am considering using macvatp instead of tap plus brctl is that it simplifies the bridge configuration and it is more efficient. However, IMHO, the interface of macvtap is not user friendly, at least for me. I have no idea about the technical reasons that make the low-level device inaccessible. But if it is accessible, a lot of configuration can be eliminated. I know virtualbox's bridge mode has this kind of restriction, while VMware's bridge mode does not. > > Arnd > -- Best Regards, Asias He -- 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
