Messages in this thread | | | Date | Mon, 20 Feb 2006 13:47:46 +0100 | From | Herbert Poetzl <> | Subject | Re: (pspace,pid) vs true pid virtualization |
| |
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 - 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/
| |