Re: (pspace,pid) vs true pid virtualization

[Kirill Korotaev <dev@sw.ru>]

> > This is to support using pidspaces for vservers, and creating
> > migrateable sub-pidspaces in each vserver.
>
>
> Agreed.
>
> Now this case is very interesting, because supporting it creates
> interesting restrictions on the rest of the problem, and
> unless I miss something this is where the OpenVZ implementation
> currently falls down.
why do you think so? VPIDs approach supports nested pspaces easily. 
Moreover it can be used in any configuration. See below.

> Which names does the intermediate pidspace (vserver) see the child
> pidspace with
options:
- all pspaces except for host system can live fully with virtual pids
- you can restrict what parent pspace can see from it's child. and as in 
your case you can see only "init".
- you can make fully isolated pspaces, where these problems doesn't 
arise at all.


> Which names does the initial pidspace see the child pid space with?
initial pidspace always sees "global" pids.

> > > - 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.
See my other emails. This is required.
1. Enter doesn't always work. e.g. due to resource limitations.
2. you may don't want to install some apps inside, especiall taking into 
account that libs in VPS can be broken.

> > 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?
> Well I think we can reuse most of the old sysadmin interfaces yes.
Doesn't look so.

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/