Re: RFC [patch 13/34] PID Virtualization Define new task_pid api

[Cedric Le Goater <clg@fr.ibm.com>]

Eric W. Biederman wrote:

> For everything except the PID namespace I am just interested in having multiple
> separate namespaces.  For the PID namespace to keep the traditional unix
> model you need a parent process so it is actually nesting.
> 
> I am interested because, it is easy, because if it is possible than
> the range of applications you can apply a containers to is much
> larger.  At the far end of that spectrum is migrating a server running
> on real hardware and bringing it up as a guest on a newer much more
> powerful machine.  With the appearance that it had only been
> unreachable for a few seconds.

We gave a name to such containers. We call them 'application' containers
just to make a difference with the 'system' containers, like vserver or openvz.

'application' containers are very useful in an HPC environment where you
can trig checkpoint/restart through batch managers. But, this model,
really, has some virtualization issues on the edge. The virtualisation of
the parent process of such a container is tricky, it can be in multiple
containers at the same time, it can die (difficult to restart ...), it
could belong to another process groups, etc. Plenty of annoying cases to
handle.

'system' containers, like vserver or openvz, are safer because they use a
private PID space.

Now, would it be possible to have an 'application' container using a
private PID space and being friendly to the usual unix process semantics ?
We haven't found a solution yet ...

> Entering is different from execing a process on the inside.
> Implementation wise it is changing the context pointer on your task.

yes and you could restrict that privilege to some top level container, like
the container 0.

C.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/