[CRIU] Live migration of LXC containers using Criu?

[Pavel Emelyanov]

On 06/05/2015 09:17 PM, Divjyot sethi wrote:
> I see -- thanks. Can you please let me know what change should I specifically make in
> the p.haul code to make this work?

Removing the p_haul_cgroup.py (and fixing all the stuff linking to it)
and adding "manage_cgroups" option to criu_opts on dump and restore.

> Asking this as I am trying to replicate your setup where you were able to live migrate
> OpenVZ containers on fedora (I am following: 
> https://github.com/xemul/p.haul/wiki/Live-migrating-OVZ-mainstream-container). 
> Thanks for the help!
> 
> On Fri, Jun 5, 2015 at 1:47 AM, Pavel Emelyanov <xemul at parallels.com <mailto:xemul at parallels.com>> wrote:
> 
>     On 06/05/2015 11:20 AM, Divjyot sethi wrote:
>     > Ok cool - thanks. Let me add --manage-cgroups in my p.haul-service at the point where it calls
>     > restore. That would be sufficient? Or, since I am also using ovz driver - do I need to do something
>     > for that as well?
> 
>     Yes, since the cgroups management is off-loaded to CRIU, then the whole p_haul_cgroup.py should
>     be removed (it used to be the code doing this).
> 
>     > On Fri, Jun 5, 2015 at 1:05 AM, Pavel Emelyanov <xemul at parallels.com <mailto:xemul at parallels.com> <mailto:xemul at parallels.com <mailto:xemul at parallels.com>>> wrote:
>     >
>     >     On 06/05/2015 01:02 AM, Divjyot sethi wrote:
>     >     > Thanks -- was able to fix it. :) Now another problem. Apparently restore doesnt work on desitination I get an error  saying:
>     >     > 1: Error (cgroup.c:907): cg: Can't move into systemd//user.slice/user-1000.slice/session-3.scope/tasks (-1/-1): No such file or directory.
>     >
>     >     Ah. This is because p.haul doesn't feed the --manage-cgroups option into criu on restore. And, if you're using
>     >     the ovz haul driver, tries to mess with cgroups itself, need do rip this piece from p.haul.
>     >
>     >     > Error (cr-restore.c 1896): Restoring FAILED.
>     >     >
>     >     > Seems that this error was in a prior mailing list where you asked to list the cgroups. I did that and it seems that
>     >     > session-3.scop doesnt exist in user-1000.slice at destination (exists at source). Is there some way of creating this? The discussion
>     >     > in the prioir mailing list doesnt seem to list a solution to this problem...
>     >     >
>     >     > Thanks,
>     >     > Divjyot
>     >     >
>     >     > On Thu, Jun 4, 2015 at 2:36 AM, Pavel Emelyanov <xemul at parallels.com <mailto:xemul at parallels.com> <mailto:xemul at parallels.com <mailto:xemul at parallels.com>> <mailto:xemul at parallels.com <mailto:xemul at parallels.com> <mailto:xemul at parallels.com <mailto:xemul at parallels.com>>>> wrote:
>     >     >
>     >     >     On 06/04/2015 04:50 AM, Kir Kolyshkin wrote:
>     >     >     >
>     >     >     >
>     >     >     > On 06/03/2015 06:45 PM, Divjyot sethi wrote:
>     >     >     >> Hey Pavel,
>     >     >     >> After a bit of a hiatus, I finally got around to istalling everything on my machines and am now trying
>     >     >     >> to live migrate OpenVZ containers running CentOS with p.haul. I however get an error at CRIU dump stage
>     >     >     >> -- log file says "Error (sk-unix.c:222): Unix socket 0x6893 without peer 0xc5b". Any thoughts on this issue?
>     >     >     >
>     >     >     > The message essentially means that there is a UNIX socket that has one end inside the container and the
>     >     >     > other end out of it. Like, a container is running mysql and someone who's not inside that CT is connected
>     >     >     > to it via a UNIX socket. CRIU warns you that if you will checkpoint a process at one end of such a socket,
>     >     >     > a process at the other end might get disappointed. In case you know what you are doing, you can add
>     >     >     > --ext-unix-sk to criu commandline to allow checkpointing of such processes.
>     >     >
>     >     >     Yup. These are connections to the outer world, the --ext-unix-sk should help, unless the
>     >     >     connection is SOCK_STREAM. In the latter case you'll have to stop the process that has one.
>     >     >
>     >     >     > This is as much as I can tell without looking into speciifics.
>     >     >
>     >     >     -- Pavel
>     >     >
>     >     >
>     >
>     >
> 
>