Herbert Poetzl [EMAIL PROTECTED] writes:
On Fri, Dec 08, 2006 at 12:57:49PM -0700, Eric W. Biederman wrote:
Herbert Poetzl [EMAIL PROTECTED] writes:
But, ok, it is not the real point to argue so much imho
and waste our time instead of doing things.
well, IMHO better talk (and think)
On Sat, Dec 09, 2006 at 04:50:02AM +0100, Herbert Poetzl wrote:
On Fri, Dec 08, 2006 at 12:57:49PM -0700, Eric W. Biederman wrote:
Herbert Poetzl [EMAIL PROTECTED] writes:
But, ok, it is not the real point to argue so much imho
and waste our time instead of doing things.
well,
On Sat, Dec 09, 2006 at 12:27:34PM +0100, Tomasz Torcz wrote:
On Sat, Dec 09, 2006 at 04:50:02AM +0100, Herbert Poetzl wrote:
On Fri, Dec 08, 2006 at 12:57:49PM -0700, Eric W. Biederman wrote:
Herbert Poetzl [EMAIL PROTECTED] writes:
But, ok, it is not the real point to argue so much
On Saturday 09 December 2006 09:35, Herbert Poetzl wrote:
On Fri, Dec 08, 2006 at 10:13:48PM -0800, Andrew Morton wrote:
On Sat, 9 Dec 2006 04:50:02 +0100
Herbert Poetzl [EMAIL PROTECTED] wrote:
On Fri, Dec 08, 2006 at 12:57:49PM -0700, Eric W. Biederman wrote:
Herbert Poetzl [EMAIL
Herbert Poetzl wrote:
On Fri, Dec 08, 2006 at 10:13:48PM -0800, Andrew Morton wrote:
It's actually happening quite gradually and carefully.
hmm, I must have missed a testing phase for the
IPC namespace then, not that I think it is broken
(well, maybe it is, we do not know yet)
On Sun, Dec 10, 2006 at 01:34:14AM +0300, Kir Kolyshkin wrote:
Herbert Poetzl wrote:
On Fri, Dec 08, 2006 at 10:13:48PM -0800, Andrew Morton wrote:
It's actually happening quite gradually and carefully.
hmm, I must have missed a testing phase for the
IPC namespace then, not that
Herbert Poetzl [EMAIL PROTECTED] writes:
But, ok, it is not the real point to argue so much imho and waste our
time instead of doing things.
well, IMHO better talk (and think) first, then implement
something ... not the other way round, and then start
fixing up the mess ...
Well we need a
On Fri, Dec 08, 2006 at 12:57:49PM -0700, Eric W. Biederman wrote:
Herbert Poetzl [EMAIL PROTECTED] writes:
But, ok, it is not the real point to argue so much imho
and waste our time instead of doing things.
well, IMHO better talk (and think) first, then implement
something ... not
On Sat, 9 Dec 2006 04:50:02 +0100
Herbert Poetzl [EMAIL PROTECTED] wrote:
On Fri, Dec 08, 2006 at 12:57:49PM -0700, Eric W. Biederman wrote:
Herbert Poetzl [EMAIL PROTECTED] writes:
But, ok, it is not the real point to argue so much imho
and waste our time instead of doing things.
On Fri, Dec 08, 2006 at 10:13:48PM -0800, Andrew Morton wrote:
On Sat, 9 Dec 2006 04:50:02 +0100
Herbert Poetzl [EMAIL PROTECTED] wrote:
On Fri, Dec 08, 2006 at 12:57:49PM -0700, Eric W. Biederman wrote:
Herbert Poetzl [EMAIL PROTECTED] writes:
But, ok, it is not the real point to
If there is a better and less intrusive while still being obvious
method I am all for it. I do not like the OpenVZ thing of doing the
lookup once and then stashing the value in current and the special
casing the exceptions.
Why?
I like it when things are obvious and not implied.
The
On Wed, Dec 06, 2006 at 02:54:16PM +0300, Kirill Korotaev wrote:
If there is a better and less intrusive while still being obvious
method I am all for it. I do not like the OpenVZ thing of doing the
lookup once and then stashing the value in current and the special
casing the exceptions.
Hi Jamal,
thanks for taking the time read the document.
The objective of the document was not to convince one approach is better
than other. I wanted to show the pros and the cons of each approach and
to point that the 2 approaches are complementary.
Currently, there are some resources
jamal [EMAIL PROTECTED] writes:
I have removed the Re: just to add some freshness to the discussion
So i read quickly the rest of the discussions. I was almost suprised to
find that i agree with Eric on a lot of opinions (we also agree that
vindaloo is good for you i guess);-
The two issues
Daniel,
On Mon, 2006-04-12 at 11:18 +0100, Daniel Lezcano wrote:
Hi Jamal,
Currently, there are some resources moved to a namespace relative
access, the IPC and the utsname and this is into the 2.6.19 kernel.
The work on the pid namespace is still in progress.
The idea is to use a clone
On Mon, 2006-04-12 at 05:15 -0700, Eric W. Biederman wrote:
jamal [EMAIL PROTECTED] writes:
Containers are a necessary first step to getting migration and
checkpoint/restart
assistance from the kernel.
Isnt it like a MUST have if you are doing things from scratch instead of
it being an
On Sunday 03 December 2006 19:00, Eric W. Biederman wrote:
Ok. Just a quick summary of where I see the discussion.
We all agree that L2 isolation is needed at some point.
As we all agreed on this, may be it is time to send patches one-by-one?
For the beggining, I propose to resend Cedric's
jamal [EMAIL PROTECTED] writes:
On Mon, 2006-04-12 at 05:15 -0700, Eric W. Biederman wrote:
jamal [EMAIL PROTECTED] writes:
Containers are a necessary first step to getting migration and
checkpoint/restart
assistance from the kernel.
Isnt it like a MUST have if you are doing things from
Dmitry Mishin [EMAIL PROTECTED] writes:
On Sunday 03 December 2006 19:00, Eric W. Biederman wrote:
Ok. Just a quick summary of where I see the discussion.
We all agree that L2 isolation is needed at some point.
As we all agreed on this, may be it is time to send patches one-by-one?
For the
On Monday 04 December 2006 18:35, Eric W. Biederman wrote:
[skip]
Where and when you look to find the network namespace that applies to
a packet is the primary difference between the OpenVZ L2
implementation and my L2 implementation.
If there is a better and less intrusive while still being
On Mon, Dec 04, 2006 at 06:19:00PM +0300, Dmitry Mishin wrote:
On Sunday 03 December 2006 19:00, Eric W. Biederman wrote:
Ok. Just a quick summary of where I see the discussion.
We all agree that L2 isolation is needed at some point.
As we all agreed on this, may be it is time to send
Dmitry Mishin [EMAIL PROTECTED] writes:
On Monday 04 December 2006 18:35, Eric W. Biederman wrote:
[skip]
Where and when you look to find the network namespace that applies to
a packet is the primary difference between the OpenVZ L2
implementation and my L2 implementation.
If there is a
Herbert Poetzl [EMAIL PROTECTED] writes:
On Mon, Dec 04, 2006 at 06:19:00PM +0300, Dmitry Mishin wrote:
On Sunday 03 December 2006 19:00, Eric W. Biederman wrote:
Ok. Just a quick summary of where I see the discussion.
We all agree that L2 isolation is needed at some point.
As we all
On Monday 04 December 2006 19:43, Herbert Poetzl wrote:
On Mon, Dec 04, 2006 at 06:19:00PM +0300, Dmitry Mishin wrote:
On Sunday 03 December 2006 19:00, Eric W. Biederman wrote:
Ok. Just a quick summary of where I see the discussion.
We all agree that L2 isolation is needed at some
Dmitry Mishin wrote:
On Monday 04 December 2006 19:43, Herbert Poetzl wrote:
On Mon, Dec 04, 2006 at 06:19:00PM +0300, Dmitry Mishin wrote:
On Sunday 03 December 2006 19:00, Eric W. Biederman wrote:
Ok. Just a quick summary of where I see the discussion.
We all agree that L2 isolation is
On Mon, Dec 04, 2006 at 08:02:48PM +0300, Dmitry Mishin wrote:
On Monday 04 December 2006 19:43, Herbert Poetzl wrote:
On Mon, Dec 04, 2006 at 06:19:00PM +0300, Dmitry Mishin wrote:
On Sunday 03 December 2006 19:00, Eric W. Biederman wrote:
Ok. Just a quick summary of where I see the
On Wed, 2006-14-11 at 16:17 +0100, Daniel Lezcano wrote:
The attached document describes the network isolation at the layer 2
and at the layer 3 ..
Daniel,
I apologize for taking this long to get back to you. The document (I
hope) made it clear to me at least the difference between the two
I have removed the Re: just to add some freshness to the discussion
So i read quickly the rest of the discussions. I was almost suprised to
find that i agree with Eric on a lot of opinions (we also agree that
vindaloo is good for you i guess);-
The two issues that stood out for me (in addition to
Ok. Just a quick summary of where I see the discussion.
We all agree that L2 isolation is needed at some point.
The approaches discussed for L2 and L3 are sufficiently orthogonal
that we can implement then in either order. You would need to
unshare L3 to unshare L2, but if we think of them as
On Sun, Dec 03, 2006 at 07:26:02AM -0500, jamal wrote:
On Wed, 2006-14-11 at 16:17 +0100, Daniel Lezcano wrote:
The attached document describes the network isolation at the layer 2
and at the layer 3 ..
Daniel,
I apologize for taking this long to get back to you. The document (I
hope)
On Sun, 2006-03-12 at 17:37 +0100, Herbert Poetzl wrote:
On Sun, Dec 03, 2006 at 07:26:02AM -0500, jamal wrote:
To use an extreme example: if i picked apache as a
binary compiled 10 years ago, it will run on the L2 approach but not on
the L3 approach. Is this understanding correct? I find
[EMAIL PROTECTED] (Eric W. Biederman) writes in gmane.linux.network:
Ok. So on this point we agree. Full isolation at the network device/L2 level
is desirable and no one is opposed to that.
There is however a strong feeling especially for the case of application
containers that something
Kari Hurtta [EMAIL PROTECTED] writes in gmane.linux.network:
[EMAIL PROTECTED] (Eric W. Biederman) writes in gmane.linux.network:
Ok. So on this point we agree. Full isolation at the network device/L2
level
is desirable and no one is opposed to that.
There is however a strong
Daniel Lezcano wrote:
Brian Haley wrote:
Eric W. Biederman wrote:
I think for cases across network socket namespaces it should
be a matter for the rules, to decide if the connection should
happen and what error code to return if the connection does not
happen.
There is a potential in this
Vlad Yasevich wrote:
Daniel Lezcano wrote:
Brian Haley wrote:
Eric W. Biederman wrote:
I think for cases across network socket namespaces it should
be a matter for the rules, to decide if the connection should
happen and what error code to return if the connection does not
happen.
There is a
On Thu, Nov 30, 2006 at 05:38:16PM +0100, Daniel Lezcano wrote:
Vlad Yasevich wrote:
Daniel Lezcano wrote:
Brian Haley wrote:
Eric W. Biederman wrote:
I think for cases across network socket namespaces it should
be a matter for the rules, to decide if the connection should
happen and
Eric W. Biederman wrote:
I think for cases across network socket namespaces it should
be a matter for the rules, to decide if the connection should
happen and what error code to return if the connection does not
happen.
There is a potential in this to have an ambiguous case where two
Brian Haley wrote:
Eric W. Biederman wrote:
I think for cases across network socket namespaces it should
be a matter for the rules, to decide if the connection should
happen and what error code to return if the connection does not
happen.
There is a potential in this to have an ambiguous case
Eric W. Biederman wrote:
[ snip ]
The packets arrive to the real device and go through the routes
engine. From this point, the used route is enough to know to which
container the traffic can go and the sockets subset assigned to the
container.
Note this has potentially the highest overhead
I do not want to get into a big debate on the merits of various
techniques at this time. We seem to be in basic agreement
about what we are talking about.
There is one thing I think we can all agree upon.
- Everything except isolation at the network device/L2 layer, does not
allow guests to
On Tue, Nov 28, 2006 at 09:51:57AM -0700, Eric W. Biederman wrote:
I do not want to get into a big debate on the merits of various
techniques at this time. We seem to be in basic agreement
about what we are talking about.
There is one thing I think we can all agree upon.
- Everything
Eric W. Biederman wrote:
I do not want to get into a big debate on the merits of various
techniques at this time. We seem to be in basic agreement
about what we are talking about.
There is one thing I think we can all agree upon.
- Everything except isolation at the network device/L2
On Tue, Nov 28, 2006 at 02:50:03PM -0700, Eric W. Biederman wrote:
Daniel Lezcano [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
I do not want to get into a big debate on the merits of various
techniques at this time. We seem to be in basic agreement
about what we are talking
On Tue, Nov 28, 2006 at 09:26:52PM +0100, Daniel Lezcano wrote:
Eric W. Biederman wrote:
I do not want to get into a big debate on the merits of various
techniques at this time. We seem to be in basic agreement
about what we are talking about.
There is one thing I think we can all
On Sat, Nov 25, 2006 at 01:21:39AM -0700, Eric W. Biederman wrote:
jamal [EMAIL PROTECTED] writes:
On Fri, 2006-27-10 at 11:10 +0200, Daniel Lezcano wrote:
No, it uses virtualization at layer 2 and I had already mention it
before (see the first email of the thread), but thank you for
Herbert Poetzl wrote:
On Sat, Nov 25, 2006 at 01:21:39AM -0700, Eric W. Biederman wrote:
Then the question is how do we reduce the overhead when we don't have
enough physical network interfaces to go around. My feeling is that
we could push the work to the network adapters and allow single
Herbert Poetzl [EMAIL PROTECTED] writes:
On Sat, Nov 25, 2006 at 01:21:39AM -0700, Eric W. Biederman wrote:
There are two techniques in real use.
- Bind/Accept filtering
Which layer 3 addresses a socket can bind/accept are filtered,
but otherwise the network stack remains unchanged.
virtualization/isolation
Leonid Grossman [EMAIL PROTECTED] writes:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric W.
Biederman
Then the question is how do we reduce the overhead when we
don't have
enough physical network interfaces
Leonid Grossman [EMAIL PROTECTED] writes:
I did not mean kernel bypass, just L2 hw channels that for
all practical purposes act as separate NICs -
different MAC addresses, no blocking, independent reset, etc.
Yes. Nearly all of what you need for safe kernel bypass.
In the worst case I
Then a matrix of how each requires what modifications in the network
code. Of course all players need to agree that the description is
accurate.
Is there such a document?
cheers,
jamal
Hi,
the attached document describes the network isolation at the layer 2 and
at the layer 3, it presents
On Tue, 14 Nov 2006, Daniel Lezcano wrote:
the attached document describes the network isolation at the layer 2 and at
the layer 3, it presents the pros and cons of the different approaches, their
common points and the impacted network code.
I hope it will be helpful :)
What about other
On Fri, 2006-27-10 at 11:10 +0200, Daniel Lezcano wrote:
No, it uses virtualization at layer 2 and I had already mention it
before (see the first email of the thread), but thank you for the email
thread pointer.
What would be really useful is someone takes the time and creates a
matrix of
What would be really useful is someone takes the time and creates a
matrix of the differences between the implementations.
It seems there are quiet a few differences but without such comparison
(to which all agree to) it is hard to form an opinion without a document
of some form.
If Dmitry is
the container enablement into the kernel is
doing good progress. The ipc, pid, utsname and filesystem system
ressources are isolated/virtualized relying on the namespaces concept.
But, there is missing the network virtualization/isolation. Two
approaches are proposed: doing the isolation
[ ... ]
Dmitry Mishin wrote:
Stephen,
Virtualized container can be secure, if it is complete system virtualization,
not just an application container. OpenVZ implements such and it is used hard
over the world. And of course, we care a lot to keep hostile root from
killing whole system.
relying on the namespaces concept.
But, there is missing the network virtualization/isolation. Two
approaches are proposed: doing the isolation at the layer 2 and at the
layer 3.
The first one instanciate a network device by namespace and add a peer
network device into the root namespace, all
. The ipc, pid, utsname and filesystem system
ressources are isolated/virtualized relying on the namespaces concept.
But, there is missing the network virtualization/isolation. Two
approaches are proposed: doing the isolation at the layer 2 and at the
layer 3.
The first one instanciate
Stephen Hemminger wrote:
On Thu, 26 Oct 2006 11:44:55 +0200
Daniel Lezcano [EMAIL PROTECTED] wrote:
[ ... ]
Assuming you are talking about pseudo-virtualized environments,
there are several different discussions.
Yes, exact, I forgot to mention that.
1. How should the namespace be
Hi Stephen,
currently the work to make the container enablement into the kernel is
doing good progress. The ipc, pid, utsname and filesystem system
ressources are isolated/virtualized relying on the namespaces concept.
But, there is missing the network virtualization/isolation. Two
concept.
But, there is missing the network virtualization/isolation. Two
approaches are proposed: doing the isolation at the layer 2 and at the
layer 3.
The first one instanciate a network device by namespace and add a peer
network device into the root namespace, all the routing ressources
60 matches
Mail list logo
