Quoting Stéphane Graber (stgra...@ubuntu.com):
> This adds a new -i flag to lxc-info to print the container's IP
> addresses using get_ips().
>
> Example:
> $ lxc-info -n lxc-dev -s -p -i
> state: RUNNING
> pid:21331
> ip: 10.0.3.165
> ip: 2607:f2c0:f00f:2751:e9ca:842f:efa9:97d1
> ip:
Quoting Stéphane Graber (stgra...@ubuntu.com):
> Signed-off-by: Stéphane Graber
Acked-by: Serge E. Hallyn
> ---
> src/lxc/lxc_info.c | 38 +++---
> 1 file changed, 23 insertions(+), 15 deletions(-)
>
> diff --git a/src/lxc/lxc_info.c b/src/lxc/lxc_info.c
> inde
Quoting Christian Seiler (christ...@iwakd.de):
> No, previously, the kernel has behaved differently. As I said,
> on my 3.2 and 2.6.32 a mount -o remount,ro /bindmount without
> the bind option would only change the bind mount and not the
> entire filesystem.
My 3.2, 3.8 and 3.11 kernels all behav
This adds a new -i flag to lxc-info to print the container's IP
addresses using get_ips().
Example:
$ lxc-info -n lxc-dev -s -p -i
state: RUNNING
pid:21331
ip: 10.0.3.165
ip: 2607:f2c0:f00f:2751:e9ca:842f:efa9:97d1
ip: 2607:f2c0:f00f:2751:216:3eff:fe3a:f1c1
Signed-off-by: Stéphan
Signed-off-by: Stéphane Graber
---
src/lxc/lxc_info.c | 38 +++---
1 file changed, 23 insertions(+), 15 deletions(-)
diff --git a/src/lxc/lxc_info.c b/src/lxc/lxc_info.c
index e61ae63..ab3aacf 100644
--- a/src/lxc/lxc_info.c
+++ b/src/lxc/lxc_info.c
@@ -29,6 +29,7
Quoting Dwight Engen (dwight.en...@oracle.com):
> Hi guys,
>
> So the line:
>
> r = lxc_grow_array((void ***)&h->all_mount_points,
> &h->all_mount_point_capacity, k + 1, 4);
>
> in cgroup.c shows up in valgrind as a leak. I thought the appropriate
> fix was:
>
> diff --gi
Hi guys,
So the line:
r = lxc_grow_array((void ***)&h->all_mount_points,
&h->all_mount_point_capacity, k + 1, 4);
in cgroup.c shows up in valgrind as a leak. I thought the appropriate
fix was:
diff --git a/src/lxc/cgroup.c b/src/lxc/cgroup.c
index e27bc03..c5dc7e2 100644
Hi Serge,
>> Yes, I see what you mean, but this is definitely a change in the
>> behaviour of the kernel compared to previous versions. And that
>> also means that (see other thread) bind-mounting a rootfs onto
>> itself will not prevent a container from remounting the filesystem
>> readonly on sh
Quoting Christian Seiler (christ...@iwakd.de):
> Hi Serge,
>
> >>+ /* Read-only bind-mounting... In older kernels, doing that
> >>required
> >>+* to do one MS_BIND mount and then MS_REMOUNT|MS_RDONLY the
> >>same
> >>+* one. According to mount(2) manpage, MS_BIND
Hi Serge,
>> +/* Read-only bind-mounting... In older kernels, doing that
>> required
>> + * to do one MS_BIND mount and then MS_REMOUNT|MS_RDONLY the
>> same
>> + * one. According to mount(2) manpage, MS_BIND honors MS_RDONLY
>> from
>> + * kernel
On Thu, Sep 26, 2013 at 8:07 PM, Greg Kroah-Hartman
wrote:
>> That being said, our wish would be to support any combination of
>> OS's and frankly, I'd be slightly annoyed to tell the customer that
>> they can't do two Androids or we magically run out of bits.
>
> If you want to support "any" com
Quoting Christian Seiler (christ...@iwakd.de):
...
> + /* Read-only bind-mounting... In older kernels, doing that
> required
> + * to do one MS_BIND mount and then MS_REMOUNT|MS_RDONLY the
> same
> + * one. According to mount(2) manpage, MS_BIND honors MS_RDO
On Thu, Sep 26, 2013 at 4:56 PM, Greg Kroah-Hartman
wrote:
>> I suppose so, but now you take the assumption that there is no
>> need for running multiple Linux variants on the same host (say
>> Ubuntu and Android side by side). Is this something you would
>> not like to see done?
>
> You can do t
On Thu, Sep 26, 2013 at 11:25:56AM +0300, Janne Karhunen wrote:
> On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman
> wrote:
>
> >> In summary the situation with device hoptlug and containers sucks today,
> >> and we need to do something. Running a linux desktop in a container is
> >> a reason
On Thu, Sep 26, 2013 at 08:01:31PM +0300, Janne Karhunen wrote:
> That being said, our wish would be to support any combination of
> OS's and frankly, I'd be slightly annoyed to tell the customer that
> they can't do two Androids or we magically run out of bits.
If you want to support "any" combin
As I mentioned in another part of this thread, my use case is deploying
"linux desktops" to users as containers. The goal is to have the
container run unmodified distros, and to be able to run arbitrary code.
A tall order to be sure, and maybe not realistic, but I'm in research so
its good to
Hi,
On Thu, Sep 26, 2013 at 9:51 AM, Dwight Engen wrote:
> On Wed, 25 Sep 2013 17:57:02 -0400
> Stéphane Graber wrote:
>
> > On Wed, Sep 25, 2013 at 05:48:26PM -0400, S.Çağlar Onur wrote:
> > > Hey,
> > >
> > > It's not that important but I just wanted to learn your thoughts
> > > about startin
Quoting Dwight Engen (dwight.en...@oracle.com):
> On Wed, 25 Sep 2013 17:25:13 -0500
> Serge Hallyn wrote:
>
> > Quoting Dwight Engen (dwight.en...@oracle.com):
> > > Currently, a maximum of one LSM within LXC will be initialized and
> > > used. If in the future stacked LSMs become a reality, we
On Wed, 25 Sep 2013 17:57:02 -0400
Stéphane Graber wrote:
> On Wed, Sep 25, 2013 at 05:48:26PM -0400, S.Çağlar Onur wrote:
> > Hey,
> >
> > It's not that important but I just wanted to learn your thoughts
> > about starting to use more predictable version names for releases.
> > I was trying to
On Wed, 25 Sep 2013 17:25:13 -0500
Serge Hallyn wrote:
> Quoting Dwight Engen (dwight.en...@oracle.com):
> > Currently, a maximum of one LSM within LXC will be initialized and
> > used. If in the future stacked LSMs become a reality, we can
> > support it without changing the configuration syntax
Branch: refs/heads/master
Home: https://github.com/lxc/lxc
Commit: 566981770e840b9043f57dac15958a723413e688
https://github.com/lxc/lxc/commit/566981770e840b9043f57dac15958a723413e688
Author: Serge Hallyn
Date: 2013-09-26 (Thu, 26 Sep 2013)
Changed paths:
M src/lxc/lxccon
Branch: refs/heads/master
Home: https://github.com/lxc/lxc
Commit: 85db5535c346fcba1ff6c30835ebd3a95214da04
https://github.com/lxc/lxc/commit/85db5535c346fcba1ff6c30835ebd3a95214da04
Author: Dwight Engen
Date: 2013-09-26 (Thu, 26 Sep 2013)
Changed paths:
M src/lxc/lxccon
Quoting Serge Hallyn (serge.hal...@ubuntu.com):
> Quoting Dwight Engen (dwight.en...@oracle.com):
> > - change get_template_path() to only return NULL or non-NULL since one of
> > the callers was doing a free(-1) which caused the segfault. Handle the
> > NULL template case in the lxcapi_create(
>From conversations at Linux Plumbers Converence it became fairly clear
that one if not the roughest edge on containers today is dealing with
devices.
- Hotplug does not work.
- There seems to be no implementation that does a much beyond creating
setting up a static set of /dev entries today.
-
On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman
wrote:
>> In summary the situation with device hoptlug and containers sucks today,
>> and we need to do something. Running a linux desktop in a container is
>> a reasonably good example use case.
>
> No it isn't. I'd argue that this is a horri
On Wed, Sep 25, 2013 at 02:34:54PM -0700, Eric W. Biederman wrote:
> So the big issues for a device namespace to solve are filtering which
> devices a container has access to and being able to dynamically change
> which devices those are at run time (aka hotplug).
As _all_ devices are hotpluggable
26 matches
Mail list logo
