[CRIU] CRIU LXC Container Live Migration Concerns

[Pavel Emelyanov]

On 04/26/2014 04:51 AM, Deepak Vij (A) wrote:
> Hi Pavel, let me quickly introduce myself. I am a researcher at FutureWei research lab based in Santa Clara. 

Nice to meet you.

> We have been looking at the LXC Containers/Docker as viable lightweight virtualization unit-of-work versus
> traditional hypervisor based virtualization. From portability of virtual machine perspectives, this is a no
> brainer. However, one of the concerns we have is due to Kernel incompatibility at the destination machine at
> the time of live migration of LXC container possibly using CRIU. For example, while doing the live
> “application process” migration embedded within the container what if someone applies a security patch on
> the destination machine that changes the underlying Kernel. This can possibly break the restore step as
> part of the overall checkpoint/restore process.

This is one of the main CRIU use cases -- evacuating containers/applications from one
node to another, potentially containing security/stability/performance updates. So I
would say that if this happens, this is a BUG, rather than expected behavior.

What CRIU does is uses only public kernel APIs to dump and restore process' state. Thus,
if we find a patch that, after applying to kernel, breaks applications behavior -- we
should report this to kernel people as "compatibility breakage". Moreover, what CRIU
dumps (and restores) is the state of the kernel objects, that can be seen via mentioned
APIs, thus this cannot change from kernel to kernel as well.


I can also share two practical experiences I have.

The first is Parallels' implementation of checkpoint/restore in 2.6.9, 2.6.18 and 2.6.32
kernels. We've been able to live migrate containers from 2.6.9 even to 2.6.32 without
any problems.

The 2nd one is about criu. I manually tried to live migrate apps from 3.11 to 3.13 and
things went smoothly every time.

> In contrast to this, hypervisor based virtualization does not have this problem as the whole OS is included
> in the VM itself.
> 
>  
> 
> The scenario I mentioned above is quite common as applying security patches etc. is a common practice. This
> seems to be our biggest concern.
> 
> I would really appreciate if you could throw some light into this. Thanks in advance.

You're welcome. Feel free to ask more if the above answer is not complete.

Thanks,
Pavel