Hacker News Reader

Comment by conradev | Hacker News Reader

Could this be used to migrate execution of a single program between two different machines?

Yep. I could imagine a deterministic method of just sending the executable + changed pages. Then load the program in the same way on the other machine, and then apply the changed pages. It would be a minimal transfer. Thread state can also be migrated, but Linux-kernel stuff like FDs cannot or at least, that's not my area of expertise!

There was Condor for this[1], a couple of decades ago. Condor would checkpoint the process and restart it on another machine entirely user-level (but requiring processes to link to their library) by continuing to forward system calls. It of course had plenty of limitations, and some of their decisions would be considered serious security risks now (e.g. they intercept open() and record the name, and assume that its safe to reopen a file by the same name after migration), but it was an interesting system.

I think migrating cooperating processes would be fairly simple, and the big challenge is rather to decide on the right set of tradeoffs.

[1] https://chtc.cs.wisc.edu/doc/ckpt97.pdf

> the big challenge is rather to decide on the right set of tradeoffs

Agreed. That's a good way to sum it up.

Yeah, that would be very cool!

With a read-only operating system that is identical across machines (i.e. NixOS or Silverblue), you would only have to send the dirty pages, too!

I don’t see why not; over ten years ago the OpenVZ vm code had a way to rsync a container across the network; syncing everything; then only the pages that had changed since the start of sync; then the final pages that had changed in the last few seconds. There was a tiny delay to pause the container on the old and start on the new host; but I am sure that this could be reduced further.

I think CRIU can do that:

https://criu.org/

Reply on news.ycombinator.com