[Devel] Re: kernel based checkpoint/restart: about X windows application checkpoint and restart support.

[Oren Laadan]

Matt Helsley wrote:
> On Wed, Oct 28, 2009 at 10:51:32AM +0800, Will Huang wrote:
>> Dear All,
>>
>>          Did the Kernel based checkpoint/restart patch support X windows
>> application such as firefox?
> 
> No, and I think it may be a long time before that happens.

In short: not yet, but we're getting closer.

For me details, let me first give some background: to successfully
restart an application that is not checkpoint/restart aware, we must
provide the application with everything it would have expected if
it were running originally. For instance, given a process, we also
need its children, the pipes between them, IPC shared memory, and
so on.

For this reason, we checkpoint groups of processes (and threads),
either a whole container or just a subtree of processes. A whole
container is preferable because it isolates the application and
makes it easier to ensure that we do include all the dependencies
of the application in the checkpoint.

Now back to your question: X applications cannot be checkpointed
standalone (unless, of course, X windows is modified for that).
Instead, one must checkpoint the entire user session, including
the X server itself.

The main problem is that the X server is "talking" to the bare
hardware, and the task of recording the specific hardware state
and restoring it later is daunting, and becomes impossible if the
session is to be restarted on different hardware.

The solution is to not run the regular X server. Instead, start
a virtual X server, such as VNC, and run the user session in it.
The main difference is that VNC server does not directly use any
hardware resources, so it is not tied to specific hardware state.
>From the user's point of view - this setup is transparent with
suitable use of a VNC client.

If the VNC server is launched inside a new container, then that
server and all the applications running in that session become
isolated from the rest of the system, and you can checkpoint and
then restart them later. (This assumes, of course, that their
view of the file system does not change between checkpoint and
restart).

So now the question becomes: does the checkpoint/restart patch
support VNC, window managers (e.g. gnome, kde, etc), and then
X applications ?

The answer, from above, is that we're almost there. There are
still some features that are used by common desktop applications
and whose checkpoint/restart logic is in the works (e.g. inotify),
and we also need rudimentary support for checkpoint/restart of
files in opened in procfs (/proc/...).

We're working on it ... stay tuned :)

Oren.

> 
> (Disclaimer: I haven't even tried to see what part of checkpointing
> X breaks first. I suspect it'd be the open device files...)
> 
> The display and input device hardware presents a serious challenge for 
> one thing. They may not be available during restart if it occurs
> on a different machine -- or they may be entirely different hardware. 
> 
> Perhaps checkpoint/restart of programs with these devices open should
> "simulate" hot-[un]plug. Checkpoint could save enough information to make
> the kernel generate the necessary uevents. At restart the file
> descriptors for those devices are never opened and syscalls on them will
> return errno==EBADF. Next we'd need to send uevents for the
> "new-but-not-new" devices. There's a "new-but-not-new" uevent pathway in
> the kernel used during boot -- perhaps there's some way to reuse that.
> Lastly, we send the unplug uevents to get X to drop its use of the old
> devices -- send those last so X always thinks there's hardware.
> 
> That's one way it _could_ be done. Others might rely on device
> "virtualization" -- writing pseudo-device code (CUSE?).
> 
> X also has its own session support. As far as I know how that could
> work with kernel-based checkpoint/restart hasn't been discussed yet.
> 
> Of course this is all off the top of my head. Others are welcome to
> make considerate use of cluebats to inform me of any misconceptions I
> may have.
> 
> Cheers,
> 	-Matt Helsley
> _______________________________________________
> Containers mailing list
> Containers at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/containers
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers