Purpose:
If we get rid of cgroup and lxc when we do dump through Criu, it's good for us to make migration successfully
LXC:
Criu itself doesn ' t dump lxc (container) unless using Lxc-checkpoint tool. So by default, Lxc are not considered by Criu.
Cgroups:
If we unload or don ' t use Cgroup functionality, a process won ' t has information about Cgroup. The checkpoint in bash environment, the checkpoint image file cgroup.img should is empty. It's true, in fact.
But if we do a dump in SSH environment, and the checkpointed process was running in bash, cgroup.img was not empty, it had t He information about bash in which the checkpointed process is running.
And here are the information about the bash:
2:name=systemd:/user/1000.user/c2.session
While cat/proc/self/cgroup in the SSH on which Criu is running
2:name=systemd:/user/1000.user/22.session
So it's strange, we don ' t enable Cgroup functionality, why the cgroup.img was not empty? Just because we use Ciru in SSH environment?
Yes.
First, let's think so. If We run Criu and the checkpointed process both in bash, we should use–shell-job to ignore the "leaked" session leader W Hich is bash. So we can do checkpoint/restore successfully.
But now Criu was in SSH and while the checkpointed process was in bash. Just like:
If They is both in bash, we can think this they belongs to one common user, so Criu can ignore the information about the User, such as session ID. But now one was in bash and the other was in SSH, and just equivalent to different users. So Criu which are in ssh shouldn ' t ignore where the checkpointed process comes from. So Criu would write down the bash information in cgroup.img.
If all in bash can be understood to belong to the same user, you can ignore the user's identity information. But now one is in bash, and the other in SSH, equivalent to two different users, the SSH Criu at checkpoint point out where the checkpoint process came from, which is why the bash message is cgroup.img. )
Conclusion:
On one server (called bug03), we run Criu and the checkpointed process both in bash environment. And then Lxc and Crgoup won ' t be considered. And the cgroup.img is empty, which means this criu ignores the information about bash session. In one word, the checkpoint is pure.
In such theory, the miration from bug03 to BUG02 (the destination node) would succeed, even though the bash session info Rmation between Bug02 and Bug03 is different.
Criu Migration:where is Cgroup and LXC?