User: Password:
|
|
Subscribe / Log in / New account

eclone()

eclone()

Posted Nov 19, 2009 17:44 UTC (Thu) by MarkWilliamson (subscriber, #30166)
Parent article: eclone()

I still don't entirely understand why the need here can't be satisfied in
some way using the containerisation mechanisms (and possibly extending them
somewhat) to allow the resumed processes to believe they have the same PIDs,
though these actually might have changed.

A clone_with_pids() or equivalent doesn't really seem like a solution to me
- if those PIDs are taken then you're stuck, right? That seems a bit
brittle.


(Log in to post comments)

eclone()

Posted Nov 19, 2009 18:39 UTC (Thu) by dmag (guest, #17775) [Link]

I'm with Linus on this one. He complained that "checkpoint/restart" will only work with a small subset of programs anyway. Everything from TCP connections to open files are always going to be problematic. So why not put a little bit of the burden on the process itself (to deal with new PIDs), instead of trying to complicate the kernel?

eclone() / containers

Posted Nov 20, 2009 9:45 UTC (Fri) by nicollet (subscriber, #37185) [Link]

Because we can't rewrite all the userland apps to be container aware. I think containers are the right way to go. Hypervisors are a way to say: "our OS can't use all the horsepower, let's put several hosts on the same physical machine".

Containers might also help to migrate virtual machines from one physical host to the other very fast, by tuning the VM subsystem. Today any page can be in the RAM or Swapped. During a container migration, we can add a third level: "on this host". That way if you want to move a 1 GB vserver/container, you wouldn't need to transfer the whole data to begin executing code.
It would help to reduce the TCP latency problem IMHO.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds