[lxc-devel] lxc and ganeti integration

Guido Trotter ultrotter at google.com
Fri May 22 14:54:57 UTC 2009


On Fri, May 22, 2009 at 2:15 PM, Daniel Lezcano <daniel.lezcano at free.fr> wrote:
>
> Oh, Dietmar Maurer did that. It is in a branch called "forker". It did some
> changes because I need to have it optional for another project build on top
> of lxc. Dietmar was supposed to do some cleanup but I guess he is very busy
> right now.
> I played with its code and it works well. A daemon is launched by lxc in the
> container right before exec'ing '/sbin/init' and communicate with a lxc
> command outside of the container via a fifo.
> So it is very easy to exec a command inside, so you can do 'ps', debug your
> application, netstat or configure the network.
> Unfortunately when a application is run instead of a system and the 'forker'
> is enabled, when the application finishes, the container does not exit. I am
> trying to find a way to fix that.
> I will merge the forker branch with the master soon.

But isn't it possible to start such an application anew, without the forker?
The issue I see with it is that living in the container it would be
easy for the forker process to be controlled from inside the container
(eg. killed).
Wouldn't it be better to just execute something new on a container "on
request", from outside? Or is that impossible?

>
> At present, if you install a debian container (via lxc-debian), you would be
> able to log to the container with the lxc-console command.
>

And what's special in lxc-debian that allows it, and that cannot be
generalized to "any" container?


>
> Not sure this is what you want, but you can specify several interfaces for
> the container either if you have just one physical nic and lxc will
> configure them automatically for you if you specify the network
> configuration in the configuration file.
>
> below an example of a network section configuration from a configuration
> file. The hwaddr, ipv4 and ipv6 are optional in case you want to 'boot' a
> system like a debian because this one will configure the network. But in
> case you want to launch an application (eg. sshd), specifying this network
> configuration will setup automatically ipv4 and ipv6. If the hwaddr is not
> specified it is automatically and randomly generated by a kernel algorithm.
>
> # Container with network a complex network mixing macvlan, veth interfaces
>
> # first interface
> lxc.network.type = veth
> lxc.network.flags = up
> lxc.network.link = br0
> lxc.network.hwaddr = 4a:49:43:49:79:bf
> lxc.network.ipv4 = 1.2.3.5/24
> lxc.network.ipv4 = 1.2.3.7/24
> lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3597
>
> # second interface
> lxc.network.type = veth
> lxc.network.flags = up
> lxc.network.link = br0
> lxc.network.hwaddr = 4a:49:43:49:79:ef
> lxc.network.ipv4 = 1.2.3.6/24
> lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3565
>
> # third interface
> lxc.network.type = macvlan
> lxc.network.flags = up
> lxc.network.link = eth0
> lxc.network.hwaddr = 4a:49:43:49:79:bd
> lxc.network.ipv4 = 1.2.3.4/24
> lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3596
>

Oh ok, I hadn't just realized that you could "repeat" lxc.network.*,
starting with a new type. That sounds good.
A script would still be useful because it allows to do special
site-level things (for example, set up routes, routing policies,
firewalling, etc)
Perhaps
lxc.network.script = ...
And then all the information gets passed to the script rather than
doing anything (apart from creating the interfaces)
And/or
lxc.network.script_model = (automatic|manual)
where in automatic you do what you do today, plus call the script, in
manual mode you leave everything apart from creating the interfaces
and associating them to the container to the script.

Thanks,

Guido




More information about the lxc-devel mailing list