Re: restart (mktree) program usage

[Oren Laadan <orenl-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org>]

Serge E. Hallyn wrote:
> Quoting Oren Laadan (orenl-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org):
>>
>> Sukadev Bhattiprolu wrote:
>>> Oren Laadan [orenl-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org] wrote:
>>> | 
>>> | 
>>> | Sukadev Bhattiprolu wrote:
>>> | > I have a usage question on the 'restart' (formerly mktree) program.
>>> | > 
>>> | > In the following container c/r case: 
>>> | > 
>>> | > 	- create a container
>>> | > 	- log in to the container,
>>> | > 	- restore filesystem(s) from snapshot
>>> | > 	- restart application from checkpoint
>>> | 
>>> | FWIW, I'd expect that future versions of 'restart' will be capable
>>> | of doing this entire setup, (filesystem(s) included), as it matures.
>>> | 
>>> | Note that this use case that you suggest will only work to restart
>>> | subtrees; it is unsuitable for full containers (with pids) because
>>> | the pid of init (1) will already be in use.
>>>
>>> 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.

This is exactly my point:

* If you checkpoint full container, you get the sshd (and init) as
well, so you can't restore into an "existing" container, but create
a new one.

* If you checkpoint subtree, you will miss orphans, and you will
give up leak-detection.

I'd assume most users of this scenarios will prefer full container.

If you want to restart by first creating a new container, than set
it up, then log-in to that container, and finally run restart -
you will _have to_ modify the checkpoint image to remove unwanted
parts, and adjust the remaining accordingly.

For instance, you will have to remove (or tell the kernel to skip)
the data for the init task, and the ssh-server, and then change the
ppid of the root of your subtree to be 1 instead of what it was
(probably the old ssh-server), and so on.

It's doable, but I'm unsure if it's worth the extra work.

Oren.

> 
>>> 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 :)
> 
> -serge