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.
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
