* Re: Containers Digest, Vol 24, Issue 82 [not found] ` <mailman.318.1216822966.8462.containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org> @ 2008-07-23 23:17 ` Peter Dolding [not found] ` <e7d8f83e0807231617y17ba889drf80c3d8994be4e73-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 3+ messages in thread From: Peter Dolding @ 2008-07-23 23:17 UTC (permalink / raw) To: dlezcano-NmTC/0ZBporQT0dZR+AlfA Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA > Daniel Lezcano <dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org> writes: > * What are the problems that the linux community can solve with the > checkpoint/restart ? > > EB : Better to add a little CR functionnality into the kernel itself > and add more after. > > DLu : Problem with kernel version > > OL : Compatibility with intermediate kernel version should be possible > with userspace conversion tools Please look at BSD Jails and Solaris Branded Zones. Both provide virtual of system calls. Its a major reason why BSD can just change there syscalls at will and still run old applications. So really its another container in its own right. Inside this container system calls are fake. Removing system call dependency from containers. Both allow virtual syscalls to be done in user space. It ends this problem of worrying about kernel version. Do we have the system call container ok we fine. Slower if we have to use it but fine to get around these issues. > DLu : Non sequential file for checkpoint statefile is a challenge > > OL : yes, but possible and useful for compression/encryption > > We showed that there are five steps to realize a checkpoint: > > 1 - Pre-dump > 2 - Freeze > 3 - Dump > 4 - Resume/kill > 5 - Post-dump > > At this point we state we want create a proof of concept and > checkpoint/restart the simplest application. > > We will add iteratively more and more kernel resources. > > Process hierarchy created from kernel or userspace ? > > OL : Seems better to send a chunk of data to kernel and that restores > the processes hierarchy > PE : Agreed > OL : We should be able to checkpoint from inside the container, keep > that in mind for later. > > => we need a syscall or a ioctl > > The first items to address before implementing the Checkpoint are: > 1 - Make a container object (the context) > 2 - Freeze the container (extend cgroup freezer ?) > 3 - syscall | ioctl > > First step: > * simplest application : A single process, without any file, no > checkpoint of text file (same file system for restart), no signals, no > syscall in the application, no ipc/no msgq, no network > > Second step: > * multiple processes + zombie state > > Third step: > * files, pipe, signals, socketpair ? > > This proof of concept must came with a documentation describing what is > supported, what is not supported and what we plan to do. > Missing critical Step 4. How to deal with processes like games or virus scanners using hardware assist or cups half way threw printing or other services half way threw doing something to a external device who state is going to change. That cannot be Frosen because the state in those devices will be lost. Even if there state could be saved you might be unfreezing on a container without them. Are the told to the user on freese and have to be terminated. Are the told to user on freese with the users with a option to go past and user on unfreese has the option to have those applications terminated to allow clean restart. Of course the hard bit is going to be detecting them all. There will always be the odd things. Container freesing and unfreesing could be aligned with the kernel level hibernate. One system does them both stable. Peter Dolding ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <e7d8f83e0807231617y17ba889drf80c3d8994be4e73-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Containers Digest, Vol 24, Issue 82 [not found] ` <e7d8f83e0807231617y17ba889drf80c3d8994be4e73-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2008-07-24 18:38 ` Oren Laadan [not found] ` <4888CC3A.50302-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> 0 siblings, 1 reply; 3+ messages in thread From: Oren Laadan @ 2008-07-24 18:38 UTC (permalink / raw) To: Peter Dolding Cc: dlezcano-NmTC/0ZBporQT0dZR+AlfA, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA Peter Dolding wrote: >> Daniel Lezcano <dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org> writes: >> * What are the problems that the linux community can solve with the >> checkpoint/restart ? >> >> EB : Better to add a little CR functionnality into the kernel itself >> and add more after. >> >> DLu : Problem with kernel version >> >> OL : Compatibility with intermediate kernel version should be possible >> with userspace conversion tools > > Please look at BSD Jails and Solaris Branded Zones. Both provide > virtual of system calls. Compatibility in the context above refers to ensuring that the restart code of a newer kernel will be able to read the checkpoint image taken by an older kernel. One way to do it is to include glue layers in the kernel; the solution we proposed was to convert the image in user space, if necessary. > > Its a major reason why BSD can just change there syscalls at will and > still run old applications. So really its another container in its > own right. Inside this container system calls are fake. Removing > system call dependency from containers. Both allow virtual syscalls > to be done in user space. It ends this problem of worrying about > kernel version. Do we have the system call container ok we fine. > Slower if we have to use it but fine to get around these issues. > >> DLu : Non sequential file for checkpoint statefile is a challenge >> >> OL : yes, but possible and useful for compression/encryption >> >> We showed that there are five steps to realize a checkpoint: >> >> 1 - Pre-dump >> 2 - Freeze >> 3 - Dump >> 4 - Resume/kill >> 5 - Post-dump >> >> At this point we state we want create a proof of concept and >> checkpoint/restart the simplest application. >> >> We will add iteratively more and more kernel resources. >> >> Process hierarchy created from kernel or userspace ? >> >> OL : Seems better to send a chunk of data to kernel and that restores >> the processes hierarchy >> PE : Agreed >> OL : We should be able to checkpoint from inside the container, keep >> that in mind for later. >> >> => we need a syscall or a ioctl >> >> The first items to address before implementing the Checkpoint are: >> 1 - Make a container object (the context) >> 2 - Freeze the container (extend cgroup freezer ?) >> 3 - syscall | ioctl >> >> First step: >> * simplest application : A single process, without any file, no >> checkpoint of text file (same file system for restart), no signals, no >> syscall in the application, no ipc/no msgq, no network >> >> Second step: >> * multiple processes + zombie state >> >> Third step: >> * files, pipe, signals, socketpair ? >> >> This proof of concept must came with a documentation describing what is >> supported, what is not supported and what we plan to do. >> > Missing critical Step 4. How to deal with processes like games or > virus scanners using hardware assist or cups half way threw printing > or other services half way threw doing something to a external device > who state is going to change. That cannot be Frosen because the > state in those devices will be lost. Even if there state could be > saved you might be unfreezing on a container without them. If they are using hardware that isn't (and cannot be) virtualized, they cannot be migrated to another machine. If they communicate with CUPS, then either the CUPS server lives within the same container, in which case it moves with the container; or they otherwise must communicate with the server via the network, in which case the network connections will be migrated with the container (and the application) as well. > Are the told to the user on freese and have to be terminated. > > Are the told to user on freese with the users with a option to go > past and user on unfreese has the option to have those applications > terminated to allow clean restart. > > Of course the hard bit is going to be detecting them all. > > There will always be the odd things. Container freesing and > unfreesing could be aligned with the kernel level hibernate. One > system does them both stable. > > Peter Dolding > _______________________________________________ > Containers mailing list > Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org > https://lists.linux-foundation.org/mailman/listinfo/containers ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <4888CC3A.50302-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>]
* Re: Containers Digest, Vol 24, Issue 82 [not found] ` <4888CC3A.50302-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> @ 2008-07-25 2:51 ` Peter Dolding 0 siblings, 0 replies; 3+ messages in thread From: Peter Dolding @ 2008-07-25 2:51 UTC (permalink / raw) To: Oren Laadan Cc: dlezcano-NmTC/0ZBporQT0dZR+AlfA, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA On Fri, Jul 25, 2008 at 4:38 AM, Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> wrote: > > > Peter Dolding wrote: >>> >>> Daniel Lezcano <dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org> writes: >>> * What are the problems that the linux community can solve with the >>> checkpoint/restart ? >>> >>> EB : Better to add a little CR functionnality into the kernel >>> itself >>> and add more after. >>> >>> DLu : Problem with kernel version >>> >>> OL : Compatibility with intermediate kernel version should be >>> possible >>> with userspace conversion tools >> >> Please look at BSD Jails and Solaris Branded Zones. Both provide >> virtual of system calls. > > Compatibility in the context above refers to ensuring that the restart code > of a newer kernel will be able to read the checkpoint image taken by an > older > kernel. One way to do it is to include glue layers in the kernel; the > solution > we proposed was to convert the image in user space, if necessary. > >> >> Its a major reason why BSD can just change there syscalls at will and >> still run old applications. So really its another container in its >> own right. Inside this container system calls are fake. Removing >> system call dependency from containers. Both allow virtual syscalls >> to be done in user space. It ends this problem of worrying about >> kernel version. Do we have the system call container ok we fine. >> Slower if we have to use it but fine to get around these issues. >> >>> DLu : Non sequential file for checkpoint statefile is a challenge >>> >>> OL : yes, but possible and useful for compression/encryption >>> >>> We showed that there are five steps to realize a checkpoint: >>> >>> 1 - Pre-dump >>> 2 - Freeze >>> 3 - Dump >>> 4 - Resume/kill >>> 5 - Post-dump >>> >>> At this point we state we want create a proof of concept and >>> checkpoint/restart the simplest application. >>> >>> We will add iteratively more and more kernel resources. >>> >>> Process hierarchy created from kernel or userspace ? >>> >>> OL : Seems better to send a chunk of data to kernel and that >>> restores >>> the processes hierarchy >>> PE : Agreed >>> OL : We should be able to checkpoint from inside the container, >>> keep >>> that in mind for later. >>> >>> => we need a syscall or a ioctl >>> >>> The first items to address before implementing the Checkpoint are: >>> 1 - Make a container object (the context) >>> 2 - Freeze the container (extend cgroup freezer ?) >>> 3 - syscall | ioctl >>> >>> First step: >>> * simplest application : A single process, without any >>> file, no >>> checkpoint of text file (same file system for restart), no signals, no >>> syscall in the application, no ipc/no msgq, no network >>> >>> Second step: >>> * multiple processes + zombie state >>> >>> Third step: >>> * files, pipe, signals, socketpair ? >>> >>> This proof of concept must came with a documentation describing >>> what is >>> supported, what is not supported and what we plan to do. >>> >> Missing critical Step 4. How to deal with processes like games or >> virus scanners using hardware assist or cups half way threw printing >> or other services half way threw doing something to a external device >> who state is going to change. That cannot be Frosen because the >> state in those devices will be lost. Even if there state could be >> saved you might be unfreezing on a container without them. > > If they are using hardware that isn't (and cannot be) virtualized, they > cannot > be migrated to another machine. > > If they communicate with CUPS, then either the CUPS server lives within the > same container, in which case it moves with the container; or they otherwise > must communicate with the server via the network, in which case the network > connections will be migrated with the container (and the application) as > well. > I am talking about a mixed container. Some of the applications in there can be migrated. But like a cups server talking to a usb printer that is not going to be there after migration. Game running on local gpu that is not going to be there after migration. Ok they are not moveable under your current model. Lets say for one secound they were container aware. Like vitalisation aware. You inform cups that X printer is being disconnected to end chatter to printer cleanly so printer does not need up jack hamming it carage into the side of its case and damaging itself. After sorted out cpus is now migration ready where it was not before. If done right you could even connect the printer back after migration is done. Allows manual moving of hardware that is not network connected. 3d applications aware that they could be moved could be provided with away of resetting up there stuff in the video card after migration also become video card independent. Ie like a game save and restore. That save and restore in game play is normally 100 percent video card neutral. There are other ways around this issue that don't include virtual. Ok not as cpu effective but its the difference between not being able to move something and can. A system that applications could flag that they are tied to something and can be informed to let go before migration and then reconnect up after migration reduces how much you need to virtual. Even being able to tag applications that cannot be migrated to inform user would be handy. It all about expanding migration options to the point that nothing is imposable. Just some things will take longer to come back on the other side of the migration. Same kind of extensions would help with Linux Suspend. For games and 3d software it could be as simple as programs providing a call that goes threw the programs data creating a save file that the program can restore back to its current state on a different video card. Memory and file operations only. Peter Dolding ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-07-25 2:51 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <mailman.318.1216822966.8462.containers@lists.linux-foundation.org>
[not found] ` <mailman.318.1216822966.8462.containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
2008-07-23 23:17 ` Containers Digest, Vol 24, Issue 82 Peter Dolding
[not found] ` <e7d8f83e0807231617y17ba889drf80c3d8994be4e73-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-24 18:38 ` Oren Laadan
[not found] ` <4888CC3A.50302-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-07-25 2:51 ` Peter Dolding
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox