[CRIU] CRIU LXC Container Live Migration Concerns
James Bottomley
jbottomley at parallels.com
Wed Apr 30 15:48:35 PDT 2014
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
More information about the CRIU
mailing list