[CRIU] CRIU LXC Container Live Migration Concerns

[Deepak Vij (A)]

Thanks James for your response. It all makes sense except for the following comment you made.

=======================
I don't quite see why you think the docker or OpenVZ templates wouldn't work inter-cloud.  We think they do.
=======================

I think you misinterpreted my note on this. What I meant was the traditional hypervisor based virtualization is not a viable option. I definitely think that LXC/OpenVZ based Container is the right unit-of-work for portability across clouds. We are planning to make major headway on this going forward as part of the IEEE P2302 Intercloud standardization & testbed effort. That is the reason I have been asking all these questions so far.

Another thing was brought to my attention by one of my IEEE Intercloud working group member. It seems you folks at Parallels/OpenVZ support reboot-less updates (for example Ksplice like object level security/performance kernel patches etc.). Based on my understanding, at the time of such an update, all running containers are suspended in server's memory and subsequently seamlessly resumed rather than shut down & started again in order to reduce the downtime and service outage for end users.

My question is, as part of CRIU, are you folks doing the same for LXC containers as well? Thanks.

Regards,
Deepak K. Vij

-----Original Message-----
From: James Bottomley [mailto:jbottomley at parallels.com] 
Sent: Wednesday, April 30, 2014 3:49 PM
To: Deepak Vij (A)
Cc: Pavel Emelianov; criu at openvz.org
Subject: Re: [CRIU] CRIU LXC Container Live Migration Concerns

On Tue, 2014-04-29 at 17:45 +0000, Deepak Vij (A) wrote:
> Thanks Pavel & James for your detail response to my earlier email. I
> appreciate it. 
> 
> Based on our back-and-forth discussion so far, I am fully convinced
> that you folks, as part of the CRIU "Live Migration" effort, are
> definitely on the right track. I am convinced that "Live Migration"
> design which you have put forward using Kernel level API should work.
> 
> Although, the concern I had was at a higher LXC/Container level
> itself. You also concur based on the following response from Pavel.
> 
> ====================================
> Hm... Good question -- what if after migration all the system
> libraries have changed. Yes, this _is_ a problem. E.g. I've seen that
> applications crash after migration between two nodes with glibcs of
> equal versions, but "fixed" by prelink in two different ways.
> ====================================
> 
> Now, first and foremost, I am also a big proponent of LXC-container
> and do want this to succeed as this is the right unit-of-work from
> portability standpoint versus traditional heavyweight hypervisor based
> unit-of-work VM model.

Just to be clear, we at Parallels and OpenVZ aren't really LXC people.
There are LXC people who hang out on this list, but we're mostly
concerned about OpenVZ which uses templates to solve this problem in a
mechanism similar to Docker.  In our commercial product, we also do
template migration, which means we never really have to worry about
this.

>  To that regards, Docker folks are trying to solve this problem by
> enabling LXC-Container capabilities across various flavors of Linux
> based operating systems and dependency issues etc. However, there
> needs to be more work done so that Docker like abstraction can provide
> OVF (Open Virtualization Format for hypervisor based VMs) like
> seamless compatibility across various LXC-Containers environment,
> supporting all kinds of dependencies, injections etc. 

My impression is that if you read the documents, docker thinks they've
got this pretty much solved.

https://www.docker.io/the_whole_story/

The overlay diffs look quite compelling.  However, you probably need to
take it up with them.  Right at the moment, we've barely got to the
stage where we can migrate a docker container.

> This is something very near and dear to my heart from IEEE Intercloud
> standards development perspectives. As part of the IEEE Intercloud
> standardization effort, so far we have made a good progress on the
> Interoperability standards across clouds (using Ontology definitions,
> Trust Management, etc). However, the portability issue we have kind of
> shoved it under the rug as traditional VM-Mobility like portability is
> not really viable across geographically dispersed cloud computing
> environment.

I don't quite see why you think the docker or OpenVZ templates wouldn't
work inter-cloud.  We think they do.

> This is a great opportunity for us to define standardization around
> lightweight container based unit-of-work, something like OVF, to make
> this whole thing work. I am not sure, who to contact to this regards.
> Maybe we should loop in Docker folks into all this as well. Or maybe
> they are already working towards that, I am not sure.

Docker doesn't really do email per se, the closest is probably google
groups.  This is how you contact them:

https://www.docker.io/community/

James