lxc userspace tools 0.3.0 released

lxc userspace tools 0.3.0 released

[Daniel Lezcano]

Hi,

a new version of lxc has been released.

	https://sourceforge.net/projects/lxc/

This version takes into account the control group and provides the
checkpoint / restart for external checkpoint.

It includes a lot of small improvements and fixes, full details are in
the ChangeLog file.

Thanks.
   -- Daniel

Re: lxc userspace tools 0.3.0 released

[Cedric Le Goater]

Daniel Lezcano wrote:
> Hi,
> 
> a new version of lxc has been released.
> 
> 	https://sourceforge.net/projects/lxc/
> 
> This version takes into account the control group and provides the
> checkpoint / restart for external checkpoint.
> 
> It includes a lot of small improvements and fixes, full details are in
> the ChangeLog file.

and the patchset that goes with the user tools is available here :

http://lxc.sourceforge.net/patches/2.6.27/2.6.27-lxc1/
http://lxc.sourceforge.net/patches/2.6.27/2.6.27-lxc1.tar.gz
http://lxc.sourceforge.net/patches/2.6.27/2.6.27-lxc1.patch.gz


Cheers,

C.

Re: [Devel] lxc userspace tools 0.3.0 released

[Dmitry Mishin]

Hi, Daniel!

I studied a bit lxc tools and have a couple of questions. Could you answer 
them?

1)  Why did you chose such way of a container's configuration storing? IMHO, 
configuration in one file is better, because this file will be small and 
could be easily mmap'ed for the following operations instead of multiple 
readdir() and filesystem lookups.
2) why did you chose cvs as VCS? Git is more common and convenient for 
distributed development...

-- 
Thanks,
Dmitry.
On Tuesday 14 October 2008 18:39:42 Daniel Lezcano wrote:
> Hi,
>
> a new version of lxc has been released.
>
> 	https://sourceforge.net/projects/lxc/
>
> This version takes into account the control group and provides the
> checkpoint / restart for external checkpoint.
>
> It includes a lot of small improvements and fixes, full details are in
> the ChangeLog file.
>
> Thanks.
>    -- Daniel
>
> _______________________________________________
> Containers mailing list
> Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
> https://lists.linux-foundation.org/mailman/listinfo/containers
>
> _______________________________________________
> Devel mailing list
> Devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org
> https://openvz.org/mailman/listinfo/devel

Re: lxc userspace tools 0.3.0 released

[Alexey Eremenko]

On Tue, Oct 14, 2008 at 2:39 PM, Daniel Lezcano <dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org> wrote:
> Hi,
>
> a new version of lxc has been released.
>
>        https://sourceforge.net/projects/lxc/
>
> This version takes into account the control group and provides the
> checkpoint / restart for external checkpoint.
>
> It includes a lot of small improvements and fixes, full details are in
> the ChangeLog file.
>
> Thanks.
>   -- Daniel

Hi !

I'm glad to hear about progress of Linux containers.

But I have a few questions:
1. How does LXC compare to OpenVZ ?
and
2. What portion of code is shared between the two ?

-- 
-Alexey Eromenko "Technologov"

Re: [Devel] lxc userspace tools 0.3.0 released

[Daniel Lezcano]

Dmitry Mishin wrote:
> Hi, Daniel!

Hi Dmitry ! good to see you again :)

> I studied a bit lxc tools and have a couple of questions. Could you answer 
> them?

Of course I can :)

> 1)  Why did you chose such way of a container's configuration storing? IMHO, 
> configuration in one file is better, because this file will be small and 
> could be easily mmap'ed for the following operations instead of multiple 
> readdir() and filesystem lookups.

I wanted to have the configuration easily hackable, so you can edit 
directly the files inside the directory. For example, if you remove the 
network directory, when you will start the container, the network will 
not be unshared. If you have a single file, that will be more difficult 
to edit especially if it is a binary file.

The container tree contains more than the configuration file, for 
example, it contains some runtime information.

It is true having a mmapped configuration is more efficient but it is 
just for container startup, and there are not thousand of files. The 
application running inside the container is not impacted.

> 2) why did you chose cvs as VCS? Git is more common and convenient for 
> distributed development...

The lxc userspace tool is a low level component I wrote to play with the 
container, and especially to facilitate the kernek hacking. The lxc 
kernel website is at lxc.sourceforge.net, so logically I put this 
component at the same place. Unfortunately the sourceforge website does 
not provide the services for git tree, only CVS/SVN. But I agree 100% 
with you, I would have definitively preferred to use git.

Re: lxc userspace tools 0.3.0 released

[Daniel Lezcano]

Alexey Eremenko wrote:
> On Tue, Oct 14, 2008 at 2:39 PM, Daniel Lezcano <dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org> wrote:
>> Hi,
>>
>> a new version of lxc has been released.
>>
>>        https://sourceforge.net/projects/lxc/
>>
>> This version takes into account the control group and provides the
>> checkpoint / restart for external checkpoint.
>>
>> It includes a lot of small improvements and fixes, full details are in
>> the ChangeLog file.
>>
>> Thanks.
>>   -- Daniel
> 
> Hi !
> 
> I'm glad to hear about progress of Linux containers.
> 
> But I have a few questions:
> 1. How does LXC compare to OpenVZ ?

I used OpenVZ a few years ago, so perhaps I am wrong comparing OpenVZ 
and LXC, I know the openvz devel mailling list is tied with the 
containers@ mailing, so I hope if I am wrong someone will correct me :)

Just to clarify to avoid confusion. There is a LXC project inside the 
libvirt and there is the lxc userspace tools (liblxc). We are talking 
about the liblxc.

The liblxc is a low level component. There is a library and a set of 
command lines.

The library provides a set of API to manage the containers. That allows 
people to start, stop, create, destroy, monitor, etc ... containers.
On top of that, there is a set of command lines relying on this library 
to play with the containers in a shell.

OpenVZ is a full featured container, providing a lot of services. A 
single command 'vzctl' manages the containers.

The liblxc follows what is in mainline and what will be in mainline. So 
the liblxc can be used with a vanilla kernel or the development kernel 
we are working on.

OpenVZ provides more than what is existing in mainline, that means it 
needs a modified kernel, even if the different features are little by 
little pushed upstream and the OpenVZ kernel patch is being smaller.

The liblxc takes into account two families of containers, the system 
containers and the application containers. The first one launches a full 
distro like a debian, the first process is the 'init' process, the 
system configuration is done by the different services of the distros. 
The second one, launches only an application (that can be 'bash', 
'sshd', or something else), and setup the container (network, mount 
points, etc ...) because there is no services to do that.

OpenVZ, AFAIK, supports the system container but not the application 
containers.

To summarize:

  * OpenVZ is a mature project with a lot of features, (for example the 
migration, checkpoint/restart), aiming to create system container using 
a shell command.

  * Liblxc is a low level component following what is in mainline, (or 
in a near future), with the objective to be simple to use.


> 2. What portion of code is shared between the two ?

I am not sure I understand the question. Do you mean : "is liblxc using 
OpenVZ code ?"

Re: lxc userspace tools 0.3.0 released

[Alexey Eremenko]

Well, Thanks for explanation...

libvirt uses liblxc or uses kernelspace containers directly ?

>> 2. What portion of code is shared between the two ?
>
> I am not sure I understand the question. Do you mean : "is liblxc using
> OpenVZ code ?"
>

Here I mean that OpenVZ and LXC have kernelspace code shared - at
least partially.
(because OpenVZ developers are the ones who are developing kernelspace
LXC and pushing code upstream)

Do you know how much of it ?

I think userspace is not shared at all.

-- 
-Alexey Eromenko "Technologov"

Re: lxc userspace tools 0.3.0 released

[Daniel Lezcano]

Alexey Eremenko wrote:
> Well, Thanks for explanation...
> 
> libvirt uses liblxc or uses kernelspace containers directly ?

kernelspace containers directly.

>>> 2. What portion of code is shared between the two ?
>> I am not sure I understand the question. Do you mean : "is liblxc using
>> OpenVZ code ?"
>>
> 
> Here I mean that OpenVZ and LXC have kernelspace code shared - at
> least partially.
> (because OpenVZ developers are the ones who are developing kernelspace
> LXC and pushing code upstream)
> 
> Do you know how much of it ?

Well OpenVZ guys are part of the container community, we are working 
together to push upstream the kernel code, this is not only an OpenVZ 
effort.

The userspace code is using a set of services provided by the kernel. So 
instead of talking about shared kernel code, IMO, we can talk about the 
used services by both OpenVZ and liblxc.

I can not give a full detail of what are the services used by OpenVZ but 
I think it is reasonable to say liblxc uses at least a subset of what is 
using OpenVZ.

Here is the detail of the kernel features used by the liblxc:
  * cgroup with cgroup scheduler and all the subsystems
  * freezer
  * ipc namespace
  * pid namespace
  * uts namespace
  * network namespace
  * mount namespace

> I think userspace is not shared at all.

Correct :)

Re: [Devel] lxc userspace tools 0.3.0 released

[Dmitry Mishin]

On Thursday 16 October 2008 13:06:45 Daniel Lezcano wrote:
> Dmitry Mishin wrote:
> > Hi, Daniel!
>
> Hi Dmitry ! good to see you again :)
Thank you ! :)

>
> > I studied a bit lxc tools and have a couple of questions. Could you
> > answer them?
>
> Of course I can :)
>
> > 1)  Why did you chose such way of a container's configuration storing?
> > IMHO, configuration in one file is better, because this file will be
> > small and could be easily mmap'ed for the following operations instead of
> > multiple readdir() and filesystem lookups.
>
> I wanted to have the configuration easily hackable, so you can edit
> directly the files inside the directory. For example, if you remove the
> network directory, when you will start the container, the network will
> not be unshared. If you have a single file, that will be more difficult
> to edit especially if it is a binary file.
>
> The container tree contains more than the configuration file, for
> example, it contains some runtime information.
>
> It is true having a mmapped configuration is more efficient but it is
> just for container startup, and there are not thousand of files. The
> application running inside the container is not impacted.
OK, but what if I need some namespace to be shared between containers?
How it will be handled? For example, CT 1 and CT 2 need to share network 
namespace, but keep it separated from host one.
 
>
> > 2) why did you chose cvs as VCS? Git is more common and convenient for
> > distributed development...
>
> The lxc userspace tool is a low level component I wrote to play with the
> container, and especially to facilitate the kernek hacking. The lxc
> kernel website is at lxc.sourceforge.net, so logically I put this
> component at the same place. Unfortunately the sourceforge website does
> not provide the services for git tree, only CVS/SVN. But I agree 100%
> with you, I would have definitively preferred to use git.
Worth to create it at git.openvz.org?

-- 
Thanks,
Dmitry.

Re: [Devel] lxc userspace tools 0.3.0 released

[Daniel Lezcano]

Dmitry Mishin wrote:
> On Thursday 16 October 2008 13:06:45 Daniel Lezcano wrote:
>> Dmitry Mishin wrote:
>>> Hi, Daniel!
>> Hi Dmitry ! good to see you again :)
> Thank you ! :)
> 
>>> I studied a bit lxc tools and have a couple of questions. Could you
>>> answer them?
>> Of course I can :)
>>
>>> 1)  Why did you chose such way of a container's configuration storing?
>>> IMHO, configuration in one file is better, because this file will be
>>> small and could be easily mmap'ed for the following operations instead of
>>> multiple readdir() and filesystem lookups.
>> I wanted to have the configuration easily hackable, so you can edit
>> directly the files inside the directory. For example, if you remove the
>> network directory, when you will start the container, the network will
>> not be unshared. If you have a single file, that will be more difficult
>> to edit especially if it is a binary file.
>>
>> The container tree contains more than the configuration file, for
>> example, it contains some runtime information.
>>
>> It is true having a mmapped configuration is more efficient but it is
>> just for container startup, and there are not thousand of files. The
>> application running inside the container is not impacted.
> OK, but what if I need some namespace to be shared between containers?
> How it will be handled? For example, CT 1 and CT 2 need to share network 
> namespace, but keep it separated from host one.

I think that can be solved by nested container, a container 1, unsharing 
the network, and inside create 2 containers without unsharing the network.

Example:
	in a script called myscript.sh:
		#!/bin/bash
		lxc-execute -n ctr1 echo "hello1" &
		lxc-execute -n ctr2 echo "hello2"
	
	in the shell:
	lxc-create -n mynetwork -f myconf
	lxc-execute -n mynetwork ./myscript.sh


Do you have an example, an use case for this kind of configuration ?

>>> 2) why did you chose cvs as VCS? Git is more common and convenient for
>>> distributed development...
>> The lxc userspace tool is a low level component I wrote to play with the
>> container, and especially to facilitate the kernek hacking. The lxc
>> kernel website is at lxc.sourceforge.net, so logically I put this
>> component at the same place. Unfortunately the sourceforge website does
>> not provide the services for git tree, only CVS/SVN. But I agree 100%
>> with you, I would have definitively preferred to use git.
> Worth to create it at git.openvz.org?

Yep, why not. I have to think about that.

Re: lxc userspace tools 0.3.0 released

[Cedric Le Goater]

> Just to clarify to avoid confusion. There is a LXC project inside the 
> libvirt and there is the lxc userspace tools (liblxc). We are talking 
> about the liblxc.

I wouldn't say there is a "LXC project inside the libvirt" but rather
there is a libvirt driver emulating a virtual machine using namespaces.
This driver is called lxc for some reason I don't know and this is very 
unfortunate IMO.

C.

Re: lxc userspace tools 0.3.0 released

[Daniel P. Berrange]

On Thu, Oct 16, 2008 at 02:55:23PM +0200, Cedric Le Goater wrote:
> > Just to clarify to avoid confusion. There is a LXC project inside the 
> > libvirt and there is the lxc userspace tools (liblxc). We are talking 
> > about the liblxc.
> 
> I wouldn't say there is a "LXC project inside the libvirt" but rather
> there is a libvirt driver emulating a virtual machine using namespaces.
> This driver is called lxc for some reason I don't know and this is very 
> unfortunate IMO.

It is called LXC because it implements "LinuX Containers". When we first
released this LXC driver in libvirt this lxc userspace tools package didn't
exist so there was no naming clash.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: lxc userspace tools 0.3.0 released

[Daniel Lezcano]

Daniel P. Berrange wrote:
> On Thu, Oct 16, 2008 at 02:55:23PM +0200, Cedric Le Goater wrote:
>>> Just to clarify to avoid confusion. There is a LXC project inside the 
>>> libvirt and there is the lxc userspace tools (liblxc). We are talking 
>>> about the liblxc.
>> I wouldn't say there is a "LXC project inside the libvirt" but rather
>> there is a libvirt driver emulating a virtual machine using namespaces.
>> This driver is called lxc for some reason I don't know and this is very 
>> unfortunate IMO.
> 
> It is called LXC because it implements "LinuX Containers". When we first
> released this LXC driver in libvirt this lxc userspace tools package didn't
> exist so there was no naming clash.

Libvirt being a VM/container middleware, shouldn't we change lxc-driver 
to use liblxc ?

Re: [Devel] lxc userspace tools 0.3.0 released

[Dmitry Mishin]

On Thursday 16 October 2008 16:28:08 Daniel Lezcano wrote:
> Dmitry Mishin wrote:
> > On Thursday 16 October 2008 13:06:45 Daniel Lezcano wrote:
> >> Dmitry Mishin wrote:
> >>> Hi, Daniel!
> >>
> >> Hi Dmitry ! good to see you again :)
> >
> > Thank you ! :)
> >
> >>> I studied a bit lxc tools and have a couple of questions. Could you
> >>> answer them?
> >>
> >> Of course I can :)
> >>
> >>> 1)  Why did you chose such way of a container's configuration storing?
> >>> IMHO, configuration in one file is better, because this file will be
> >>> small and could be easily mmap'ed for the following operations instead
> >>> of multiple readdir() and filesystem lookups.
> >>
> >> I wanted to have the configuration easily hackable, so you can edit
> >> directly the files inside the directory. For example, if you remove the
> >> network directory, when you will start the container, the network will
> >> not be unshared. If you have a single file, that will be more difficult
> >> to edit especially if it is a binary file.
> >>
> >> The container tree contains more than the configuration file, for
> >> example, it contains some runtime information.
> >>
> >> It is true having a mmapped configuration is more efficient but it is
> >> just for container startup, and there are not thousand of files. The
> >> application running inside the container is not impacted.
> >
> > OK, but what if I need some namespace to be shared between containers?
> > How it will be handled? For example, CT 1 and CT 2 need to share network
> > namespace, but keep it separated from host one.
>
> I think that can be solved by nested container, a container 1, unsharing
> the network, and inside create 2 containers without unsharing the network.
>
> Example:
> 	in a script called myscript.sh:
> 		#!/bin/bash
> 		lxc-execute -n ctr1 echo "hello1" &
> 		lxc-execute -n ctr2 echo "hello2"
>
> 	in the shell:
> 	lxc-create -n mynetwork -f myconf
> 	lxc-execute -n mynetwork ./myscript.sh
I mean how it will be handled from configuration layout POV?

>
>
> Do you have an example, an use case for this kind of configuration ?
For example, web server and dns server for the same domain, hosted on the 
external node.

As you mentioned, the goal of this tool is to provide ability for kernel 
hackers to test namespaces support in mainstream. Thus it should be flexible 
as possible and do not add limitations over current functionality. Current 
design of configuration storing is likely to be a week place in this sense. 
At least I do not understand yet how namespaces inheritance could be 
reflected in it.

>
> >>> 2) why did you chose cvs as VCS? Git is more common and convenient for
> >>> distributed development...
> >>
> >> The lxc userspace tool is a low level component I wrote to play with the
> >> container, and especially to facilitate the kernek hacking. The lxc
> >> kernel website is at lxc.sourceforge.net, so logically I put this
> >> component at the same place. Unfortunately the sourceforge website does
> >> not provide the services for git tree, only CVS/SVN. But I agree 100%
> >> with you, I would have definitively preferred to use git.
> >
> > Worth to create it at git.openvz.org?
>
> Yep, why not. I have to think about that.



-- 
Thanks,
Dmitry.

Re: [Devel] lxc userspace tools 0.3.0 released

[Daniel Lezcano]

Dmitry Mishin wrote:
> On Thursday 16 October 2008 16:28:08 Daniel Lezcano wrote:
>> Dmitry Mishin wrote:
>>> On Thursday 16 October 2008 13:06:45 Daniel Lezcano wrote:
>>>> Dmitry Mishin wrote:
>>>>> Hi, Daniel!
>>>> Hi Dmitry ! good to see you again :)
>>> Thank you ! :)
>>>
>>>>> I studied a bit lxc tools and have a couple of questions. Could you
>>>>> answer them?
>>>> Of course I can :)
>>>>
>>>>> 1)  Why did you chose such way of a container's configuration storing?
>>>>> IMHO, configuration in one file is better, because this file will be
>>>>> small and could be easily mmap'ed for the following operations instead
>>>>> of multiple readdir() and filesystem lookups.
>>>> I wanted to have the configuration easily hackable, so you can edit
>>>> directly the files inside the directory. For example, if you remove the
>>>> network directory, when you will start the container, the network will
>>>> not be unshared. If you have a single file, that will be more difficult
>>>> to edit especially if it is a binary file.
>>>>
>>>> The container tree contains more than the configuration file, for
>>>> example, it contains some runtime information.
>>>>
>>>> It is true having a mmapped configuration is more efficient but it is
>>>> just for container startup, and there are not thousand of files. The
>>>> application running inside the container is not impacted.
>>> OK, but what if I need some namespace to be shared between containers?
>>> How it will be handled? For example, CT 1 and CT 2 need to share network
>>> namespace, but keep it separated from host one.
>> I think that can be solved by nested container, a container 1, unsharing
>> the network, and inside create 2 containers without unsharing the network.
>>
>> Example:
>> 	in a script called myscript.sh:
>> 		#!/bin/bash
>> 		lxc-execute -n ctr1 echo "hello1" &
>> 		lxc-execute -n ctr2 echo "hello2"
>>
>> 	in the shell:
>> 	lxc-create -n mynetwork -f myconf
>> 	lxc-execute -n mynetwork ./myscript.sh
> I mean how it will be handled from configuration layout POV?
> 
>>
>> Do you have an example, an use case for this kind of configuration ?
> For example, web server and dns server for the same domain, hosted on the 
> external node.

Ok I see, thanks.

> As you mentioned, the goal of this tool is to provide ability for kernel 
> hackers to test namespaces support in mainstream. Thus it should be flexible 
> as possible and do not add limitations over current functionality. Current 
> design of configuration storing is likely to be a week place in this sense. 
> At least I do not understand yet how namespaces inheritance could be 
> reflected in it.

I don't think it is a current limitation as I shown in the previous 
example. Not being able to define a configuration for a nested container 
is not a big issue right now because the nested container are not fully 
supported (eg. network devices being pushed back to init_net).

The configuration storing is I think a good approach and it is not an 
API like the cgroup, it can be changed at any time. The advantage of 
having a tree file for a container will appear more clear with the 
future functionalities.

If the nested containers become a must-have and asked by people, the lxc 
tools will be changed in this way. We can imagine to do like the cgroup 
and create in the container directory a new container directory to 
reflect the hierarchy and we access a container by doing for example 
"lxc-stop -n foo/bar" (bar is a child of foo). We can imagine to 
implement a fuse for containers and create / destroy when doing 
mkdir/rmdir, as well as create a directory when doing lxc_create.

The configuration could be something like:

Create a nested container with two configuration files:
	lxc-create -n foo/bar -f foo.conf -f bar.conf

And so execute:
	lxc-execute -n foo/bar /usr/sbin/httpd /bin/bash

will unshare 'foo', exec 'httpd' and so unshare 'bar' (under 'foo') and 
exec 'bash'

Well these are random thoughts... :)

Thanks
  -- Daniel

Re: [Devel] lxc userspace tools 0.3.0 released

[Dmitry Mishin]

On Saturday 18 October 2008 00:42:38 Daniel Lezcano wrote:
> Dmitry Mishin wrote:
> > On Thursday 16 October 2008 16:28:08 Daniel Lezcano wrote:
> >> Dmitry Mishin wrote:
> >>> On Thursday 16 October 2008 13:06:45 Daniel Lezcano wrote:
> >>>> Dmitry Mishin wrote:
> >>>>> Hi, Daniel!
> >>>>
> >>>> Hi Dmitry ! good to see you again :)
> >>>
> >>> Thank you ! :)
> >>>
> >>>>> I studied a bit lxc tools and have a couple of questions. Could you
> >>>>> answer them?
> >>>>
> >>>> Of course I can :)
> >>>>
> >>>>> 1)  Why did you chose such way of a container's configuration
> >>>>> storing? IMHO, configuration in one file is better, because this file
> >>>>> will be small and could be easily mmap'ed for the following
> >>>>> operations instead of multiple readdir() and filesystem lookups.
> >>>>
> >>>> I wanted to have the configuration easily hackable, so you can edit
> >>>> directly the files inside the directory. For example, if you remove
> >>>> the network directory, when you will start the container, the network
> >>>> will not be unshared. If you have a single file, that will be more
> >>>> difficult to edit especially if it is a binary file.
> >>>>
> >>>> The container tree contains more than the configuration file, for
> >>>> example, it contains some runtime information.
> >>>>
> >>>> It is true having a mmapped configuration is more efficient but it is
> >>>> just for container startup, and there are not thousand of files. The
> >>>> application running inside the container is not impacted.
> >>>
> >>> OK, but what if I need some namespace to be shared between containers?
> >>> How it will be handled? For example, CT 1 and CT 2 need to share
> >>> network namespace, but keep it separated from host one.
> >>
> >> I think that can be solved by nested container, a container 1, unsharing
> >> the network, and inside create 2 containers without unsharing the
> >> network.
> >>
> >> Example:
> >> 	in a script called myscript.sh:
> >> 		#!/bin/bash
> >> 		lxc-execute -n ctr1 echo "hello1" &
> >> 		lxc-execute -n ctr2 echo "hello2"
> >>
> >> 	in the shell:
> >> 	lxc-create -n mynetwork -f myconf
> >> 	lxc-execute -n mynetwork ./myscript.sh
> >
> > I mean how it will be handled from configuration layout POV?
> >
> >> Do you have an example, an use case for this kind of configuration ?
> >
> > For example, web server and dns server for the same domain, hosted on the
> > external node.
>
> Ok I see, thanks.
>
> > As you mentioned, the goal of this tool is to provide ability for kernel
> > hackers to test namespaces support in mainstream. Thus it should be
> > flexible as possible and do not add limitations over current
> > functionality. Current design of configuration storing is likely to be a
> > week place in this sense. At least I do not understand yet how namespaces
> > inheritance could be reflected in it.
>
> I don't think it is a current limitation as I shown in the previous
> example. Not being able to define a configuration for a nested container
> is not a big issue right now because the nested container are not fully
> supported (eg. network devices being pushed back to init_net).
>
> The configuration storing is I think a good approach and it is not an
> API like the cgroup, it can be changed at any time. 
With the respective backward-compatibility or conversion code to be written...

> The advantage of 
> having a tree file for a container will appear more clear with the
> future functionalities.
>
> If the nested containers become a must-have and asked by people, the lxc
> tools will be changed in this way. We can imagine to do like the cgroup
> and create in the container directory a new container directory to
> reflect the hierarchy and we access a container by doing for example
> "lxc-stop -n foo/bar" (bar is a child of foo).
Unification with cgroups is good idea, IMHO.
 
> We can imagine to 
> implement a fuse for containers and create / destroy when doing
> mkdir/rmdir, as well as create a directory when doing lxc_create.
>
> The configuration could be something like:
>
> Create a nested container with two configuration files:
> 	lxc-create -n foo/bar -f foo.conf -f bar.conf
>
> And so execute:
> 	lxc-execute -n foo/bar /usr/sbin/httpd /bin/bash
>
> will unshare 'foo', exec 'httpd' and so unshare 'bar' (under 'foo') and
> exec 'bash'
>
> Well these are random thoughts... :)
Good thoughts! I need to take a look at cgroups management tools and possibly 
develop something usefull for lxc :)
 
>
> Thanks
>   -- Daniel



-- 
Thanks,
Dmitry.

Re: [Devel] lxc userspace tools 0.3.0 released

[Daniel Lezcano]

Dmitry Mishin wrote:
> On Saturday 18 October 2008 00:42:38 Daniel Lezcano wrote:
>> Dmitry Mishin wrote:
>>> On Thursday 16 October 2008 16:28:08 Daniel Lezcano wrote:
>>>> Dmitry Mishin wrote:
>>>>> On Thursday 16 October 2008 13:06:45 Daniel Lezcano wrote:
>>>>>> Dmitry Mishin wrote:
>>>>>>> Hi, Daniel!
>>>>>> Hi Dmitry ! good to see you again :)
>>>>> Thank you ! :)
>>>>>
>>>>>>> I studied a bit lxc tools and have a couple of questions. Could you
>>>>>>> answer them?
>>>>>> Of course I can :)
>>>>>>
>>>>>>> 1)  Why did you chose such way of a container's configuration
>>>>>>> storing? IMHO, configuration in one file is better, because this file
>>>>>>> will be small and could be easily mmap'ed for the following
>>>>>>> operations instead of multiple readdir() and filesystem lookups.
>>>>>> I wanted to have the configuration easily hackable, so you can edit
>>>>>> directly the files inside the directory. For example, if you remove
>>>>>> the network directory, when you will start the container, the network
>>>>>> will not be unshared. If you have a single file, that will be more
>>>>>> difficult to edit especially if it is a binary file.
>>>>>>
>>>>>> The container tree contains more than the configuration file, for
>>>>>> example, it contains some runtime information.
>>>>>>
>>>>>> It is true having a mmapped configuration is more efficient but it is
>>>>>> just for container startup, and there are not thousand of files. The
>>>>>> application running inside the container is not impacted.
>>>>> OK, but what if I need some namespace to be shared between containers?
>>>>> How it will be handled? For example, CT 1 and CT 2 need to share
>>>>> network namespace, but keep it separated from host one.
>>>> I think that can be solved by nested container, a container 1, unsharing
>>>> the network, and inside create 2 containers without unsharing the
>>>> network.
>>>>
>>>> Example:
>>>> 	in a script called myscript.sh:
>>>> 		#!/bin/bash
>>>> 		lxc-execute -n ctr1 echo "hello1" &
>>>> 		lxc-execute -n ctr2 echo "hello2"
>>>>
>>>> 	in the shell:
>>>> 	lxc-create -n mynetwork -f myconf
>>>> 	lxc-execute -n mynetwork ./myscript.sh
>>> I mean how it will be handled from configuration layout POV?
>>>
>>>> Do you have an example, an use case for this kind of configuration ?
>>> For example, web server and dns server for the same domain, hosted on the
>>> external node.
>> Ok I see, thanks.
>>
>>> As you mentioned, the goal of this tool is to provide ability for kernel
>>> hackers to test namespaces support in mainstream. Thus it should be
>>> flexible as possible and do not add limitations over current
>>> functionality. Current design of configuration storing is likely to be a
>>> week place in this sense. At least I do not understand yet how namespaces
>>> inheritance could be reflected in it.
>> I don't think it is a current limitation as I shown in the previous
>> example. Not being able to define a configuration for a nested container
>> is not a big issue right now because the nested container are not fully
>> supported (eg. network devices being pushed back to init_net).
>>
>> The configuration storing is I think a good approach and it is not an
>> API like the cgroup, it can be changed at any time. 
> With the respective backward-compatibility or conversion code to be written...

Good point :)