Re: (pspace,pid) vs true pid virtualization

[Herbert Poetzl <herbert@13thfloor.at>]

On Mon, Feb 20, 2006 at 12:37:25PM +0300, Kirill Korotaev wrote:
> >>- 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 :) )

IMHO there are certain things which _are_ required
and others which are nice to have but not strictly
required, just think "ptrace across pid spaces"

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

well, not the child pspace, but the parent, no?

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

because we are not trying to implement a VPS only
solution for mainline, we are trying to provide
building blocks for many different uses, including
the VPS approach ...

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

ptrace across pid spaces is not required, it is
nice to have and probably adds a bunch of security
issues ...

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

management tools should have a way to get the
required information, they do not necessarily need
to utilize existing interfaces ...

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

best,
Herbert

> Kirill