[lxc-devel] lxc git branch

Daniel Lezcano dlezcano at fr.ibm.com
Wed Mar 18 09:14:59 UTC 2009


Dietmar Maurer wrote:
>> Dietmar Maurer wrote:
>>>> I will look at making the cinit optional and not correlated to the
>>>> rootfs.
>>> It does not makes sense if it is optional, because then you have no
>> way
>>> to exec commands inside the container (for example reboot)?
>> The philosophy of the lxc tools is to be as flexible as possible. You
>> see in the code, I tried to have as much as possible everything being
>> configurable. And I would like to keep this configurable, especially
> to
> 
> sure, I agree on that.
> 
>> bring checkpoint/restart on top of lxc. And making the 'exec'
>> configurable is a way to organize the code and do some cleanup.
> 
> Yes, but the current tty code make c/r impossible, because it uses pty
> resources of the host?

Yes, you are right they won't be checkpointed but they should be 
restored by the configuration when restarting (losing the buffer content).

Before changing this code, I have to finish the CR on top of lxc which 
will take some months. I have been thinking about this point since Oren 
pointed it and I think it would be possible to invert the tty creation 
into the container and pass the fd to the parent.

>>> - for application containers, you need an 'init' anyways?
>> If you want to support daemon like sshd, yes. Otherwise it is not
>> mandatory.
> 
> I thought the current code always starts an dummy init?

When you use lxc-execute, it will launch lxc-init with the specified 
program. When you use lxc-start, if no command is specified in the 
command, the /sbin/init is used, otherwise it is the specified command.

>>> - for 'full' containers, you need a way to log init output (really).
>> Yes, sure. But the logging and the ability to launch commands inside
>> the
>> container are different features no ?
> 
> Yes, that is why we can pass flags to cinit to adjust the behavior.

ok.

>> Maybe someone would like to have
>> the init's logs directly displayed on its tty instead of having them
>> saved into a file, especially when he is trying to figure out what is
>> going wrong when the container boots.
> 
> IMHO, this is a debugging feature. And you can also 'tail -f file' to
> show
> the output of that file ;-)

Argh ! :)

>>> - and you always want a way to exec commands inside the container.
>> Not always and that is the point. The liblxc is used with HPC jobs
>> where
>> they want only one process inside, so they do lxc-start -n foo myjob.
> 
> ah, ok.
>  
> Btw, the current 'lxc-start' is an additinal process, staying around for
> the whole 
> lifetime of a container. Don't you think we can remove that overhead?
> OpenVZ shows
> that it is not strictly needed.

Yes, there is a supervision process on top of the first virtualized 
process. It is in charge of monitoring the container, cleanup the 
resources and wait for the child process for the exit status of the 
application. The HPC guys agreed on this process because it can not be 
avoided due to the pid namespace design.

The legitimate question is "shall the lxc_start function do so much 
things ?". No sure, maybe lxc_start just needs to fork/setup/exec and 
returns the pid of the first process of the container and let the caller 
to handle that. But this is another story....

Concerning OpenVZ, I would not compare lxc to openvz because there are 
some fundamental differences:
	* openvz has a kernel they modify to fit their needs, lxc uses a 
mainline kernel.
	* it is a complete system container while lxc is a container tool kit 
making possible to do system and application container or other things 
around containers.
	* there was a third reason but I don't remember it :)

AFAICS, if openvz does not use an additional process it is for one of 
these two reasons:
  * it doesn't care about the container lifecycle and return code
  or
  * it doesn't use the pid namespace or it uses a modified version.





More information about the lxc-devel mailing list