CRIU migration: where are cgroup and lxc ?

Purpose:

If we get rid of cgroup and lxc when we do dump through criu, it is good for us to make migration successfully


LXC:

CRIU itself doesn’t dump lxc(container) unless using lxc-checkpoint tool. So by default, lxc is not considered by CRIU.

Cgroups:

If we unload or don’t use cgroup functionality, a process won’t have information about cgroup. So when we do checkpoint in bash environment, the checkpoint image file cgroup.img should be empty. It is true, in fact.

But when we do dump in ssh environment, and the checkpointed process is running in bash, cgroup.img is not empty, it has the information about bash in which the checkpointed process is running.

And here is the information about the bash:

2:name=systemd:/user/1000.user/c2.session

while cat /proc/self/cgroup in the ssh in which criu is running

2:name=systemd:/user/1000.user/22.session

So it is strange, we don’t enable cgroup functionality, why the cgroup.img is 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 which is bash. So we can do checkpoint/restore successfully.

But now criu is in ssh, while the checkpointed process is in bash. Just like:

If they are both in bash, we can think that they belongs to one common user, so criu can ignore the information about the user, such as session id. But now one is in bash, while the other is in ssh, just equivalent to two different users. So criu which is in ssh shouldn’t ignore where the checkpointed process comes from. So criu will write down the bash information in cgroup.img.

( 译文:如果都在bash中,可以理解为从属于同一个用户,所以可以忽略这个用户的标识信息。但现在一个在bash,而另一个在ssh,相当于两个不同用户,位于ssh的criu在checkpoint时就要点出被checkpoint的process来自何方,这也就是cgroup.img出现bash信息的原因。)


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 that 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) will succeed, even though the bash session information between bug02 and bug03 is different.

时间: 2024-10-24 17:08:23

CRIU migration: where are cgroup and lxc ?的相关文章

畅谈Docker底层技术-LXC与Cgroup

#Docker LXC及Cgroup    docker最为为LXC+AUFS组合,其中LXC负责资源管理,AUFS负责镜像管理:而LXC包括cgroup,namespace,chroot等组件 并通过cgroup资源管理     那么,从资源管理的角度来看,Docker,Lxc,Cgroup三者的关系是怎样的呢? cgroup是在底层落实资源管理,LXC在cgroup上面封装了一层,随后,docker有在LXC封装了一层:    Cgroup其实就是linux提供的一种限制,记录,隔离进程组所

Cgroup 用法(转帖)

Cgroup 用法 13 January 2014 介绍docker的的过程中,提到lxc利用cgroup来提供资源的限额和控制,本文主要介绍cgroup的用法和操作命令,主要内容来自 [1]https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/ch01.html [2]https://www.kernel.org/doc/Docum

Ubuntu Docker介绍与安装使用

什么是Docker? docker是一个开源的应用容器引擎,系统级的轻量虚拟化技术. 应用程序的自动化部署解决方案,能够迅速创建一个容器,并在容器上部署和运行应用程序,并通过配置文件可以轻松实现应用程序的自动化安装.部署和升级. docker使用Go语言编写,用cgroup实现资源隔离,容器技术采用LXC,lxc是一种内核虚拟化技术,提供轻量级的虚拟化.lxc是linux内核一个特性,它允许进程或进程组运行在一块独立的空间,并能对其控制.并实现容器与宿主机资源共享. 优点? 1.轻量级资源,容器

从Storm学习集群管理

简介 Storm是当前最流行的分布式实时计算平台,使用场景是根据Storm定义的接口规范编写一个实时处理流,然后提交到Storm平台处理,Storm平台解析该处理流,使其并行.分布式地在集群中运行,并附带相应的状态监控.本文主要描述Storm的集群管理这块的内容,处理流的相关接口逻辑规范不作涉及. Storm集群监控管理的目标是管理和监控用户提交的处理流作业(类似于Hadoop监控管理mr-job). Storm系统架构 Storm遵循经典的master-slave架构,nimbus节点即为ma

Cgroups控制cpu,内存,io示例

Cgroups是control groups的缩写,最初由Google工程师提出,后来编进linux内核. Cgroups是实现IaaS虚拟化(kvm.lxc等),PaaS容器沙箱(Docker等)的资源管理控制部分的底层基础. 百度私有PaaS云就是使用轻量的cgoups做的应用之间的隔离,以下是关于百度架构师许立强,对于虚拟机VM,应用沙盒,cgroups技术选型的理解 本文用脚本运行示例进程,来验证Cgroups关于cpu.内存.io这三部分的隔离效果. 测试机器:CentOS relea

docker使用详解

docker是什么?docker不是虚拟机,是容器. 虚拟机可以理解为大房子里面的套间房,套间里面有客厅/厕所/厨房等,其他套间的使用人不能使用别人的厕所和厨房等,各自不知道各自房间里面有什么,就连房主(母机)也不知道里面有什么. 容器可以理解为大房子里面的独立房间,客厅/厕所/厨房等是公用的,所有房间的使用人都有权使用它们这些共有资源,但是各自不知道各自房间里面有什么,不过房主(母机)会知道他们占用了什么资源. Docker是基于cgroup和lxc开发的容器工具. cgroup原本是用来分割

7个变革DevOps的工具

7个变革DevOps的工具 1. 简介 随着公司业务的不断迅速增长,使得管理复杂的IT基础设施需求变得更为艰难.解决应对这一复杂变幻的挑战的最佳方法是让开发团队和运维团队紧密协作,实现灵活应对.拥有一个DevOps专家团队可以实现在最少时间服务中断的情况下实现IT基础设施的动态伸缩. DevOps团队执行各种任务, 如: 新虚拟机的配置 配置网络设备和服务器 应用程序部署 收集和聚合的日志 性能监视服务.网络和应用程序 报警和自动修复的问题 服务器和服务可用性监控 如果不使用正确的工具集来执行这

引擎下的PaaS, 第一章: kernel 命名空间

使事情简单化背后是非常繁重的工作.在dotCloud,我们将非常复杂的事务(例如部署和扩展web应用)打包进一个尽可能简单的环境中.但是我们在这样的环境中,如何进行工作呢?从kernel-level的虚拟化到监控,从高吞吐量忘了路由到分布式锁,从EBS处理到每分钟手机数百万的系统数据...如同一些人提到过的,弹性调度一个PaaS 就像是系统工程师的迪斯尼乐园. 本文是第一期文章,关于PaaS的架构和内部进行探索,并对dotCloud做更详细的说明.在第一段中,我们将介绍namespace,dot

Docker——入门

虚拟化最大区别:虚拟化技术元件,资源申请调度到其他硬件服务器: Docker是一个开源得应用容器引擎,让开发者可以打包他们得应用以及依赖包到一共可移植得容器中,然后发布到任何流行得linux机器上,也可以实现虚拟化. 容器之间互不影响,不需要任何语言 目的就是实现轻量级得操作系统虚拟化解决方案. LXC负责资源管理 AUFS负责镜像管理得 LXC包括:cgroup.namespace.chroot 并通过cgroup进行资源管理 分三层: 最底层 cgroup -->LXC对croup进行封装