[lxc-devel] Container autostart proposal V2

Harald Dunkel harri at afaics.de
Thu May 30 15:28:45 UTC 2013


Hi Stéphane,

On 05/30/13 15:33, Stéphane Graber wrote:
>
> That's already covered by my proposal and I believe covered in the use
> cases listed within it.
>
> "lxc-stop -g any"
>
> That'll stop all containers that are in the "any" group. "any" is
> documented as being a special group that contains all containers even if
> they have lxc.group set.
>

My appologies, I have missed that.

If LXC relies upon a special group to stop containers, wouldn't
it be more consistent to use an "autostart" group, too?

>> And one question:
>>
>> Do lxc-start -a ... and lxc-stop -a ... start/stop all LXC
>> containers in parallel, if their order and group are the
>> same? I am concerned about accumulating timeouts or delays
>> at shutdown or startup time of the host.
>
> The usual STOPPED => RUNNING or RUNNING => STOPPED time is < 1s, so no,
> we'll be doing that in serial order, but you won't really notice it
> because of how quick it's.
>

Sorry, but I disagree in this case. Surely the containers start init
very fast, but on shutdown time lxc-stop has to wait for _all_
processes running in the container. Some Java webapps might take an
awful lot of time to stop (just as an example, meaning no offense to
the Java folks).

The LXC server might have 16 cores or more. Its more efficient if
the containers are triggered to shut down in parallel, instead of
shutting down one after the other, while the rest is still using
up their own CPU time and keep the disks busy.

If we assume a LXC server running 30 containers in parallel, and
if every container needs 10 seconds to stop (this is not uncommon),
then this means 5 minutes downtime just to stop all services.

> That's assuming lxc.start.delay isn't set. If it's set, then obviously
> startup will take longer because we'll wait of lxc.start.delay before
> starting the next container (parallelizing would make the whole
> priority/delay idea completely pointless obviously).
>

Thats not obvious at all. The containers might have different order
numbers. Only the containers with the same order number should
be started (or stopped) in parallel. Lxc could wait for the largest
start delay, before starting the next set of containers with the
next order number.


Regards
Harri





More information about the lxc-devel mailing list