[lxc-users] Unavailable loop devices

Michael H. Warfield mhw at WittsEnd.com
Tue May 6 16:34:47 UTC 2014 

On Tue, 2014-05-06 at 12:20 -0400, CDR wrote:
> 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.

It's not an abandoned distro.  I don't think...  In fact, I was thinking
that a new release had just come out late last year but I guess it was
just the latest service pack to SEL 11.  Releases and service packs have
been few and far between, though, I'll admit.  SEL 11 is 5 years old
now.  Sigh...  I traded E-Mails with a couple of their developers
earlier this year.  They may be short handed and unable to response in a
way we would like, but we've all been there.  Fortunately, I'm no longer
involved in anything that requires SEL.

Regards,
Mike

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20140506/c3acecf2/attachment.sig>

More information about the lxc-users mailing list