[Lxc-users] autofs in lxc containers?
Hi, Anyone who successfully run autofs in lxc containers? Thanks. Fred -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] lxc on Fedora 15
On Tue, 2011-05-31 at 14:00 -0500, Serge Hallyn wrote:
Quoting Ramez Hanna (rha...@informatiq.org):
On Tue, May 31, 2011 at 5:38 PM, Serge Hallyn
serge.hal...@canonical.comwrote:
Quoting Daniel Lezcano (daniel.lezc...@free.fr):
On 05/31/2011 01:44 PM, Ramez Hanna wrote:
On Tue, May 31, 2011 at 2:07 PM, Daniel Lezcanodaniel.lezc...@free.fr
wrote:
On 05/31/2011 12:33 PM, Ramez Hanna wrote:
it seems that lxc cannot handle cgroups when capabilities are not
all
in
the
same mount
it fails now because it cannot write the devices.deny in the cgroup
if i comment out all the lxc.cgroup.devices lines in the config of
the
container then i can actually start it
I would think that the way lxc identifies the cgroup mount might be
the
part
that needs patching
Thanks for investigating.
The main problem is lxc is cgroup agnostic, so we should find a
solution
where we don't break that.
Maybe one solution would be to collect all the mount points found for
the
cgroup and try to find the right path when writing or reading from
one
cgroup file.
that is what i had in mind, tried looking into the code but my C
skills
are
next to zero
Does systemd run lxc within a cgroup which is not the root cgroup ?
the lxc-start command would run under $user/master/
(/sys/fs/cgroup/systemd/$user/$master)
and the container itself would run under $container_name
(/sys/fs/cgroup/systemd/$container_name)
so it would run the container in the root cgroup
ouch ! I have to install systemd on a test machine to check how systemd
plays with the cgroup.
I don't think the cgroup created by lxc should escape the cgroup the
command is assigned to.
Another similar - and easier to setup - thing we need to address is
running
on a system with libcgroup installed.
For both, I assume it'll basically come down to:
1. figure out the path of the cgroup we are in for each cgroup we care
about
2. create new child cgroup for ourselves in each of the above paths whic
is unique
3. track those through the lifetime of the container
So it just slightly complicates what's being done now.
-serge
how does libcgroup change things? does it also mount cgroup on different
points ?
Yes, in whatever way you ask it to.
I noticed this a couple of clicks back. Maybe even F13 where I had
libcgroup installed and it was mounting things, initially, in /cgroup
(or some such) before the kernel dudes created the mountpoint
in /sys/fs/cgroup. I got burned by it, even back then, and had to
disable libcgroup and do the manual mount stuff in fstab. That was back
months ago when we were having the controversy over whether cgroups
should be mounted under /cgroup or /dev/cgroup or /var/lib/cgroup
or /var/run/cgroup. I thought I raised the whole issue that these
things were in a hierarchy and not a flat mount even back then. Now
it's under the /sys/fs/cgroup mount point and we need to deal with this,
now. I've had to disable the devices.{allow|deny} options on several of
my host machines at this point. Is anyone working on a solution?
Daniel mentioned getting systemd running on a system but it's more
fundamental than that. Like you say, even setting up and enabling
libcgroup is going to be problematical and we need to play nicey nicey
with the other kids in the sandbox.
Regards,
Mike
-serge
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it!
signature.asc
Description: This is a digitally signed message part
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] lxc on Fedora 15
Quoting Michael H. Warfield (m...@wittsend.com):
On Tue, 2011-05-31 at 14:00 -0500, Serge Hallyn wrote:
Quoting Ramez Hanna (rha...@informatiq.org):
On Tue, May 31, 2011 at 5:38 PM, Serge Hallyn
serge.hal...@canonical.comwrote:
Quoting Daniel Lezcano (daniel.lezc...@free.fr):
On 05/31/2011 01:44 PM, Ramez Hanna wrote:
On Tue, May 31, 2011 at 2:07 PM, Daniel
Lezcanodaniel.lezc...@free.fr
wrote:
On 05/31/2011 12:33 PM, Ramez Hanna wrote:
it seems that lxc cannot handle cgroups when capabilities are not
all
in
the
same mount
it fails now because it cannot write the devices.deny in the
cgroup
if i comment out all the lxc.cgroup.devices lines in the config of
the
container then i can actually start it
I would think that the way lxc identifies the cgroup mount might
be
the
part
that needs patching
Thanks for investigating.
The main problem is lxc is cgroup agnostic, so we should find a
solution
where we don't break that.
Maybe one solution would be to collect all the mount points found
for
the
cgroup and try to find the right path when writing or reading from
one
cgroup file.
that is what i had in mind, tried looking into the code but my C
skills
are
next to zero
Does systemd run lxc within a cgroup which is not the root cgroup ?
the lxc-start command would run under $user/master/
(/sys/fs/cgroup/systemd/$user/$master)
and the container itself would run under $container_name
(/sys/fs/cgroup/systemd/$container_name)
so it would run the container in the root cgroup
ouch ! I have to install systemd on a test machine to check how
systemd
plays with the cgroup.
I don't think the cgroup created by lxc should escape the cgroup the
command is assigned to.
Another similar - and easier to setup - thing we need to address is
running
on a system with libcgroup installed.
For both, I assume it'll basically come down to:
1. figure out the path of the cgroup we are in for each cgroup we care
about
2. create new child cgroup for ourselves in each of the above paths
whic
is unique
3. track those through the lifetime of the container
So it just slightly complicates what's being done now.
-serge
how does libcgroup change things? does it also mount cgroup on different
points ?
Yes, in whatever way you ask it to.
I noticed this a couple of clicks back. Maybe even F13 where I had
libcgroup installed and it was mounting things, initially, in /cgroup
(or some such) before the kernel dudes created the mountpoint
in /sys/fs/cgroup. I got burned by it, even back then, and had to
disable libcgroup and do the manual mount stuff in fstab. That was back
months ago when we were having the controversy over whether cgroups
should be mounted under /cgroup or /dev/cgroup or /var/lib/cgroup
or /var/run/cgroup. I thought I raised the whole issue that these
things were in a hierarchy and not a flat mount even back then. Now
it's under the /sys/fs/cgroup mount point and we need to deal with this,
now. I've had to disable the devices.{allow|deny} options on several of
my host machines at this point. Is anyone working on a solution?
Not that I know of. I don't think it's fundamentally hard, though it
may get a bit dicy in principle. Just find the mountpoint for each
cgroup, and change each set/get in the lxc code to use the right
mountpoint.
Is this something you have time to take a stab at?
Daniel mentioned getting systemd running on a system but it's more
fundamental than that. Like you say, even setting up and enabling
libcgroup is going to be problematical and we need to play nicey nicey
with the other kids in the sandbox.
Regards,
Mike
-serge
--
Simplify data backup and recovery for your virtual environment with
vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it!
--
