[lxc-users] Unavailable loop devices
Michael H. Warfield
mhw at WittsEnd.com
Tue May 6 15:40:48 UTC 2014
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!
-------------- 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/8eaef16b/attachment.sig>
More information about the lxc-users
mailing list