Re: [Lxc-users] lxc on Fedora 15

2011-05-31 Thread Ramez Hanna
On Sat, May 28, 2011 at 3:33 PM, Ramez Hanna rha...@informatiq.org wrote:

 I have failed to start a container on f15 although it worked fine on 14
 here is the log
 ==snip
 [root@hovercraft boss]# cat lxc.log
 lxc-start 1306584262.160 DEBUG lxc_conf - allocated pty '/dev/pts/9' (4/5)
 lxc-start 1306584262.160 DEBUG lxc_conf - allocated pty '/dev/pts/10' (6/7)
 lxc-start 1306584262.160 DEBUG lxc_conf - allocated pty '/dev/pts/11' (8/9)
 lxc-start 1306584262.160 DEBUG lxc_conf - allocated pty '/dev/pts/12'
 (10/11)
 lxc-start 1306584262.160 INFO lxc_conf - tty's configured
 lxc-start 1306584262.160 ERROR lxc_caps - failed to cap_get_flag: Invalid
 argument
 lxc-start 1306584262.160 DEBUG lxc_console - using '/dev/tty' as console
 lxc-start 1306584262.160 DEBUG lxc_start - sigchild handler set
 lxc-start 1306584262.161 INFO lxc_start - 'boss' is initialized
 lxc-start 1306584262.161 ERROR lxc_namespace - failed to clone(0x6c02):
 Operation not permitted
 lxc-start 1306584262.161 ERROR lxc_start - Operation not permitted - failed
 to fork into a new namespace
 lxc-start 1306584262.161 ERROR lxc_start - failed to spawn 'boss'
 lxc-start 1306584262.161 DEBUG lxc_cgroup - using cgroup mounted at
 '/sys/fs/cgroup/systemd'
 lxc-start 1306584262.161 ERROR lxc_cgroup - No such file or directory -
 failed to remove cgroup '/sys/fs/cgroup/systemd/boss'
 == end

 mounts
 [root@hovercraft boss]# mount |grep cgroup
 tmpfs on /sys/fs/cgroup type tmpfs
 (rw,nosuid,nodev,noexec,relatime,mode=755)
 cgroup on /sys/fs/cgroup/systemd type cgroup
 (rw,nosuid,nodev,noexec,relatime,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
 cgroup on /sys/fs/cgroup/cpuset type cgroup
 (rw,nosuid,nodev,noexec,relatime,cpuset)
 cgroup on /sys/fs/cgroup/ns type cgroup
 (rw,nosuid,nodev,noexec,relatime,ns)
 cgroup on /sys/fs/cgroup/cpu type cgroup
 (rw,nosuid,nodev,noexec,relatime,cpu)
 cgroup on /sys/fs/cgroup/cpuacct type cgroup
 (rw,nosuid,nodev,noexec,relatime,cpuacct)
 cgroup on /sys/fs/cgroup/memory type cgroup
 (rw,nosuid,nodev,noexec,relatime,memory)
 cgroup on /sys/fs/cgroup/devices type cgroup
 (rw,nosuid,nodev,noexec,relatime,devices)
 cgroup on /sys/fs/cgroup/freezer type cgroup
 (rw,nosuid,nodev,noexec,relatime,freezer)
 cgroup on /sys/fs/cgroup/net_cls type cgroup
 (rw,nosuid,nodev,noexec,relatime,net_cls)
 cgroup on /sys/fs/cgroup/blkio type cgroup
 (rw,nosuid,nodev,noexec,relatime,blkio)

 it looks like lxc is trying to create the container's cgroup under systemd
 which seems to be the wrong location
 any leads on how can i debug further
 how does lxc find where cgroup is mounted?

 see bug https://bugzilla.redhat.com/show_bug.cgi?id=683667



upgraded to lxc-0.7.4.1-1.1.x86_64

[root@hovercraft ~]# lxc-start -n boss -l DEBUG -o log
lxc-start: open /sys/fs/cgroup/systemd/boss/devices.deny : No such file or
directory
lxc-start: failed to setup the cgroups for 'boss'
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn 'boss'

[root@hovercraft ~]# cat log
lxc-start 1306828803.471 DEBUG lxc_conf - allocated pty '/dev/pts/9' (4/5)
lxc-start 1306828803.471 DEBUG lxc_conf - allocated pty '/dev/pts/10' (6/7)
lxc-start 1306828803.471 DEBUG lxc_conf - allocated pty '/dev/pts/11' (8/9)
lxc-start 1306828803.471 DEBUG lxc_conf - allocated pty '/dev/pts/12'
(10/11)
lxc-start 1306828803.471 INFO lxc_conf - tty's configured
lxc-start 1306828803.471 DEBUG lxc_console - using '/dev/tty' as console
lxc-start 1306828803.471 DEBUG lxc_start - sigchild handler set
lxc-start 1306828803.471 INFO lxc_start - 'boss' is initialized
lxc-start 1306828803.478 DEBUG lxc_cgroup - using cgroup mounted at
'/sys/fs/cgroup/systemd'
lxc-start 1306828803.479 DEBUG lxc_cgroup - cgroup flags is 0x2
lxc-start 1306828803.485 INFO lxc_conf - network has been setup
lxc-start 1306828803.485 DEBUG lxc_conf - mounted '/var/lib/lxc/boss/rootfs'
on '/usr/lib64/lxc/rootfs'
lxc-start 1306828803.485 DEBUG lxc_conf - mounted 'proc' on
'/usr/lib64/lxc/rootfs//proc', type 'proc'
lxc-start 1306828803.486 DEBUG lxc_conf - mounted 'devpts' on
'/usr/lib64/lxc/rootfs//dev/pts', type 'devpts'
lxc-start 1306828803.486 DEBUG lxc_conf - mounted 'sysfs' on
'/usr/lib64/lxc/rootfs//sys', type 'sysfs'
lxc-start 1306828803.486 INFO lxc_conf - mount points have been setup
lxc-start 1306828803.486 DEBUG lxc_cgroup - using cgroup mounted at
'/sys/fs/cgroup/systemd'
lxc-start 1306828803.486 ERROR lxc_cgroup - open
/sys/fs/cgroup/systemd/boss/devices.deny : No such file or directory
lxc-start 1306828803.486 ERROR lxc_conf - failed to setup the cgroups for
'boss'
lxc-start 1306828803.486 ERROR lxc_start - failed to setup the container
lxc-start 1306828803.486 ERROR lxc_sync - invalid sequence number 1.
expected 2
lxc-start 1306828803.486 ERROR lxc_start - failed to spawn 'boss'
lxc-start 1306828803.486 DEBUG lxc_cgroup - using cgroup mounted at
'/sys/fs/cgroup/systemd'
lxc-start 1306828803.491 DEBUG lxc_cgroup - 

Re: [Lxc-users] lxc on Fedora 15

2011-05-31 Thread Ramez Hanna
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



On Tue, May 31, 2011 at 11:00 AM, Ramez Hanna rha...@informatiq.org wrote:

 On Sat, May 28, 2011 at 3:33 PM, Ramez Hanna rha...@informatiq.orgwrote:

 I have failed to start a container on f15 although it worked fine on 14
 here is the log
 ==snip
 [root@hovercraft boss]# cat lxc.log
 lxc-start 1306584262.160 DEBUG lxc_conf - allocated pty '/dev/pts/9' (4/5)
 lxc-start 1306584262.160 DEBUG lxc_conf - allocated pty '/dev/pts/10'
 (6/7)
 lxc-start 1306584262.160 DEBUG lxc_conf - allocated pty '/dev/pts/11'
 (8/9)
 lxc-start 1306584262.160 DEBUG lxc_conf - allocated pty '/dev/pts/12'
 (10/11)
 lxc-start 1306584262.160 INFO lxc_conf - tty's configured
 lxc-start 1306584262.160 ERROR lxc_caps - failed to cap_get_flag: Invalid
 argument
 lxc-start 1306584262.160 DEBUG lxc_console - using '/dev/tty' as console
 lxc-start 1306584262.160 DEBUG lxc_start - sigchild handler set
 lxc-start 1306584262.161 INFO lxc_start - 'boss' is initialized
 lxc-start 1306584262.161 ERROR lxc_namespace - failed to
 clone(0x6c02): Operation not permitted
 lxc-start 1306584262.161 ERROR lxc_start - Operation not permitted -
 failed to fork into a new namespace
 lxc-start 1306584262.161 ERROR lxc_start - failed to spawn 'boss'
 lxc-start 1306584262.161 DEBUG lxc_cgroup - using cgroup mounted at
 '/sys/fs/cgroup/systemd'
 lxc-start 1306584262.161 ERROR lxc_cgroup - No such file or directory -
 failed to remove cgroup '/sys/fs/cgroup/systemd/boss'
 == end

 mounts
 [root@hovercraft boss]# mount |grep cgroup
 tmpfs on /sys/fs/cgroup type tmpfs
 (rw,nosuid,nodev,noexec,relatime,mode=755)
 cgroup on /sys/fs/cgroup/systemd type cgroup
 (rw,nosuid,nodev,noexec,relatime,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
 cgroup on /sys/fs/cgroup/cpuset type cgroup
 (rw,nosuid,nodev,noexec,relatime,cpuset)
 cgroup on /sys/fs/cgroup/ns type cgroup
 (rw,nosuid,nodev,noexec,relatime,ns)
 cgroup on /sys/fs/cgroup/cpu type cgroup
 (rw,nosuid,nodev,noexec,relatime,cpu)
 cgroup on /sys/fs/cgroup/cpuacct type cgroup
 (rw,nosuid,nodev,noexec,relatime,cpuacct)
 cgroup on /sys/fs/cgroup/memory type cgroup
 (rw,nosuid,nodev,noexec,relatime,memory)
 cgroup on /sys/fs/cgroup/devices type cgroup
 (rw,nosuid,nodev,noexec,relatime,devices)
 cgroup on /sys/fs/cgroup/freezer type cgroup
 (rw,nosuid,nodev,noexec,relatime,freezer)
 cgroup on /sys/fs/cgroup/net_cls type cgroup
 (rw,nosuid,nodev,noexec,relatime,net_cls)
 cgroup on /sys/fs/cgroup/blkio type cgroup
 (rw,nosuid,nodev,noexec,relatime,blkio)

 it looks like lxc is trying to create the container's cgroup under systemd
 which seems to be the wrong location
 any leads on how can i debug further
 how does lxc find where cgroup is mounted?

 see bug https://bugzilla.redhat.com/show_bug.cgi?id=683667



 upgraded to lxc-0.7.4.1-1.1.x86_64

 [root@hovercraft ~]# lxc-start -n boss -l DEBUG -o log
 lxc-start: open /sys/fs/cgroup/systemd/boss/devices.deny : No such file or
 directory
 lxc-start: failed to setup the cgroups for 'boss'
 lxc-start: failed to setup the container
 lxc-start: invalid sequence number 1. expected 2

 lxc-start: failed to spawn 'boss'

 [root@hovercraft ~]# cat log
 lxc-start 1306828803.471 DEBUG lxc_conf - allocated pty '/dev/pts/9' (4/5)
 lxc-start 1306828803.471 DEBUG lxc_conf - allocated pty '/dev/pts/10' (6/7)
 lxc-start 1306828803.471 DEBUG lxc_conf - allocated pty '/dev/pts/11' (8/9)
 lxc-start 1306828803.471 DEBUG lxc_conf - allocated pty '/dev/pts/12'
 (10/11)
 lxc-start 1306828803.471 INFO lxc_conf - tty's configured
 lxc-start 1306828803.471 DEBUG lxc_console - using '/dev/tty' as console
 lxc-start 1306828803.471 DEBUG lxc_start - sigchild handler set
 lxc-start 1306828803.471 INFO lxc_start - 'boss' is initialized
 lxc-start 1306828803.478 DEBUG lxc_cgroup - using cgroup mounted at
 '/sys/fs/cgroup/systemd'
 lxc-start 1306828803.479 DEBUG lxc_cgroup - cgroup flags is 0x2
 lxc-start 1306828803.485 INFO lxc_conf - network has been setup
 lxc-start 1306828803.485 DEBUG lxc_conf - mounted
 '/var/lib/lxc/boss/rootfs' on '/usr/lib64/lxc/rootfs'
 lxc-start 1306828803.485 DEBUG lxc_conf - mounted 'proc' on
 '/usr/lib64/lxc/rootfs//proc', type 'proc'
 lxc-start 1306828803.486 DEBUG lxc_conf - mounted 'devpts' on
 '/usr/lib64/lxc/rootfs//dev/pts', type 'devpts'
 lxc-start 1306828803.486 DEBUG lxc_conf - mounted 'sysfs' on
 '/usr/lib64/lxc/rootfs//sys', type 'sysfs'
 lxc-start 1306828803.486 INFO lxc_conf - mount points have been setup
 lxc-start 1306828803.486 DEBUG lxc_cgroup - using cgroup mounted at
 '/sys/fs/cgroup/systemd'
 lxc-start 1306828803.486 ERROR lxc_cgroup - open
 

Re: [Lxc-users] lxc on Fedora 15

2011-05-31 Thread Daniel Lezcano
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.

Does systemd run lxc within a cgroup which is not the root cgroup ?


--
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


Re: [Lxc-users] lxc on Fedora 15

2011-05-31 Thread Ramez Hanna
On Tue, May 31, 2011 at 2:07 PM, Daniel Lezcano daniel.lezc...@free.frwrote:

 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
--
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


Re: [Lxc-users] lxc on Fedora 15

2011-05-31 Thread Daniel Lezcano
On 05/31/2011 01:44 PM, Ramez Hanna wrote:
 On Tue, May 31, 2011 at 2:07 PM, Daniel Lezcanodaniel.lezc...@free.frwrote:

 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.

--
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


Re: [Lxc-users] lxc on Fedora 15

2011-05-31 Thread Ramez Hanna
On Tue, May 31, 2011 at 2:54 PM, Daniel Lezcano daniel.lezc...@free.frwrote:

 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.


if there is anything i can investigate for you just let me know
--
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


Re: [Lxc-users] [Patch ] lxc-fedora.in

2011-05-31 Thread Ramez Hanna
On Mon, May 30, 2011 at 11:00 AM, Daniel Lezcano daniel.lezc...@free.frwrote:

 On 05/30/2011 09:32 AM, Ramez Hanna wrote:

 hi,

 here is my lxc-fedora script again based on request from Daniel Lezcano
 it has been tested to work on fedora and ubuntu hosts
 it was tested to create fedora 14 and 13 guests (not f15 yet)

 i had submitted it as a merge request earlier to gitorious repo
 lxc-mainline

 this script has extra args to the other scripts so it won't work directly
 through the lxc-create -t
 it can be modified to do that but i am not sure if i should spin off
 several
 ones with the release hardcoded in them like with debian/ubuntu templates


 Yep, there is a some work to do with the ubuntu templates to factor the
 code.
 I would suggest you default to one fedora version if no release version is
 specified.


 I inlined the code in the email so it will be easier to review.
 Please in the future make sure the patch is inlined and conforming to the
 CONTRIBUTING patch submit, that is with the author, subject and
 signed-off-by.

  #!/bin/bash

 #
 # template script for generating fedora container for LXC
 #

 #
 # lxc: linux Container library

 # Authors:
 # Daniel Lezcano daniel.lezc...@free.fr
 # Ramez Hanna rha...@informatiq.org

 # This library is free software; you can redistribute it and/or
 # modify it under the terms of the GNU Lesser General Public
 # License as published by the Free Software Foundation; either
 # version 2.1 of the License, or (at your option) any later version.

 # This library is distributed in the hope that it will be useful,
 # but WITHOUT ANY WARRANTY; without even the implied warranty of
  # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 # Lesser General Public License for more details.

 # You should have received a copy of the GNU Lesser General Public
 # License along with this library; if not, write to the Free Software
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

 #Configurations
 arch=$(arch)
 cache_base=/var/cache/lxc/fedora/$arch


 shouldn't it be /var/cache/lxc/$release/$arch ?

no because later cache=$cache_base/$release when release is actually known


  default_path=/var/lib/lxc
 root_password=rooter
 lxc_network_type=veth
 lxc_network_link=virbr0

 # is this fedora?
 [ -f /etc/fedora-release ]  is_fedora=true

 configure_fedora()
 {

# disable selinux in fedora
mkdir -p $rootfs_path/selinux
echo 0  $rootfs_path/selinux/enforce

   # configure the network using the dhcp
cat EOF  ${rootfs_path}/etc/sysconfig/network-scripts/ifcfg-eth0
 DEVICE=eth0
 BOOTPROTO=dhcp
 ONBOOT=yes
 HOSTNAME=${UTSNAME}
 NM_CONTROLLED=no
 TYPE=Ethernet
 MTU=${MTU}
 EOF

# set the hostname
cat EOF  ${rootfs_path}/etc/sysconfig/network
 NETWORKING=yes
 HOSTNAME=${UTSNAME}
 EOF

# set minimal hosts
cat EOF  $rootfs_path/etc/hosts
 127.0.0.1 localhost $name
 EOF

sed -i 's|.sbin.start_udev||' ${rootfs_path}/etc/rc.sysinit
sed -i 's|.sbin.start_udev||' ${rootfs_path}/etc/rc.d/rc.sysinit
chroot ${rootfs_path} chkconfig udev-post off
chroot ${rootfs_path} chkconfig network on

dev_path=${rootfs_path}/dev
rm -rf $dev_path
mkdir -p $dev_path
mknod -m 666 ${dev_path}/null c 1 3
mknod -m 666 ${dev_path}/zero c 1 5
mknod -m 666 ${dev_path}/random c 1 8
mknod -m 666 ${dev_path}/urandom c 1 9
mkdir -m 755 ${dev_path}/pts
mkdir -m 1777 ${dev_path}/shm
mknod -m 666 ${dev_path}/tty c 5 0
mknod -m 666 ${dev_path}/tty0 c 4 0
mknod -m 666 ${dev_path}/tty1 c 4 1
mknod -m 666 ${dev_path}/tty2 c 4 2
mknod -m 666 ${dev_path}/tty3 c 4 3
mknod -m 666 ${dev_path}/tty4 c 4 4
mknod -m 600 ${dev_path}/console c 5 1
mknod -m 666 ${dev_path}/full c 1 7
mknod -m 600 ${dev_path}/initctl p
mknod -m 666 ${dev_path}/ptmx c 5 2

echo setting root passwd to $root_password
echo root:$root_password | chroot $rootfs_path chpasswd

return 0
 }

 download_fedora()
 {

# check the mini fedora was not already downloaded
INSTALL_ROOT=$cache/partial
mkdir -p $INSTALL_ROOT
if [ $? -ne 0 ]; then
echo Failed to create '$INSTALL_ROOT' directory
return 1
fi

# download a mini fedora into a cache
echo Downloading fedora minimal ...
YUM=yum --installroot $INSTALL_ROOT -y --nogpgcheck
PKG_LIST=yum initscripts passwd rsyslog vim-minimal dhclient chkconfig
 rootfiles policycoreutils
RELEASE_URL=
 http://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/releases/$release/Everything/x86_64/os/Packages/fedora-release-$release-1.noarch.rpm
 


  s/x86_64/$arch ?




curl $RELEASE_URL  $INSTALL_ROOT/fedora-release-$release.noarch.rpm

mkdir -p $INSTALL_ROOT/var/lib/rpm
rpm --root $INSTALL_ROOT  --initdb
rpm --root $INSTALL_ROOT -ivh
 $INSTALL_ROOT/fedora-release-$release.noarch.rpm
$YUM install $PKG_LIST

if [ $? -ne 0 ]; then
echo Failed to download the rootfs, aborting.
 

[Lxc-users] rootfs=/

2011-05-31 Thread erkan yanar
Moin,
Im doing application-container and I don't use rootfs at all.
So lxc is used to make the cgroup-stuff and some interfaces.
I wonder if Im doing something totally wrong *not* setting rootfs?

Is there a way to deny access to logical volumes with a cgroup?
I didn't managed it to achieve it with the devices namespace.

Regards
Erkan
lxc-0.6.5-1.2.31 on 2.6.32.27-0.2-default

-- 
über den grenzen muß die freiheit wohl wolkenlos sein 

--
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


Re: [Lxc-users] lxc on Fedora 15

2011-05-31 Thread Serge Hallyn
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.frwrote:
 
  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

--
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


Re: [Lxc-users] lxc on Fedora 15

2011-05-31 Thread Clemens Perz

Hi!

Just hit something similar today. Ubuntu Lucid had a kernel update to
2.6.32-32 and now my dev container refuses to start. lxc tools are still
at 0.7.1.

On 05/28/2011 02:33 PM, Ramez Hanna wrote:
 lxc-start 1306584262.161 ERROR lxc_namespace - failed to clone(0x6c02):
 Operation not permitted
 lxc-start 1306584262.161 ERROR lxc_start - Operation not permitted - failed
 to fork into a new namespace
 lxc-start 1306584262.161 ERROR lxc_start - failed to spawn 'boss'


lxc-start 1306854843.605 ERRORlxc_namespace - failed to
clone(0x6c02): Invalid argument
lxc-start 1306854843.605 ERRORlxc_start - Bad file descriptor -
failed to fork into a new namespace

Going back to kernel 2.6.32-31 makes it work again.

Cheers,
Clemens

--
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


Re: [Lxc-users] lxc on Fedora 15

2011-05-31 Thread Serge Hallyn
Jinkeys.  Could you please file a bug against 'linux (Ubuntu)' about
this?  Or file it against lxc and I'll retarget it.

thanks,
-serge

Quoting Clemens Perz (cp...@gmx.net):
 
 Hi!
 
 Just hit something similar today. Ubuntu Lucid had a kernel update to
 2.6.32-32 and now my dev container refuses to start. lxc tools are still
 at 0.7.1.
 
 On 05/28/2011 02:33 PM, Ramez Hanna wrote:
  lxc-start 1306584262.161 ERROR lxc_namespace - failed to clone(0x6c02):
  Operation not permitted
  lxc-start 1306584262.161 ERROR lxc_start - Operation not permitted - failed
  to fork into a new namespace
  lxc-start 1306584262.161 ERROR lxc_start - failed to spawn 'boss'
 
 
 lxc-start 1306854843.605 ERRORlxc_namespace - failed to
 clone(0x6c02): Invalid argument
 lxc-start 1306854843.605 ERRORlxc_start - Bad file descriptor -
 failed to fork into a new namespace
 
 Going back to kernel 2.6.32-31 makes it work again.
 
 Cheers,
 Clemens
 
 --
 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

--
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


Re: [Lxc-users] lxc on Fedora 15

2011-05-31 Thread Ramez Hanna
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 ?
--
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


Re: [Lxc-users] lxc on Fedora 15

2011-05-31 Thread Serge Hallyn
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.

-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


[Lxc-users] two NICs in container

2011-05-31 Thread Mihamina Rakotomandimby
Hi all,

When I create a container, I usually created it with only one NIC:
  [...]
  lxc.network.type = veth
  lxc.network.flags = up
  lxc.network.link = br0
  lxc.network.ipv4 = 41.204.96.2/28
  lxc.network.name = eth0
  [...]

Now I want to create a container with 2 NICs
On the host I have another bridge br1, and I wan the 2nd container
interface to be eth1

How to?

-- 
RMA.

--
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