if you say "no network connections" and "no open files",
the problem gets a lot easier - but also quickly devolving into a
master's thesis research project rather than anything useful....

Actually it is a master's thesis research project as of now. I am ready to boil down to the most basic implementation of distributed linux kernel. Assume there is no network connection and no open files. We can drop even more assumptions if it becomes complicated. Once this basic implementation is successful, we can go ahead with a more complicated version. The next task is to integrate the migration code in the linux kernel. What is the most easy way of implementing it.

On Tue, Feb 16, 2016 at 10:05 PM, <Valdis.Kletnieks@vt.edu> wrote:

On Tue, 16 Feb 2016 09:42:52 +0100, Dominik Dingel said:

> I wouldn't see things that dark. Also this is an interesting puzzle.

Just pointing out *very real* issues that will require solution, unless
you add strict bounds like "cannot be using network connections".

Heck, even open files get interesting. How do you ensure that the
file descriptor returned by mkstemp() remains valid? (The *really*
ugly case is programs that do a mkstemp() and then unlink() the result,
confident that the kernel will clean up when the process exits, as
there is no longer a file system object to reference....

Of course, if you say "no network connections" and "no open files",
the problem gets a lot easier - but also quickly devolving into a
master's thesis research project rather than anything useful....

Bottom line: Don't even *think* about changing the scheduler etc
until you have a functional way to actually move the process. Doesn't
matter if you use a kvm approach, or containers, or whatever - if
you can't do the migrate, you can't even *test* your code that decides
which process to migrate.....