Serge,
Sorry for the delay responding. I have tried multiple times to get
lxcbr0 to recognize the IPV6 DHCP in my network, but after reading it
looks like lxcbr0 is more self contained and may not allow access to the
local, physical network.
I will keep trying and testing.
Thanks,
Van
On 1
On 20/01/16 23:57, Fajar A. Nugraha wrote:
> Yep. I don't know when it was fixed, but my test system works fine. This is
> after a reboot:
>
> root@debian:~# lxc-ls -f
> NAME STATEIPV4IPV6 GROUPS AUTOSTART
> --
> c1RUNNING 10.0.3.
Yep. I don't know when it was fixed, but my test system works fine. This is
after a reboot:
root@debian:~# lxc-ls -f
NAME STATEIPV4IPV6 GROUPS AUTOSTART
--
c1RUNNING 10.0.3.194 - - YES
root@debian:~# lxc-attach -n c1 -
On Thu, Jan 21, 2016 at 5:49 AM, Fajar A. Nugraha wrote:
> On Thu, Jan 21, 2016 at 5:23 AM, Viktor Trojanovic
> wrote:
>
>> I just did a system upgrade on my Arch System which included updating the
>> kernel, systemd and lxc to the newest versions. After having done so, I
>> cannot interact with
On Thu, Jan 21, 2016 at 5:23 AM, Viktor Trojanovic wrote:
> I just did a system upgrade on my Arch System which included updating the
> kernel, systemd and lxc to the newest versions. After having done so, I
> cannot interact with my Linux container any longer. The system within the
> container s
I just did a system upgrade on my Arch System which included updating
the kernel, systemd and lxc to the newest versions. After having done
so, I cannot interact with my Linux container any longer. The system
within the container still seems to work fine and can be contacted from
outside (Samba
That looks like an old version of LXC. Try upgrading to a newer version, maybe
build one from source.
Neil.
On 20 January 2016 18:54:44 GMT+00:00, Carlos Alberto Lopez Perez
wrote:
>On 20/01/16 19:20, Carlos Alberto Lopez Perez wrote:
>>
>> After more testing, this only seems reproducible w
On 20/01/16 19:20, Carlos Alberto Lopez Perez wrote:
>
> After more testing, this only seems reproducible when booting.
>
And is not a race condition (I thought that maybe the cgroup fs were not
mounted when lxc-autostart-helper was executed).
So, I have tested to put a sleep of 30 seconds in l
>
> Right now, there is one lxc-start process per container running (that has
> renamed itself in lxc 1.1.4 to [lxc-monitor]) to act as the interface to
> the
> container for various LXC tools.
>
> I'd like that process to exit once the container is up and running. I do
> not
> want to ever stop th
On 20/01/16 18:59, Carlos Alberto Lopez Perez wrote:
> Hello,
>
> I've found that when lxc-autostart is executed via systemd, the cgroups
> assigned to the container are wrong for some control groups.
>
> See the following two examples:
>
> 1. Container started via systemd (/lib/systemd/system/l
Hello,
I've found that when lxc-autostart is executed via systemd, the cgroups
assigned to the container are wrong for some control groups.
See the following two examples:
1. Container started via systemd (/lib/systemd/system/lxc.service unit
that calls lxc-autostart).
# cat /proc/${pidofsomepr
I agree lxc-top is somewhat confusing. For example, all columns except Mem
show totals, while Mem shows current memory usage.
I believe lxc-top needs some work to become actually usable. Data it
displays should be in one of the following modes:
- current value, like top
- total divided by containe
Right now, there is one lxc-start process per container running (that has
renamed itself in lxc 1.1.4 to [lxc-monitor]) to act as the interface to the
container for various LXC tools.
I'd like that process to exit once the container is up and running. I do not
want to ever stop the container, con
13 matches
Mail list logo