Eric W. Biederman wrote:
Kir Kolyshkin <[EMAIL PROTECTED]> writes:
Herbert Poetzl wrote:
my point (until we have an implementation which clearly
shows that performance is equal/better to isolation)
is simply this:
of course, you can 'simulate' or 'construct' all the
isolation scenarios with kernel bridging and routing
and tricky injection/marking of packets, but, this
usually comes with an overhead ...
Well, TANSTAAFL*, and pretty much everything comes with an overhead.
Multitasking comes with the (scheduler, context switch, CPU cache, etc.)
overhead -- is that the reason to abandon it? OpenVZ and Linux-VServer
resource management also adds some overhead -- do we want to throw it away?
The question is not just "equal or better performance", the question is
"what do we get and how much we pay for it".
Equal or better performance is certainly required when we have the code
compiled in but aren't using it. We must not penalize the current code.
That's a valid argument. Although it's not applicable here (at least for
both network virtualization types which OpenVZ offers). Kirill/Andrey,
please correct me if I'm wrong here.
Finally, as I understand both network isolation and network
virtualization (both level2 and level3) can happily co-exist. We do have
several filesystems in kernel. Let's have several network virtualization
approaches, and let a user choose. Is that makes sense?
o
If there are not compelling arguments for using both ways of doing
it is silly to merge both, as it is more maintenance overhead.
Definitely a valid argument as well.
I am not sure about "network isolation" (used by Linux-VServer), but as
it comes for level2 vs. level3 virtualization, I see a need for both.
Here is the easy-to-understand comparison which can shed some light:
http://wiki.openvz.org/Differences_between_venet_and_veth
Here are a couple of examples
* Do we want to let container's owner (i.e. root) to add/remove IP
addresses? Most probably not, but in some cases we want that.
* Do we want to be able to run DHCP server and/or DHCP client inside a
container? Sometimes...but not always.
* Do we want to let container's owner to create/manage his own set of
iptables? In half of the cases we do.
The problem here is single solution will not cover all those scenarios.
That said I think there is a real chance if we can look at the bind
filtering and find a way to express that in the networking stack
through iptables. Using the security hooks conflicts with things
like selinux. Although it would be interesting to see if selinux
can already implement general purpose layer 3 filtering.
The more I look the gut feel I have is that the way to proceed would
be to add a new table that filters binds, and connects. Plus a new
module that would look at a process creating a socket and tell us if
it is the appropriate group of processes. With a little care that
would be a general solution to the layer 3 filtering problem.
Eric
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
