Home » Mailing lists » Devel » Userspace checkpoint/restart hack: cryo
| Userspace checkpoint/restart hack: cryo [message #29834] |
Fri, 25 April 2008 17:24  |
Dave Hansen
Messages: 240
Registered: October 2005
|
Senior Member |
|
|
A guy named Marc Vertes wrote this as a little demonstration of
checkpoint/restart. I've been using it to experiment with
checkpoint/restart. I thought it might be of some use as we move
subsystems to being helped by the kernel to checkpoint and restart.
It's ptrace-based, and stuck on i386 for now. It can probably be ported
elsewhere without too much trouble. It doesn't support *anything
fancy like multuiple tasks :). It has the advantage of being very
feature-bare, and I think it is pretty easy to hack on. Whatever c/r
support we add to the kernel could easily be added on and tested.
http://userweb.kernel.org/~daveh/cryo/cryo-001.tar.gz
Usage:
cr -p `pidof task` > checkpoint.cryo
cr -r < checkpoint.cryo
If anyone else has something simpler or easier to hack on, I'm all ears.
-- Dave
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Userspace checkpoint/restart hack: cryo [message #30859 is a reply to message #30001] |
Mon, 09 June 2008 13:04  |
serue
Messages: 750
Registered: February 2006
|
Senior Member |
|
|
Quoting Nadia Derbey (Nadia.Derbey@bull.net):
> Cedric Le Goater wrote:
> >
> >
> >>Looks like it has worked for me (msg1 creates 1000 msg queues, sleeps
> >>for a while and then removes the msg queues).
> >
> >
> > cool. which kernel are you using ?
> >
> > C.
> >
> >
>
> 2.6.25-mm1 (sorry for the late answer - plenty of days off in France in
> May).
>
> Regards,
> Nadia
I'm playing with features in cryo, and keeping a git tree at:
git://git.sr71.net/~hallyn/cryodev.git
It's meant to exploit the extras which are in the -lxc kernel at
lxc.sf.net. Current latest kernel patch is at
http://lxc.sourceforge.net/patches/2.6.26/2.6.26-rc2-mm1-lxc4/ This -lxc
tree contains, for instance, Nadia's next_id patches, exploitation for
setting ids for sysvipc and for tasks at fork, and updated ipc_setall
patches (also using next_id). The version of cryo in my git tree
exploits these. If you're root when you restart a task, it will clone a
new set of namespaces and recreate your sysvipc objects, and it will
reset your pids (even if you're not root if the pids are available).
Cryo is still rather touchy - I'm trying to track this down. Older
distros seem to actually have the most success (I'm told FC6 is somewhat
useful, while my FC8 kvm image is practically useless with cryo).
So if you want to play with it, please clone and do so, and send me any
patches you think should go in.
thanks,
-serge
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
|
| Re: Userspace checkpoint/restart hack: cryo [message #30868 is a reply to message #30859] |
Mon, 09 June 2008 15:02 |
Nadia Derbey
Messages: 114
Registered: January 2008
|
Senior Member |
|
|
Serge E. Hallyn wrote:
> Quoting Nadia Derbey (Nadia.Derbey@bull.net):
>
>>Cedric Le Goater wrote:
>>
>>>
>>>
>>>
>>>>Looks like it has worked for me (msg1 creates 1000 msg queues, sleeps
>>>>for a while and then removes the msg queues).
>>>
>>>
>>>cool. which kernel are you using ?
>>>
>>>C.
>>>
>>>
>>
>>2.6.25-mm1 (sorry for the late answer - plenty of days off in France in
>>May).
>>
>>Regards,
>>Nadia
>
>
> I'm playing with features in cryo, and keeping a git tree at:
>
> git://git.sr71.net/~hallyn/cryodev.git
>
> It's meant to exploit the extras which are in the -lxc kernel at
> lxc.sf.net. Current latest kernel patch is at
> http://lxc.sourceforge.net/patches/2.6.26/2.6.26-rc2-mm1-lxc4/ This -lxc
> tree contains, for instance, Nadia's next_id patches, exploitation for
> setting ids for sysvipc and for tasks at fork, and updated ipc_setall
> patches (also using next_id). The version of cryo in my git tree
> exploits these. If you're root when you restart a task, it will clone a
> new set of namespaces and recreate your sysvipc objects, and it will
> reset your pids (even if you're not root if the pids are available).
Serge,
I noticed that the sys_hijack() has disappeared from the lxc dev tree:
would you mind putting it back. I think it might be useful if we want to
start a task in a newly defined cgroup, checkpoint it and then try to
restart it. We will need to 'join' the restarted container to check if
everything has correctly be restarted. Or may be is there another way to
do that?
Regards,
Nadia
>
> Cryo is still rather touchy - I'm trying to track this down. Older
> distros seem to actually have the most success (I'm told FC6 is somewhat
> useful, while my FC8 kvm image is practically useless with cryo).
>
> So if you want to play with it, please clone and do so, and send me any
> patches you think should go in.
>
> thanks,
> -serge
> _______________________________________________
> Containers mailing list
> Containers@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/containers
>
>
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
|
| Re: Userspace checkpoint/restart hack: cryo [message #30871 is a reply to message #30868] |
Mon, 09 June 2008 15:23 |
serue
Messages: 750
Registered: February 2006
|
Senior Member |
|
|
Quoting Nadia Derbey (Nadia.Derbey@bull.net):
> Serge E. Hallyn wrote:
>> Quoting Nadia Derbey (Nadia.Derbey@bull.net):
>>
>>> Cedric Le Goater wrote:
>>>
>>>>
>>>>
>>>>
>>>>> Looks like it has worked for me (msg1 creates 1000 msg queues, sleeps
>>>>> for a while and then removes the msg queues).
>>>>
>>>>
>>>> cool. which kernel are you using ?
>>>>
>>>> C.
>>>>
>>>>
>>>
>>> 2.6.25-mm1 (sorry for the late answer - plenty of days off in France
>>> in May).
>>>
>>> Regards,
>>> Nadia
>>
>>
>> I'm playing with features in cryo, and keeping a git tree at:
>>
>> git://git.sr71.net/~hallyn/cryodev.git
>>
>> It's meant to exploit the extras which are in the -lxc kernel at
>> lxc.sf.net. Current latest kernel patch is at
>> http://lxc.sourceforge.net/patches/2.6.26/2.6.26-rc2-mm1-lxc4/ This -lxc
>> tree contains, for instance, Nadia's next_id patches, exploitation for
>> setting ids for sysvipc and for tasks at fork, and updated ipc_setall
>> patches (also using next_id). The version of cryo in my git tree
>> exploits these. If you're root when you restart a task, it will clone a
>> new set of namespaces and recreate your sysvipc objects, and it will
>> reset your pids (even if you're not root if the pids are available).
>
> Serge,
>
> I noticed that the sys_hijack() has disappeared from the lxc dev tree:
> would you mind putting it back. I think it might be useful if we want to
> start a task in a newly defined cgroup, checkpoint it and then try to
> restart it. We will need to 'join' the restarted container to check if
> everything has correctly be restarted. Or may be is there another way to
> do that?
Well it *could* be done similar to how cryo itself works, by ptracing
the destination task and making it fork a task which execve()s a process
to do the querying. But yuck.
Kathy, I'm sorry, I know I asked you to take sys_hijack() out. Could
you please put it back in? Preferably at the end of the queue, as I don't
want other patches having to be ported on top of it since its future is
very suspect... Let me know if you have trouble porting it, but it
should be pretty simple.
thanks,
-serge
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
|
| Re: Userspace checkpoint/restart hack: cryo [message #30926 is a reply to message #29834] |
Tue, 10 June 2008 18:17 |
serue
Messages: 750
Registered: February 2006
|
Senior Member |
|
|
Quoting kathys (kathys@ozlabs.au.ibm.com):
> Serge E. Hallyn wrote:
>> Quoting Nadia Derbey (Nadia.Derbey@bull.net):
>>
>>> Serge E. Hallyn wrote:
>>>
>>>> Quoting Nadia Derbey (Nadia.Derbey@bull.net):
>>>>
>>>>
>>>>> Cedric Le Goater wrote:
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>> Looks like it has worked for me (msg1 creates 1000 msg queues, sleeps
>>>>>>> for a while and then removes the msg queues).
>>>>>>>
>>>>>> cool. which kernel are you using ?
>>>>>>
>>>>>> C.
>>>>>>
>>>>>>
>>>>>>
>>>>> 2.6.25-mm1 (sorry for the late answer - plenty of days off in
>>>>> France in May).
>>>>>
>>>>> Regards,
>>>>> Nadia
>>>>>
>>>> I'm playing with features in cryo, and keeping a git tree at:
>>>>
>>>> git://git.sr71.net/~hallyn/cryodev.git
>>>>
>>>> It's meant to exploit the extras which are in the -lxc kernel at
>>>> lxc.sf.net. Current latest kernel patch is at
>>>> http://lxc.sourceforge.net/patches/2.6.26/2.6.26-rc2-mm1-lxc4/ This -lxc
>>>> tree contains, for instance, Nadia's next_id patches, exploitation for
>>>> setting ids for sysvipc and for tasks at fork, and updated ipc_setall
>>>> patches (also using next_id). The version of cryo in my git tree
>>>> exploits these. If you're root when you restart a task, it will clone a
>>>> new set of namespaces and recreate your sysvipc objects, and it will
>>>> reset your pids (even if you're not root if the pids are available).
>>>>
>>> Serge,
>>>
>>> I noticed that the sys_hijack() has disappeared from the lxc dev
>>> tree: would you mind putting it back. I think it might be useful if
>>> we want to start a task in a newly defined cgroup, checkpoint it and
>>> then try to restart it. We will need to 'join' the restarted
>>> container to check if everything has correctly be restarted. Or may
>>> be is there another way to do that?
>>>
>>
>> Well it *could* be done similar to how cryo itself works, by ptracing
>> the destination task and making it fork a task which execve()s a process
>> to do the querying. But yuck.
>>
>> Kathy, I'm sorry, I know I asked you to take sys_hijack() out. Could
>> you please put it back in? Preferably at the end of the queue, as I don't
>> want other patches having to be ported on top of it since its future is
>> very suspect... Let me know if you have trouble porting it, but it
>> should be pretty simple.
>>
> I added sys_hijack() (namespaces-introduce-sys_hijack.patch) back, with
> a little bit of massaging to get it to port properly (as Cedrics
> clone64-change-clone_flag-type-to-u64.patch changes unsigned long to
> u64) but was unable to compile. I received the following errors:
>
> /scratch/kathys/containers/kernel_trees/upstream/kernel/fork.c: In
> function 'do_fork_task':
> /scratch/kathys/containers/kernel_trees/upstream/kernel/fork.c:1342:
> warning: format '%1lx' expects type 'long unsigned int', but argument 3
> has type 'u64'
> /scratch/kathys/containers/kernel_trees/upstream/kernel/fork.c: At top
> level:
> /scratch/kathys/containers/kernel_trees/upstream/kernel/fork.c:1416:
> error: conflicting types for 'do_fork'
> /scratch/kathys/containers/kernel_trees/upstream/include/linux/sched.h:1868:
> error: previous declaration of 'do_fork' was here
Did you change the do_fork definition in sched.h?
-serge
> I changed the patch as follows so it would apply properly, but I can't
> work out why it breaks now, but not previously:
>
> Original patch from 2.6.26-rc2-mm1-lxc3:
> @@ -1307,13 +1313,8 @@ static int fork_traceflag(unsigned clone
> return 0;
> }
>
> -/*
> - * Ok, this is the main fork-routine.
> - *
> - * It copies the process, and if successful kick-starts
> - * it and waits for it to finish using the VM if required.
> - */
> -long do_fork(unsigned long clone_flags,
> +long do_fork_task(struct cgroup *cgroup,
> + unsigned long clone_flags,
> unsigned long stack_start,
> struct pt_regs *regs,
> unsigned long stack_size,
>
>
> Changed to:
>
> @@ -1308,13 +1314,8 @@ static int fork_traceflag(u64 clone_flag
> return 0;
> }
>
> -/*
> - * Ok, this is the main fork-routine.
> - *
> - * It copies the process, and if successful kick-starts
> - * it and waits for it to finish using the VM if required.
> - */
> -long do_fork(u64 clone_flags,
> +long do_fork_task(struct cgroup *cgroup,
> + u64 clone_flags,
> unsigned long stack_start,
> struct pt_regs *regs,
> unsigned long stack_size,
>
>
>
>> thanks,
>> -serge
>> _______________________________________________
>> Containers mailing list
>> Containers@lists.linux-foundation.org
>> https://lists.linux-foundation.org/mailman/listinfo/containers
>>
>>
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
|
| Re: Userspace checkpoint/restart hack: cryo [message #31178 is a reply to message #30926] |
Tue, 17 June 2008 05:48 |
kathys
Messages: 3
Registered: June 2008
|
Junior Member |
|
|
Serge E. Hallyn wrote:
> Quoting kathys (kathys@ozlabs.au.ibm.com):
>
>> Serge E. Hallyn wrote:
>>
>>> Quoting Nadia Derbey (Nadia.Derbey@bull.net):
>>>
>>>
>>>> Serge E. Hallyn wrote:
>>>>
>>>>
>>>>> Quoting Nadia Derbey (Nadia.Derbey@bull.net):
>>>>>
>>>>>
>>>>>
>>>>>> Cedric Le Goater wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Looks like it has worked for me (msg1 creates 1000 msg queues, sleeps
>>>>>>>> for a while and then removes the msg queues).
>>>>>>>>
>>>>>>>>
>>>>>>> cool. which kernel are you using ?
>>>>>>>
>>>>>>> C.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> 2.6.25-mm1 (sorry for the late answer - plenty of days off in
>>>>>> France in May).
>>>>>>
>>>>>> Regards,
>>>>>> Nadia
>>>>>>
>>>>>>
>>>>> I'm playing with features in cryo, and keeping a git tree at:
>>>>>
>>>>> git://git.sr71.net/~hallyn/cryodev.git
>>>>>
>>>>> It's meant to exploit the extras which are in the -lxc kernel at
>>>>> lxc.sf.net. Current latest kernel patch is at
>>>>> http://lxc.sourceforge.net/patches/2.6.26/2.6.26-rc2-mm1-lxc4/ This -lxc
>>>>> tree contains, for instance, Nadia's next_id patches, exploitation for
>>>>> setting ids for sysvipc and for tasks at fork, and updated ipc_setall
>>>>> patches (also using next_id). The version of cryo in my git tree
>>>>> exploits these. If you're root when you restart a task, it will clone a
>>>>> new set of namespaces and recreate your sysvipc objects, and it will
>>>>> reset your pids (even if you're not root if the pids are available).
>>>>>
>>>>>
>>>> Serge,
>>>>
>>>> I noticed that the sys_hijack() has disappeared from the lxc dev
>>>> tree: would you mind putting it back. I think it might be useful if
>>>> we want to start a task in a newly defined cgroup, checkpoint it and
>>>> then try to restart it. We will need to 'join' the restarted
>>>> container to check if everything has correctly be restarted. Or may
>>>> be is there another way to do that?
>>>>
>>>>
>>> Well it *could* be done similar to how cryo itself works, by ptracing
>>> the destination task and making it fork a task which execve()s a process
>>> to do the querying. But yuck.
>>>
>>> Kathy, I'm sorry, I know I asked you to take sys_hijack() out. Could
>>> you please put it back in? Preferably at the end of the queue, as I don't
>>> want other patches having to be ported on top of it since its future is
>>> very suspect... Let me know if you have trouble porting it, but it
>>> should be pretty simple.
>>>
>>>
>> I added sys_hijack() (namespaces-introduce-sys_hijack.patch) back, with
>> a little bit of massaging to get it to port properly (as Cedrics
>> clone64-change-clone_flag-type-to-u64.patch changes unsigned long to
>> u64) but was unable to compile. I received the following errors:
>>
>> /scratch/kathys/containers/kernel_trees/upstream/kernel/fork.c: In
>> function 'do_fork_task':
>> /scratch/kathys/containers/kernel_trees/upstream/kernel/fork.c:1342:
>> warning: format '%1lx' expects type 'long unsigned int', but argument 3
>> has type 'u64'
>> /scratch/kathys/containers/kernel_trees/upstream/kernel/fork.c: At top
>> level:
>> /scratch/kathys/containers/kernel_trees/upstream/kernel/fork.c:1416:
>> error: conflicting types for 'do_fork'
>>
>
>
>> /scratch/kathys/containers/kernel_trees/upstream/include/linux/sched.h:1868:
>> error: previous declaration of 'do_fork' was here
>>
>
> Did you change the do_fork definition in sched.h?
>
> -serge
>
>
I changed definition in sched.h to match do_fork in fork.c
>> I changed the patch as follows so it would apply properly, but I can't
>> work out why it breaks now, but not previously:
>>
>> Original patch from 2.6.26-rc2-mm1-lxc3:
>> @@ -1307,13 +1313,8 @@ static int fork_traceflag(unsigned clone
>> return 0;
>> }
>>
>> -/*
>> - * Ok, this is the main fork-routine.
>> - *
>> - * It copies the process, and if successful kick-starts
>> - * it and waits for it to finish using the VM if required.
>> - */
>> -long do_fork(unsigned long clone_flags,
>> +long do_fork_task(struct cgroup *cgroup,
>> + unsigned long clone_flags,
>> unsigned long stack_start,
>> struct pt_regs *regs,
>> unsigned long stack_size,
>>
>>
>> Changed to:
>>
>> @@ -1308,13 +1314,8 @@ static int fork_traceflag(u64 clone_flag
>> return 0;
>> }
>>
>> -/*
>> - * Ok, this is the main fork-routine.
>> - *
>> - * It copies the process, and if successful kick-starts
>> - * it and waits for it to finish using the VM if required.
>> - */
>> -long do_fork(u64 clone_flags,
>> +long do_fork_task(struct cgroup *cgroup,
>> + u64 clone_flags,
>> unsigned long stack_start,
>> struct pt_regs *regs,
>> unsigned long stack_size,
>>
>>
>>
>>
>>> thanks,
>>> -serge
>>> _______________________________________________
>>> Containers mailing list
>>> Containers@lists.linux-foundation.org
>>> https://lists.linux-foundation.org/mailman/listinfo/containers
>>>
>>>
>>>
>
>
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
|
Goto Forum:
Current Time: Tue Oct 03 09:45:13 GMT 2023
Total time taken to generate the page: 0.02369 seconds
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
