Re: (pspace,pid) vs true pid virtualization

[Kirill Korotaev <dev@sw.ru>]

> > - Should the pids in a pid space be visible from the outside?
>
> Again, the openvz guys say yes.
>
> I think it should be acceptable if a pidspace is visible in all it's
> ancestor pidspaces.  I.e. if I create pspace2 and pspace3 from pid 234
> in pspace1, then pspace2 doesn't need to be able to address pspace3
> and vice versa.
>
> Kirill, is that acceptable?
yes, acceptable.
once, again, believe me, this is very required feature for 
troubleshouting and management (as Eric likes to take about maintanance :) )

> > - Should the parent of pid 1 be able to wait for it for it's 
> >  children?
> Yes.
why? any reason?

> > - Should a process not in the default pid space be able to create 
> >  another pid space?
>
>
> Yes.
>
> This is to support using pidspaces for vservers, and creating
> migrateable sub-pidspaces in each vserver.
this doesn't help to create migratable sub-pidspaces.
for example, will you share IPCs in your pid parent and child pspaces?
if yes, then it won't be migratable;
if no, then you need to create fully isolated spaces to the end and 
again you end up with a question, why nested pspaces are required at all?

> > - Should we be able to monitor a pid space from the outside?
> To some extent, yes.
SURE! :)

> > - Should we be able to have processes enter a pid space?
> IMO that is crucial.
required.

> > - Do we need to be able to be able to ptrace/kill individual processes
> >  in a pid space, from the outside, and why?
> I think this is completely unnecessary so long as a process can enter a
> pidspace.
No. This is required.
Because, container can be limited with some resource limitations. You 
may be unable to enter inside. For example, if container forked() many 
threads up to its limit, you won't be able to enter it.

> > - After migration what identifiers should the tasks have?
> So this is irrelevant, as the openvz approach can just virtualize the
> old pid, while (pspace, pid) will be able to create a new container and
> use the old pid values, which are then guaranteed to not be in use.
agreed. irrelevant.

> > If we can answer these kinds of questions we can likely focus in
> > on what the implementation should look like.  So far I have not
> > seen a question that could not be implemented with a (pspace, pid)/pid
> > or a vpid/pid implementation.
> But you have, haven't you?  Namely, how can openvz provide it's
> customers with a global view of all processes without putting 5 years of
> work into a new sysadmin interface?
it is not only about OpenVz. This is about manageability.
This is the feature our users like _very_ much, when administrator can 
fix the problems. Have you ever tried to fix broken VM in VMWare/Xen?
On the other hand, VPID approach can fully isolate containers if needed 
for security reasons.

Kirill

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