I have a new container which I cannot attach to (lxc-console):
root@zoo:/lxc# /usr/bin/lxc-start -f egal.cfg -n egal &
[1] 3800
root@zoo:/lxc# pstree -p 3800
lxc-start(3800)---init(3801)-+-cron(3857)
|-rsyslogd(3827)-+-{rsyslogd}(3839)
|
On Mon 2011-04-18 (19:40), Daniel Lezcano wrote:
> On 04/17/2011 09:47 AM, Ulli Horlacher wrote:
>
> >
> > I will integrate the other lxc basic commands as soon the phys nic
> > renaming bug is solved.
>
> The bug is coming from the kernel and the network namespace life cycle.
>
> As we changed
So some more testing today. Here's what happens:
When i have one container up with my host network restart trick,
everything's fine, i can download gigas of data without problem.
Starting a second one, redo the network trick to have network in this one
either, everything looks ok.
About 5minutes la
On 04/17/2011 09:47 AM, Ulli Horlacher wrote:
>
> I will integrate the other lxc basic commands as soon the phys nic
> renaming bug is solved.
The bug is coming from the kernel and the network namespace life cycle.
When the network namespace dies, the physical nic is moved back to the
host. Unfo
On 04/10/2011 12:20 PM, Gordon Henderson wrote:
> I have a program that calls sched_setscheduler - however it fails when run
> inside a container - it doesn't overly impact anything, but I'm wondering
> if it's because I've missed something or that it's just not supported?
It is possible it collid
Quoting Daniel Lezcano (daniel.lezc...@free.fr):
> On 04/06/2011 04:05 PM, Serge E. Hallyn wrote:
> >Quoting Daniel Lezcano (daniel.lezc...@free.fr):
> >>>What do you think is the best way to do this? We could allow the user
> >>>to specify a 'firstboot' script, which gets copied into root directo
On 04/06/2011 04:05 PM, Serge E. Hallyn wrote:
> Quoting Daniel Lezcano (daniel.lezc...@free.fr):
>>> What do you think is the best way to do this? We could allow the user
>>> to specify a 'firstboot' script, which gets copied into root directory
>>> of the container. Maybe boot the container wh
Thanks, help is really appreciated.
Cheers,
Olivier
On Sun, Apr 17, 2011 at 8:39 AM, Geordy Korte wrote:
> Hi,
>
> Thought about it some more and i think it might be an advanced esx feature
> that restricts this. Basically a couple of adv features block spoofing and
> mac changes on a vhost. I