Re: [ckrm-tech] Re: [RFC][patch 00/21] PID Virtualization: Overview and Patches

On Fri, 16 Dec 2005 09:35:19 PST, Dave Hansen wrote:
> On Thu, 2005-12-15 at 19:28 -0800, Gerrit Huizenga wrote:
> > In the pid virtualization, I would think that tasks can move between
> > containers as well,
> 
> I don't think tasks can not be permitted to move between containers.  As
> a simple exercise, imagine that you have two processes with the same
> pid, one in container A and one in container B.  You wish to have them
> both run in container A.  They can't both have the same pid.  What do
> you do?
> 
> I've been talking a lot lately about how important filesystem isolation
> between containers is to implement containers properly.  Isolating the
> filesystem namespaces makes it much easier to do things like fs-based
> shared memory during a checkpoint/resume.  If we want to allow tasks to
> move around, we'll have to throw out this entire concept.  That means
> that a _lot_ of things get a notch closer to the too-costly-to-implement
> category.

Interesting...  So how to tasks get *into* a container?  And can they
ever get back "out" of a container?  Are most processes on the system
initially not in a container?  And then they can be stuffed in a container?
And then containers can be moved around or be isolated from each other?

And, is pid virtualization the point where this happens?  Or is that
a slightly higher level?  In other words, is pid virtualization the
full implementation of container isolation?  Or is it a significant
element on which additional policy, restrictions, and usage models
can be built?

gerrit


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click