criu VS kubevirt

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.

First, download virtctl for ARM: https://github.com/kubevirt/kubevirt/releases/tag/v1.1.0-alpha.0

The full list of changes can be found in the Release notes. There are performance and scalability benchmarks published for the v1.0 release.

If you're happy with k8s and longhorn, why add Proxmox as another layer underneath? Consider kubevirt ?

Have you looked at http://kubevirt.io/ ?

If the answer to "how do you run VMs" is "Kubernetes does it" then its about https://kubevirt.io/

We are even using Docker Hub to store and distribute VM images...

https://github.com/kubevirt/kubevirt/blob/main/containerimag...

Docker Desktop runs dockerd in a Linux VM with Apple's hypervisor framework. You can also run containers in a Linux VM with Parallels or VMware Fusion hypervisors. But you can't run VMs inside those VMs as it stands today. This works fine on Intel Macs which means you can't experiment and use KVM - one of the killer features of Linux and things like https://kubevirt.io/

Proxmox VE can run VMs and LXC containers (see my comment below on LXC). Kubernetes can run OCI containers, but there's also KubeVirt for running VMs.

Another option would be something like KubeVirt but that is a different use case where you are actually running a VM in a container for hard-to-containerize workloads.