Add checkpoint/restore functionality to nsinit and libcontainer

New code was added to nsinit and libcontainer to use the criu(8) utility
to checkpoint and restore a container.

While there are no hard-coded assumptions about Docker, the new C/R
functionality has only been tested with Docker containers.

The nsinit command line usage for checkpoint and restore is consistent
with the rest of nsinit commands.  However, for easier C/R usage, the
user can specify the container ID on the command line.  The best way
to get started is to run "nsinit checkpoint --help" and look at the
"EXAMPLE:" section.

Signed-off-by: Saied Kazemi <saied@google.com>
Lets not go the route of having a hard dependency on Docker and it's
structure in nsinit. It should be a standalone tool used by other container
implementations. I'm guessing what we really want is some list of mounts we
use for C/R, an easy way we do it today is assuming AUFS and the structure.
We can alternatively take all the mounts as args (kinda horrible I know,
but more correct and flexible, nsinit is not the jewel of usable tools
anyways).

On Tue, Sep 30, 2014 at 9:27 AM, Saied Kazemi <notifications@github.com>
wrote:

> In nsinit/restore.go:
>
> > +	if err != nil {
> > +		log.Fatal(err)
> > +	}
> > +}
> > +
> > +// Mount the container's filesystem if it's not already mounted.
> > +func mountRootFs(containerId string, verbose bool) error {
> > +	// Check if already mounted.
> > +	aufsDir := filepath.Join(libcontainerDir, "../../aufs")
> > +	rootFs := filepath.Join(aufsDir, "mnt", containerId)
> > +	err := exec.Command("grep", "-q", rootFs, "/proc/mounts").Run()
> > +	if err == nil {
> > +		return nil
> > +	}
> > +
> > +	// Filesystem isn't mounted. Read its AUFS branch IDs in
>
> As you have said, nsinit is a test/debug tool to validate libcontainer
> APIs and, therefore, should not be considered as production tool to
> checkpoint and restore containers.
>
> However, if there is a strong desire in adding support for additional
> graph drivers to nsinit, we have the following options ordered from least
> desirable to most (for me):
>
>    1. Parse rootfs path to determine filesystem type.
>    2. Peek into Docker's config.json.
>    3. Specify on the command line.
>    4. Add driver type to container.json.
>
> In short, if we really want additional graph driver support in nsinit, I
> suggest adding the driver type to container.json.
>
> Any thoughts?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/docker/libcontainer/pull/204/files#r18228869>.
>