restart (mktree) program usage

Serge E. Hallyn serue at us.ibm.com
Thu Sep 17 10:13:27 PDT 2009


Quoting Sukadev Bhattiprolu (sukadev at linux.vnet.ibm.com):
> Serge E. Hallyn [serue at us.ibm.com] wrote:
> | > > True. But if originally the application was started as:
> | > > 
> | > > 	Create container
> | > > 	Login to contaienr
> | > 
> | > Actually, I'm not sure what you mean by "login to container" ?
> | 
> | I assume he was thinking of a system container created with liblxc
> | or libvirt, and literally logging in on its console or over ssh.
> 
> Yes, but...
> | 
> | ...
> | 
> | > > Yes, that would be really useful I think for things like restoring file
> | > > system to its snapshot. Without that there is somewhat of an assymetry
> | > > in starting an application in a container and restarting it from a
> | > > checkpoint.
> | 
> | Fine, they are different operations :)
> 
> ...more than the assymetry, I guess I am not sure what is the "recommended"
> way to restart an application, while ensuring filesystem (and network)
> are correctly restored by user.
> 
> 	ns_exec --cpuim -- /usr/bin/restart --wait < checkpoint-image.1
> 
> assumes fs/network are setup. Hence the "login" to the container.

Right, this is stuff to discuss at the plumbers talk and BOF.  How
much of this do we want /usr/bin/restart to handle?  It already does
pidns, and IMO having it handle everything needed makes sense.  The
only problem is we can't have it handle filesystem yet because we
haven't yet decided where/how to checkpont the fs :)  I don't even
mean mounts, I mean a btrfs snapshot or rsync.  Do we want to create
a 'container_checkpoint' program which wraps 'checkpoint' and does
filesystem and network interface snapshotting?

I'm not asking for an answer in this thread, but for it to be discussed
at the bof :)

-serge


More information about the Containers mailing list