containers VS criu

Checkpoint/Restore I feel is a bigger concept than just saving state. At the zeroth level it's a system that can correctly stop and serialize a running process (as criu https://github.com/checkpoint-restore/criu has shown is a huge pain in the ass to still not be perfect) in a way that can initiated from within the process itself.

The 1st level more-work-but-easier way to do this is to build or use a heavily constrained VM/language you run from within your main application that doesn't allow for most of the hard problems to even exist.

I can't find any ready-made tools to do this that I wouldn't consider an endeavor.

That being said the Checkpoint Restore In Userspace project has been around for a number of years and is the closest thing to what you are talking about: taking a linux process on one machine and moving it to another. It is messy but can be done in some cases. There are folks looking at how to integrate CRIU with k8s but it’s all research at this point.

I would love to make more use of CRIU. E.g. I considered to use CRIU for my Python preloaded logic (https://github.com/albertz/python-preloaded). Unfortunately, at that point in time, CRIU must be used with root access, which was not an option. However, I see that the PR was merged now, so maybe it works now? (https://github.com/checkpoint-restore/criu/pull/1930)

There is also DMTCP (https://github.com/dmtcp/dmtcp/) but this might have other problems for my use case.

My solution was to use a fork server instead, which works almost equally well. There are not really much downsides with this approach. And this is actually quite simple, and also quite cross-platform (except Windows).

CRIU currently needs root access for dump/restore. However, there is ongoing work to support a non-root option in https://github.com/checkpoint-restore/criu/pull/1930.

There have been multiple checkpointing attempts over the years. Criu is the only one I know of that's still kicking. That's probably your best and only bet.