[lxc-users] Unavailable loop devices
CDR
venefax at gmail.com
Tue May 6 16:20:41 UTC 2014
The current SUSE 11 SP3 templates are useless.
The on-line repository is corrupt and since Novell sold the company,
there is no maintenance.
I had to install the container from the ISO files.
I think SLES is an abandoned distribution. Fortunately, OpenSUSE seems vibrant.
I have a single client that loves SUSE.
On Tue, May 6, 2014 at 11:40 AM, Michael H. Warfield <mhw at wittsend.com> wrote:
> On Tue, 2014-05-06 at 11:36 -0400, Michael H. Warfield wrote:
>> On Tue, 2014-05-06 at 11:20 -0400, CDR wrote:
>> > Well, I just found real business case where your theory falls flat.
>> > In a Suse Enterprise container, the only way to allow the owner of the
>> > container to install new packages, is to mount permanently the
>> > original ISO and the original SDK iso, otherwise zypper would not
>> > work. The updates come from the internet, but new base packages you
>> > need to fetch them from the ISO. I am not sure if zypper just mounts
>> > and dismounts them on the sport and frees the loop device.
>> > Suppose my customer clones 50 times a container, this would blow
>> > through the available loop devices.
>
>> Yeah, I ran into that on some mainframes using full hardware VM's. We
>> had zLinux Suse SEL running as a VM on a zSeries mainframe. Same issue.
>> Same solution. The host services provides the mounted images (they set
>> the container up in the first place) either though full mounts or bind
>> mounts.
>
>> That's actually an easier and more reliable solution which I've seen
>> used in practice with HW VM's. One image in the host can service
>> multiple HW VM's and containers. I've even seen that done with some
>> RHEL instantiations in HW VM's. That's a fixed (pun and dual meaning
>> fully intended here) case and I don't see where we need anything
>> different here.
>
> I should also add that, if that were a hard requirement for Suse which
> absolutely could not be worked around in the host, the Suse maintainers
> should add that option to their template and their configuration include
> for all the Suse templates. It still should not be part of the general
> default for all containers and all distros.
>
> Regards,
> Mike
>
>> > Yours
>> >
>> > Philip
>> >
>> > On Tue, May 6, 2014 at 11:06 AM, Michael H. Warfield <mhw at wittsend.com> wrote:
>> > > On Tue, 2014-05-06 at 10:33 -0400, CDR wrote:
>> > >> Dear Mike
>> > >> It does work indeed.
>> > >> I suggest that the developers add these two lines to the sample configuration.
>> > >
>> > > It's been discussed and passed on for reasons for the time being. The
>> > > need for it in containers is relatively limited.
>> > >
>> > > There also are currently some isolation issues between containers with
>> > > the loop devices. i.e. Running losetup -l currently dumps the
>> > > information of all the loop devices system wide even if you are in a
>> > > container. I'm not sure at this point in time if you did a losetup -d
>> > > on a loop device in a container, which had not setup the loop device,
>> > > what would happen. I hadn't previously tested that yet but... It seems
>> > > to "fail" silently as if it succeeded but doesn't really do anything.
>> > > It's not clean. In most cases, using losetup to automatically managed
>> > > the appropriate loop device does the right thing and avoids collisions.
>> > >
>> > > Then there's the issue of the number of available loop devices. Because
>> > > they're shared, if one container consumes 3 and another container
>> > > requires 2, the second one is going to fail in the default configuration
>> > > (Default is 4 - I run with 64).
>> > >
>> > > I would personally advise only adding loop devices to those containers
>> > > that absolutely need them. I don't think they are appropriate as
>> > > default devices at this time when most containers don't even need them.
>> > > I would especially avoid them in cases where you may be hosting
>> > > containers for others. I have about a half a dozen groups of containers
>> > > I'm hosting for other friends and relatives and business associates on a
>> > > bit colocated server I run. I wouldn't enable loop devices in any of
>> > > those containers unless it was specifically requested and even then only
>> > > for the duration of the need. They know. They've never asked.
>> > > Certainly no need for that to be in a default configuration.
>> > >
>> > > Yes that limits the container owners ability to mount images but that's
>> > > really not that common in practice outside of developers.
>> > >
>> > > Building containers within containers, you may also run into problems
>> > > with certain package installs and builds having unusual requirements for
>> > > capabilities (setfcap comes immediately to mind). I run into this when
>> > > I created containers to build NST (Network Security Toolkit) images, in
>> > > addition to the expected loop device issues. That's another thing that
>> > > should only be enabled on those specific containers requiring it.
>> > >
>> > >> Yours
>> > >> Philip
>> > >
>> > > Regards,
>> > > Mike
>> > >
>> > >> On Tue, May 6, 2014 at 9:28 AM, Michael H. Warfield <mhw at wittsend.com> wrote:
>> > >> > On Tue, 2014-05-06 at 06:25 -0400, CDR wrote:
>> > >> >> Dear Friends
>> > >> >
>> > >> >> I succesfully created a SLES 11 SP3 container, but when I try to do this
>> > >> >
>> > >> >> mount -o loop /images/SLE-11-SP3-SDK-DVD-x86_64-GM-DVD1.iso /media
>> > >> >
>> > >> >> mount: Could not find any loop device. Maybe this kernel does not know
>> > >> >> about the loop device? (If so, recompile or `modprobe loop'.)
>> > >> >
>> > >> > Add the following to your container configuration file:
>> > >> >
>> > >> > lxc.cgroup.devices.allow = c 10:137 rwm # loop-control
>> > >> > lxc.cgroup.devices.allow = b 7:* rwm # loop*
>> > >> >
>> > >> > Then make sure you have the following devices in your container /dev
>> > >> > directory...
>> > >> >
>> > >> > brw-rw----. 1 root disk 7, 0 May 2 13:03 /dev/loop0
>> > >> > brw-rw----. 1 root disk 7, 1 May 2 13:03 /dev/loop1
>> > >> > brw-rw----. 1 root disk 7, 2 May 2 13:03 /dev/loop2
>> > >> > brw-rw----. 1 root disk 7, 3 May 2 13:03 /dev/loop3
>> > >> > crw-------. 1 root root 10, 237 May 2 13:03 /dev/loop-control
>> > >> >
>> > >> > Regards,
>> > >> > Mike
>> > >> >
>> > >> >> My host is Fedora 20 and the LXC version is
>> > >> >
>> > >> >> rpm -qa | grep lxc
>> > >> >> libvirt-daemon-lxc-1.1.3.4-4.fc20.x86_64
>> > >> >> libvirt-daemon-driver-lxc-1.1.3.4-4.fc20.x86_64
>> > >> >> lxc-devel-1.0.0-1.fc20.x86_64
>> > >> >> lxc-debuginfo-1.0.0-1.fc20.x86_64
>> > >> >> lxc-libs-1.0.0-1.fc20.x86_64
>> > >> >> lxc-1.0.0-1.fc20.x86_64
>> > >> >
>> > >> >> the configuration is:
>> > >> >>
>> > >> >> lxc.start.auto = 0
>> > >> >> lxc.start.delay = 5
>> > >> >> lxc.start.order = 10
>> > >> >>
>> > >> >> # When using LXC with apparmor, uncomment the next line to run unconfined:
>> > >> >> #lxc.aa_profile = unconfined
>> > >> >>
>> > >> >> lxc.cgroup.devices.deny = a
>> > >> >> # /dev/null and zero
>> > >> >> lxc.cgroup.devices.allow = c 1:3 rwm
>> > >> >> lxc.cgroup.devices.allow = c 1:5 rwm
>> > >> >> # consoles
>> > >> >> lxc.cgroup.devices.allow = c 5:1 rwm
>> > >> >> lxc.cgroup.devices.allow = c 5:0 rwm
>> > >> >> lxc.cgroup.devices.allow = c 4:0 rwm
>> > >> >> lxc.cgroup.devices.allow = c 4:1 rwm
>> > >> >> # /dev/{,u}random
>> > >> >> lxc.cgroup.devices.allow = c 1:9 rwm
>> > >> >> lxc.cgroup.devices.allow = c 1:8 rwm
>> > >> >> lxc.cgroup.devices.allow = c 136:* rwm
>> > >> >> lxc.cgroup.devices.allow = c 5:2 rwm
>> > >> >> # rtc
>> > >> >> lxc.cgroup.devices.allow = c 254:0 rwm
>> > >> >>
>> > >> >> # mounts point
>> > >> >> lxc.mount.entry = proc proc proc nodev,noexec,nosuid 0 0
>> > >> >> lxc.mount.entry = sysfs sys sysfs defaults 0 0
>> > >> >> lxc.mount.entry = /images /var/lib/lxc/utel-kde/rootfs/images none bind 0 0
>> > >> >>
>> > >> >>
>> > >> >> lxc.network.type=macvlan
>> > >> >> lxc.network.macvlan.mode=bridge
>> > >> >> lxc.network.link=eth1
>> > >> >> lxc.network.flags=up
>> > >> >> lxc.network.hwaddr = e2:91:a8:17:97:e4
>> > >> >> lxc.network.ipv4 = 0.0.0.0/21
>> > >> >>
>> > >> >>
>> > >> >> How do make the kernel loop module available for the container?
>> > >> >>
>> > >> >> Yours
>> > >> >> Philip
>> > >> >> _______________________________________________
>> > >> >> lxc-users mailing list
>> > >> >> lxc-users at lists.linuxcontainers.org
>> > >> >> http://lists.linuxcontainers.org/listinfo/lxc-users
>> > >> >
>> > >> > --
>> > >> > Michael H. Warfield (AI4NB) | (770) 978-7061 | mhw at 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!
>> > >> >
>> > >> >
>> > >> > _______________________________________________
>> > >> > lxc-users mailing list
>> > >> > lxc-users at lists.linuxcontainers.org
>> > >> > http://lists.linuxcontainers.org/listinfo/lxc-users
>> > >> _______________________________________________
>> > >> lxc-users mailing list
>> > >> lxc-users at lists.linuxcontainers.org
>> > >> http://lists.linuxcontainers.org/listinfo/lxc-users
>> > >
>> > > --
>> > > Michael H. Warfield (AI4NB) | (770) 978-7061 | mhw at 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!
>> > >
>> > >
>> > > _______________________________________________
>> > > lxc-users mailing list
>> > > lxc-users at lists.linuxcontainers.org
>> > > http://lists.linuxcontainers.org/listinfo/lxc-users
>> > _______________________________________________
>> > lxc-users mailing list
>> > lxc-users at lists.linuxcontainers.org
>> > http://lists.linuxcontainers.org/listinfo/lxc-users
>>
>
> --
> Michael H. Warfield (AI4NB) | (770) 978-7061 | mhw at 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!
>
>
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
More information about the lxc-users
mailing list