- 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
