Difference between pages "FAQ/Old" and "Linux Containers"

From Funtoo
< FAQ(Difference between pages)
Jump to navigation Jump to search
m (I believe that there was a word missing in *How do I become a Funtoo Developer*)
 
 
Line 1: Line 1:
== Top Questions ==
Linux Containers, or LXC, is a Linux feature that allows Linux to run one or more isolated virtual systems (with their own network interfaces, process namespace, user namespace, and power state) using a single Linux kernel on a single server.


=== Why use a Source-Based Linux Distribution like Funtoo Linux? ===
== Status ==


Using a source-based Linux distribution like Funtoo Linux could be likened to driving an exotic sports car. It's an experience that is appreciated by professionals and technology enthusiasts because it simply offers a more direct, engaging experience with the underlying technology. You can push the technology further. You have more control. It is more satisfying.
As of Linux kernel 3.1.5, LXC is usable for isolating your own private workloads from one another. It is not yet ready to isolate potentially malicious users from one another or the host system. For a more mature containers solution that is appropriate for hosting environments, see [[OpenVZ]].


If you aren't looking for something "special", there are a number of binary-only Linux distributions to choose from. They will get you from point A to point B. You won't have as much fun or be as connected to what's going on, but maybe that's not what you're looking for.
LXC containers don't yet have their own system uptime, and they see everything that's in the host's <tt>dmesg</tt> output, among other things. But in general, the technology works.


But if you ''do'' appreciate a deeper connection to technology, and pushing technology to its limits, Funtoo Linux may be a life-changing experience for you.
== Basic Info ==


=== Do you support systemd? ===


Part of the distinctiveness of Funtoo Linux is its dependency-based OpenRC init system, so changing this would make it something other than Funtoo Linux. So we do '''not''' support systemd as part of Funtoo Linux.
* Linux Containers are based on:
** Kernel namespaces for resource isolation
** CGroups for resource limitation and accounting


Thanks to the work of Dantrell B., we do, however, fully support running GNOME 3.12+ without depending on systemd.
{{Package|app-emulation/lxc}} is the userspace tool for Linux containers


=== What's with the Question Mark in the Logo? ===
== Control groups ==


We're currently looking for a new logo. I change it periodically and include a question mark to encourage people to submit ideas. You can post ideas to the [http://forums.funtoo.org forums].
* Control groups (cgroups) in kernel since 2.6.24
** Allows aggregation of tasks and their children
** Subsystems (cpuset, memory, blkio,...)
** accounting - to measure how much resources certain systems use
** resource limiting - groups can be set to not exceed a set memory limit
** prioritization - some groups may get a larger share of CPU
** control - freezing/unfreezing of cgroups, checkpointing and restarting
** No disk quota limitation ( -> image file, LVM, XFS, directory tree quota,...)


=== Do you use GitHub? ===
== Subsystems ==
 
<br>
Funtoo Linux has core git repositories at git.funtoo.org, which are automatically synced to GitHub, so all our public repositories are available on GitHub. But we don't use GitHub for pull requests, documentation, or tracking bugs. We have our own infrastructure for that. More information is available on the [[How to Dev|How to 'Dev' page]].
<console>
 
###i## cat /proc/cgroups
=== Does Funtoo use an overlay? ===
subsys_name hierarchy num_cgroups enabled
 
cpuset
An overlay is a Portage tree that is added "on top of" an existing Portage tree. Funtoo Linux allows you to use overlays, and we use overlays for development, but we deliver a single Funtoo Portage tree via git. This tree is generated automatically from the Gentoo Portage tree and a number of other overlays, and merged into a single tree. This is the tree that you get when you run <tt>emerge --sync</tt>. More information is available on the [[How to Dev|How to 'Dev' page]].
cpu
 
cpuacct
=== Does Funtoo Linux use a Red Hat or Debian kernel? ===
memory
 
devices
Funtoo Linux users are free to choose their own kernel, and we offer additional kernels from other Linux distributions such as Debian, Red Hat Enterprise Linux and others. These are documented on the [[Funtoo Linux Kernels]] page.
freezer
 
blkio
== Using Funtoo Linux, Portage and Git ==
perf_event
 
hugetlb
=== How do I start using Funtoo Linux? ===
</console>
 
For information on how to start using Funtoo Linux, see [[Funtoo Linux Installation]].


=== Is it possible to convert an existing Gentoo Linux install to Funtoo Linux? ===
#cpuset    -> limits tasks to specific CPU/CPUs
#cpu        -> CPU shares
#cpuacct    -> CPU accounting
#memory    -> memory and swap limitation and accounting
#devices    -> device allow deny list
#freezer    -> suspend/resume tasks
#blkio      -> I/O priorization (weight, throttle, ...)
#perf_event -> support for per-cpu per-cgroup monitoring [http://lwn.net/Articles/421574/ perf_events]
#hugetlb    -> cgroup resource controller for HugeTLB pages  [http://lwn.net/Articles/499255/ hugetlb]


Yes, it is possible, but not supported. Some people have done it, but you should not rely on it to always work. It is always best to install Funtoo Linux by following the steps in [[Funtoo Linux Installation]].
== Configuring the Funtoo Host System ==


=== What is mini-manifest? ===
=== Install LXC kernel ===
Any kernel beyond 3.1.5 will probably work. Personally I prefer {{Package|sys-kernel/gentoo-sources}} as these have support for all the namespaces without sacrificing the xfs, FUSE or NFS support for example. These checks were introduced later starting from kernel 3.5, this could also mean that the user namespace is not working optimally.


Manifests are files that you will find inside a Portage tree on a Gentoo Linux or Funtoo Linux system, one associated with each package -- for example <tt>dev-lang/php</tt> will have a single Manifest file for all PHP ebuilds. Traditionally, the Manifest files contain cryptographic hashes of all files in the Portage tree, plus hashes of all downloadable files (distfiles) used to build the package.
* User namespace (EXPERIMENTAL) depends on EXPERIMENTAL and on UIDGID_CONVERTED
** config UIDGID_CONVERTED
*** True if all of the selected software components are known to have uid_t and gid_t converted to kuid_t and kgid_t where appropriate and are otherwise safe to use with the user namespace.
**** Networking - depends on NET_9P = n
**** Filesystems - 9P_FS = n, AFS_FS = n, AUTOFS4_FS = n, CEPH_FS = n, CIFS = n, CODA_FS = n, FUSE_FS = n, GFS2_FS = n, NCP_FS = n, NFSD = n, NFS_FS = n, OCFS2_FS = n, XFS_FS = n
**** Security options - Grsecurity - GRKERNSEC = n (if applicable)


A feature introduced by Funtoo Linux, and now integrated upstream into Gentoo's Portage, are mini-Manifests. Because we use git for our Portage tree, which uses cryptographic hashes internally, we don't need Manifests to include hashes for all files ''in'' Portage, just files that need to be downloaded from mirrors. This is what mini-Manifests are -- Manifest files that have gone on a diet.
** As of 3.10.xx kernel, all of the above options are safe to use with User namespaces, except for XFS_FS, therefore with kernel >=3.10.xx, you should answer XFS_FS = n, if you want User namespaces support.
** in your kernel source directory, you should check init/Kconfig and find out what UIDGID_CONVERTED depends on


=== How do I get my initial Portage tree, or update my Portage tree? ===
==== Kernel configuration ====
These options should be enable in your kernel to be able to take full advantage of LXC.


This is done by typing:
* General setup
** CONFIG_NAMESPACES
*** CONFIG_UTS_NS
*** CONFIG_IPC_NS
*** CONFIG_PID_NS
*** CONFIG_NET_NS
*** CONFIG_USER_NS
** CONFIG_CGROUPS
*** CONFIG_CGROUP_DEVICE
*** CONFIG_CGROUP_SCHED
*** CONFIG_CGROUP_CPUACCT
*** CONFIG_CGROUP_MEM_RES_CTLR (in 3.6+ kernels it's called CONFIG_MEMCG)
*** CONFIG_CGROUP_MEM_RES_CTLR_SWAP (in 3.6+ kernels it's called CONFIG_MEMCG_SWAP)
*** CONFIG_CPUSETS (on multiprocessor hosts)
* Networking support
** Networking options
*** CONFIG_VLAN_8021Q
* Device Drivers
** Character devices
*** Unix98 PTY support
**** CONFIG_DEVPTS_MULTIPLE_INSTANCES
** Network device support
*** Network core driver support
**** CONFIG_VETH
**** CONFIG_MACVLAN


Once you have lxc installed, you can then check your kernel config with:
<console>
<console>
###i## emerge --sync
# ##i##CONFIG=/path/to/config /usr/sbin/lxc-checkconfig
</console>
</console>


Emerge will use the <tt>git pull</tt> command to update your tree for you, or will use <tt>git clone</tt> if one doesn't exist.
=== Emerge lxc ===
 
=== I set up my initial git-based Portage tree, but <tt>/usr/portage</tt> seems to be empty. ===
 
You forgot to type:
 
<console>
<console>
###i## cd /usr/portage
# ##i##emerge app-emulation/lxc
###i## git checkout funtoo.org
</console>
</console>
Funtoo Linux's portage tree snapshot ships with a mostly empty branch active by default to reduce the size of the resultant snapshot tarball.
=== What is the status of Funtoo's UTF-8 support? ===
Funtoo Linux has UTF-8 enabled by default, even for the <tt>root</tt> user. This allows UTF-8 files to be edited without issue, <tt>root</tt> GNU screen sessions to display UTF-8 character sets properly, etc. The classic sort order of <tt>ls -a</tt> has been preserved by setting <tt>LC_COLLATE</tt> to <tt>POSIX</tt>. All other locale settings inherit the system default defined in the <tt>LANG</tt> variable, which is set to <tt>en_US.UTF-8</tt>.


=== What if I want to use a non-English locale/language? ===
=== Configure Networking For Container ===


I recommend two things. First, it's strongly recommended that you always use a UTF-8-based locale.
Typically, one uses a bridge to allow containers to connect to the network. This is how to do it under Funtoo Linux:


The next thing I recommend is to try to avoid changing the global system LANG setting, and instead set the LANG setting on a per-user basis by adding the desired LANG setting to your <tt>~/.bashrc</tt>. This will preserve English log output in <tt>/var/log</tt> and make it easier to search for more common matching English strings on the Internet when you need help.
# create a bridge using the Funtoo network configuration scripts. Name the bridge something like <tt>brwan</tt> (using <tt>/etc/init.d/netif.brwan</tt>). Configure your bridge to have an IP address.
# Make your physical interface, such as <tt>eth0</tt>, an interface with no IP address (use the Funtoo <tt>interface-noip</tt> template.)
# Make <tt>netif.eth0</tt> a slave of <tt>netif.brwan</tt> in <tt>/etc/conf.d/netif.brwan</tt>.
# Enable your new bridged network and make sure it is functioning properly on the host.


If you really want to change the default system LANG setting (taking into account the paragraph above,) then it's recommended that you create your own <tt>/etc/env.d/02locale</tt> file that contains something like this:
You will now be able to configure LXC to automatically add your container's virtual ethernet interface to the bridge when it starts, which will connect it to your network.
<pre>
LANG="fr_CA.UTF-8"
</pre>
You will need to run <tt>env-update</tt> and <tt>source /etc/profile</tt> to apply changes immediately to any open shells, and reboot to apply changes fully.


=== What is different with Funtoo's Ruby? ===
== Setting up a Funtoo Linux LXC Container ==


Funtoo Linux tracks Gentoo's Ruby, but we do have one change for ruby-1.9 and greater - the binary name is changed with /usr/bin/ruby1.9 instead of Gentoo's /usr/bin/ruby19. This makes the versioning consistent with Python binaries and MacOS X. This means that for ruby-1.9 and greater. While the path to the binary has changed, all Portage variables are the same as Gentoo, so you should use &quot;ruby19&quot; for the <tt>RUBY_TARGETS</tt> setting in <tt>/etc/make.conf</tt>.
Here are the steps required to get Funtoo Linux running <i>inside</i> a container. The steps below show you how to set up a container using an existing Funtoo Linux OpenVZ template. It is now also possible to use [[Metro]] to build an lxc container tarball directly, which will save you manual configuration steps and will provide an <tt>/etc/fstab.lxc</tt> file that you can use for your host container config. See [[Metro Recipes]] for info on how to use Metro to generate an lxc container.


=== Does Funtoo Linux use an older udev? ===
=== Create and Configure Container Filesystem ===


Historically, we have, in order to avoid problems introduced with newer udev versions.
# Start with a Funtoo LXC template, and unpack it to a directory such as <tt>/lxc/funtoo0/rootfs/</tt>
# Create an empty <tt>/lxc/funtoo0/fstab</tt> file
# Ensure <tt>c1</tt> line is uncommented (enabled) and <tt>c2</tt> through <tt>c6</tt> lines are disabled in <tt>/lxc/funtoo0/rootfs/etc/inittab</tt>


We have just recently migrated to <tt>eudev</tt>, an udev fork, and will be keeping udev up-to-date.
That's almost all you need to get the container filesystem ready to start.


=== What is the minimum kernel version I can use with Funtoo Linux? ===
=== Create Container Configuration Files ===


We test and support 2.6.32 and above, and maintain compatiblity with RHEL 6 kernels, which are based on 2.6.32 and heavily patched.
Create the following files:


=== Why is package.mask a directory? ===
==== <tt>/lxc/funtoo0/config</tt> ====


Portage allows <tt>/usr/portage/profiles/package.mask</tt> to be a directory. We use this to organize our package masks into categories so they are easier to maintain.
=== Git complains and aborts when I emerge --sync. ===
It appears that a previous git merge was interrupted or did not complete, leaving your portage tree in an intermediate state. Typically, this can be fixed by typing:


and also create symlink from
==== <tt> /lxc/funtoo0/config to /etc/lxc/funtoo0.conf </tt> ====
<console>
<console>
###i## cd /usr/portage
###i## ln -s /lxc/funtoo0/config /etc/lxc/funtoo0.conf
###i## git reset --hard
</console>
</console>
This should restore your portage tree to a consistent state and allow future <tt>emerge --sync</tt> commands to complete successfully.


If this doesn't work, the simplest way to fix this is to delete your <tt>/usr/portage</tt> directory and run <tt>emerge --sync</tt> again. This will download a fresh tree.
{{Fancynote| Daniel Robbins needs to update this config to be more in line with http://wiki.progress-linux.org/software/lxc/ -- this config appears to have nice, refined device node permissions and other goodies. // note by Havis to Daniel, this config is already superior.}}


=== How do I tell if a problem I am having originates from Gentoo or Funtoo? ===


Let us figure this out for you. Report a bug to our [http://bugs.funtoo.org bug tracker], and we will determine how to resolve the issue.
Read "man 5 lxc.conf" , to get more information about linux container configuration file.
<pre>
## Container
lxc.utsname                            = funtoo0
lxc.rootfs                              = /lxc/funtoo0/rootfs/
lxc.arch                                = x86_64
#lxc.console                            = /var/log/lxc/funtoo0.console  # uncomment if you want to log containers console
lxc.tty                                = 6  # if you plan to use container with physical terminals (eg F1..F6)
#lxc.tty                                = 0  # set to 0 if you dont plan to use the container with physical terminal, also comment out in your containers /etc/inittab  c1 to c6 respawns (e.g. c1:12345:respawn:/sbin/agetty 38400 tty1 linux)
lxc.pts                                = 1024


=== How can I see the differences between the Gentoo and Funtoo Portage trees? ===


In the old days, this was tricky. We do not have a comprehensive way to do this, but here are some things to start looking at:
## Capabilities
lxc.cap.drop                            = audit_control
lxc.cap.drop                            = audit_write
lxc.cap.drop                            = mac_admin
lxc.cap.drop                            = mac_override
lxc.cap.drop                            = mknod
lxc.cap.drop                            = setfcap
lxc.cap.drop                            = setpcap
lxc.cap.drop                            = sys_admin
#lxc.cap.drop                            = sys_boot # capability to reboot the container
#lxc.cap.drop                            = sys_chroot # required by SSH
lxc.cap.drop                            = sys_module
#lxc.cap.drop                            = sys_nice
lxc.cap.drop                            = sys_pacct
lxc.cap.drop                            = sys_rawio
lxc.cap.drop                            = sys_resource
lxc.cap.drop                            = sys_time
#lxc.cap.drop                            = sys_tty_config # required by getty


* See the [http://www.github.com/funtoo/funtoo-overlay funtoo-overlay] for our main repository of Funtoo-specific stuff -- this is our main Funtoo package repository, but not our only one.
## Devices
* To get a full view of everything, see [http://git.funtoo.org/funtoo-overlay/tree/funtoo/scripts/merge.py our merge script] which generates our unified <tt>emerge --sync</tt>able tree. This describes everything that is part of Funtoo Linux.
#lxc.cgroup.devices.allow              = a # Allow access to all devices
* We have an automated report which is visible at [[Compare Forked Packages To Gentoo]]. This report is designed for Funtoo developers, and lists only the "bad" stuff -- areas in which our packages are older than what is in Gentoo Linux. We use this report to identify ebuilds that need to be updated in Funtoo Linux.
lxc.cgroup.devices.deny                = a # Deny access to all devices


=== Is Paludis compatible with the Funtoo Portage tree? ===
# Allow to mknod all devices (but not using them)
lxc.cgroup.devices.allow                = c *:* m
lxc.cgroup.devices.allow                = b *:* m


Paludis does not appear to be compatible with the Funtoo Portage tree, unfortunately. It does not support the <tt>package.mask</tt> directory without additional hooks, and also does not support merging device nodes. These features are supported by Portage and we use both of these capabilities. I think that both <tt>package.mask</tt> (and <tt>package.keywords</tt>, etc.) directories are a good idea, and I also think it's a good idea for the package manager to support device nodes, which is particularly useful for the <tt>udev</tt> and <tt>baselayout</tt> ebuilds. Funtoo Linux has separate versions of these packages, and these ebuilds are easier to maintain if device nodes are correctly supported by the package manger, and the <tt>package.mask</tt> directory is a great help to us as well.
lxc.cgroup.devices.allow                = c 1:3 rwm # /dev/null
lxc.cgroup.devices.allow                = c 1:5 rwm # /dev/zero
lxc.cgroup.devices.allow                = c 1:8 rwm # /dev/random
lxc.cgroup.devices.allow                = c 1:9 rwm # /dev/urandom
#lxc.cgroup.devices.allow                = c 4:0 rwm # /dev/tty0 ttys not required if you have lxc.tty = 0
#lxc.cgroup.devices.allow                = c 4:1 rwm # /dev/tty1 devices with major number 4 are "real" tty devices
#lxc.cgroup.devices.allow                = c 4:2 rwm # /dev/tty2
#lxc.cgroup.devices.allow                = c 4:3 rwm # /dev/tty3
lxc.cgroup.devices.allow                = c 5:0 rwm # /dev/tty
lxc.cgroup.devices.allow                = c 5:1 rwm # /dev/console
lxc.cgroup.devices.allow                = c 5:2 rwm # /dev/ptmx
lxc.cgroup.devices.allow                = c 10:229 rwm # /dev/fuse
lxc.cgroup.devices.allow                = c 136:* rwm # /dev/pts/* devices with major number 136 are pts
lxc.cgroup.devices.allow                = c 254:0 rwm # /dev/rtc0


We could maintain a patched version of Paludis that would be useable with the Funtoo Portage tree, but I don't want to get into the business of supporting a non-standard package manager as the upstream project seems not seem very supportive of getting these compatibility issues resolved, and thus this could turn into a maintenance burden for Funtoo. So I'd rather just not support Paludis for now.
## Limits#
lxc.cgroup.cpu.shares                  = 1024
lxc.cgroup.cpuset.cpus                = 0        # limits container to CPU0
lxc.cgroup.memory.limit_in_bytes      = 512M
lxc.cgroup.memory.memsw.limit_in_bytes = 1G
#lxc.cgroup.blkio.weight                = 500      # requires cfq block scheduler


=== What about pkgcore? ===
## Filesystem
#containers fstab should be outside it's rootfs dir (e.g. /lxc/funtoo0/fstab is ok, but /lxc/funtoo0/rootfs/etc/fstab is wrong!!!)
#lxc.mount                              = /lxc/funtoo0/fstab     


Pkgcore is not currently compatible with Funtoo Linux and this isn't something we test.
#lxc.mount.entry is prefered, because it supports relative paths
lxc.mount.entry                        = proc proc proc nosuid,nodev,noexec  0 0
lxc.mount.entry                        = sysfs sys sysfs nosuid,nodev,noexec,ro 0 0
lxc.mount.entry                        = devpts dev/pts devpts nosuid,noexec,mode=0620,ptmxmode=000,newinstance 0 0
lxc.mount.entry                        = tmpfs dev/shm tmpfs nosuid,nodev,mode=1777 0 0
lxc.mount.entry                        = tmpfs run tmpfs nosuid,nodev,noexec,mode=0755,size=128m 0 0
lxc.mount.entry                        = tmpfs tmp tmpfs nosuid,nodev,noexec,mode=1777,size=1g 0 0


=== How do I report a bug? ===
##Example of having /var/tmp/portage as tmpfs in container
#lxc.mount.entry                        = tmpfs var/tmp/portage tmpfs defaults,size=8g,uid=250,gid=250,mode=0775 0 0
##Example of bind mount
#lxc.mount.entry                        = /srv/funtoo0 /lxc/funtoo0/rootfs/srv/funtoo0 none defaults,bind 0 0


Please use our [http://bugs.funtoo.org bug tracker] to report all bugs. If you aren't quite at the stage where you feel you should report a bug, you may want to try using [http://forums.funtoo.org our forums] to ask others for help. Or ask on the [irc://irc.freenode.net/funtoo #funtoo] IRC channel.
## Network
lxc.network.type                        = veth
lxc.network.flags                      = up
lxc.network.hwaddr                      = #put your MAC address here, otherwise you will get a random one
lxc.network.link                        = br0
lxc.network.name                        = eth0
#lxc.network.veth.pair                  = veth-example
</pre>


=== How do I become a Funtoo developer? ===
Read "man 7 capabilities" to get more information aboout Linux capabilities.


First, we want you to be a Funtoo Linux user. Funtoo Linux is a project run by users.
Above, use the following command to generate a random MAC for <tt>lxc.network.hwaddr</tt>:


We have different ways you can get involved:
<console>
###i## openssl rand -hex 6 | sed 's/\(..\)/\1:/g; s/.$//'
</console>


==== Staff ====
It is a very good idea to assign a static MAC address to your container using <tt>lxc.network.hwaddr</tt>. If you don't, LXC will auto-generate a new random MAC every time your container starts, which may confuse network equipment that expects MAC addresses to remain constant.


Staff members help with things like ebuild maintenance, ensuring stages build, wiki documentation, and generally supporting the project by keeping it healthy.
It might happen from case to case that you aren't able to start your LXC Container with the above generated MAC address so for all these who run into that problem here is a little script that connects your IP for the container with the MAC address. Just save the following code as <tt>/etc/lxc/hwaddr.sh</tt>, make it executable and run it like <tt>/etc/lxc/hwaddr.sh xxx.xxx.xxx.xxx</tt> where xxx.xxx.xxx.xxx represents your Container IP. <br><tt>/etc/lxc/hwaddr.sh</tt>:


==== Developers ====
<pre>
#!/bin/sh
IP=$*
HA=`printf "02:00:%x:%x:%x:%x" ${IP//./ }`
echo $HA
</pre>


Developers help by working on maintenance of certain ebuilds, or even entire architectures or flavors of Funtoo Linux, like ARM or hardened.
==== <tt>/lxc/funtoo0/fstab</tt> ====
{{fancynote| It is now preferable to have mount entries directly in config file instead of separate fstab:}}
Edit the file <tt>/lxc/funtoo0/fstab</tt>:
<pre>
none /lxc/funtoo0/dev/pts devpts defaults 0 0
none /lxc/funtoo0/proc proc defaults 0 0
none /lxc/funtoo0/sys sysfs defaults 0 0
none /lxc/funtoo0/dev/shm tmpfs nodev,nosuid,noexec,mode=1777,rw 0 0
</pre>


==== Contributors ====
== LXC Networking ==
*veth - Virtual Ethernet (bridge)
*vlan - vlan interface (requires device able to do vlan tagging)
*macvlan (mac-address based virtual lan tagging) has 3 modes:
**private
**vepa (Virtual Ethernet Port Aggregator)
**bridge
*phys - dedicated host NIC
[https://blog.flameeyes.eu/2010/09/linux-containers-and-networking Linux Containers and Networking]


Contributors often work semi-independently, and commit their ebuilds or code to their own repositories. We then 'pull' from these repositories, often using automated tools, so their updates automatically become part of Funtoo Linux.
Enable routing on the host:
By default Linux workstations and servers have IPv4 forwarding disabled.
<console>
###i## echo "1" > /proc/sys/net/ipv4/ip_forward
###i## cat /proc/sys/net/ipv4/ip_forward
# 1
</console>


==== In Summary ====
== Initializing and Starting the Container ==


In reality, no one person fits 100% into a single category, and people who are actively involved in Funtoo Linux are doing some level of each of these things.
You will probably need to set the root password for the container before you can log in. You can use chroot to do this quickly:


I suggest hanging out in the #funtoo channel on Freenode and participating in [http://forums.funtoo.org the forums] and getting to know everyone in the community, and find an area in Funtoo Linux that you want to improve. If you have skills, and don't know what to improve, then ask in the Forums, and we'll help point you in the right direction.
<console>
###i## chroot /lxc/funtoo0/rootfs
(chroot) ###i## passwd
New password: XXXXXXXX
Retype new password: XXXXXXXX
passwd: password updated successfully
(chroot) ###i## exit
</console>


I always need people who are passionate about documenting technologies. There is so much to be documented. We have lots of bugs on the bug tracker that you can help with. And we are always open to people who want to take an out-of-date ebuild and give it some love. A great way to start doing this is to start filing bugs on [http://bugs.funtoo.org our bug tracker] and then start fixing these bugs by submitting patches. After a while, we'll get the idea that you are wanting to help, and we'll either start merging in an overlay of yours or find some other way for you to contribute.
Now that the root password is set, run:


Here are some tips for working with us:
<console>
###i## lxc-start -n funtoo0 -d
</console>


* We have limited time, and don't work on Funtoo Linux full-time. Please be respectful of that.
The <tt>-d</tt> option will cause it to run in the background.
* We are a very small project. As of mid-June 2014, we have four staff members (including BDFL) with commit rights Funtoo repositories, and only two (including BDFL) commit regularly.
* A priority is placed on being friendly and easy-going. If you are irritable or get into arguments often, and think that your technical skills will result in these deficiencies being overlooked, you will be unpleasantly surprised. We're called 'fun'too for a reason.


== General Funtoo Stuff ==
To attach to the console:


=== What is 'Funtoo' all about? And 'Funtoo Linux'? ===
<console>
###i## lxc-console -n funtoo0
</console>


<tt>Funtoo</tt> by itself refers to this site, or the larger <tt>Funtoo</tt> project run by Daniel Robbins. That's just a fancy way of saying that <tt>Funtoo</tt> refers to all the stuff I'm doing.
You should now be able to log in and use the container. In addition, the container should now be accessible on the network.


''Funtoo Linux'' refers specifically to my variant of Gentoo Linux.
To directly attach to container:


If you see me use the phrase <tt>Funtoo Portage tree</tt> or <tt>Funtoo ebuild</tt>, I'm just talking about our separate (and slightly different) Portage tree, or our version of an ebuild.
<console>
###i## lxc-attach -n funtoo0
</console>


=== What is 'tnufoo'? ===
To stop the container:


<tt>tnufoo</tt> is <tt>funtoo</tt> rotated 180 degrees vertically.
<console>
###i## lxc-stop -n funtoo0
</console>


=== How many developers are working on Funtoo Linux? ===
Ensure that networking is working from within the container while it is running, and you're good to go!


Funtoo Linux development is led by Daniel Robbins. We have one development lead, and a couple of other people who commit semi-infrequently. So, currently, about 4 people.
== Starting LXC container during host boot ==


=== Is Funtoo Linux a fork of Gentoo Linux? ===
# You need to create symlink in <tt>/etc/init.d/</tt> to <tt>/etc/init.d/lxc</tt> so that it reflects your container.
 
# <tt>ln -s /etc/init.d/lxc /etc/init.d/lxc.funtoo0</tt>
Funtoo Linux is not a full fork of Gentoo Linux, but we do fork some ebuilds.
# now you can add <tt>lxc.funtoo0</tt> to default runlevel
 
# <tt>rc-update add lxc.funtoo0 default</tt>
It's more accurate to refer to Funtoo Linux as a <tt>Gentoo Linux variant</tt>, meaning that it is more like another flavor of Gentoo than a fork.
<console>
 
###i## rc
We share our changes and bug fixes with the Gentoo project, so Gentoo is free to merge in any of our changes at any time.
* Starting funtoo0 ...                  [ ok ]
 
</console>
=== What is the best way to interact with the Funtoo community? ===


There is a list of resources on our [[Welcome]] page that is kept up-to-date.
== LXC Bugs/Missing Features ==


=== What Architectures does Funtoo Linux support? ===
This section is devoted to documenting issues with the current implementation of LXC and its associated tools. We will be gradually expanding this section with detailed descriptions of problems, their status, and proposed solutions.


Currently, Funtoo Linux is supporting x86-32bit, x86-64bit, including hardened and pure64 (non-multilib), as well as ARM. There has been a Sparc64 build in the past, which could always come back in the future if others come forward to maintain it.
=== reboot ===


=== How should a developer use package.mask? ===
By default, lxc does not support rebooting a container from within. It will simply stop and the host will not know to start it.


We have various package.mask files in <tt>funtoo-overlay</tt>:
=== PID namespaces ===


* <tt>funtoo-cautionary</tt> - masks that are in place to protect us from upstream changes in Gentoo Linux, or from ourselves.
Process ID namespaces are functional, but the container can still see the CPU utilization of the host via the system load (ie. in <tt>top</tt>).
* <tt>funtoo-staging</tt> - stuff that is masked for testing, and is intended to be unmasked soon.
* <tt>funtoo-toolchain</tt> - masks related to our toolchain, which is treated with care (we like to upgrade it in a careful and coordinated fashion.)
* <tt>funtoo-udev</tt> - this may disappear soon -- it's one of those mask files that we create for a special purpose -- in this case, stuff related to our <tt>eudev</tt> migration.


=== Do you use the normal Gentoo system profiles? ===
=== /dev/pts newinstance ===


I designed a new profile system for Funtoo which you can read about at [[Funtoo 1.0 Profile]]. It has a lot of cool functionality, including ''flavors'', ''mix-ins'' and other cool things. Thanks to Ryan Harris (rh1) for the excellent Funtoo <tt>eselect</tt> implementation for our new profile system.
* Some changes may be required to the host to properly implement "newinstance" <tt>/dev/pts</tt>. See [https://bugzilla.redhat.com/show_bug.cgi?id=501718 This Red Hat bug].


=== Is Funtoo Linux More Stable Than Gentoo Linux? ===
=== lxc-create and lxc-destroy ===


The short answer is that we don't know, but some people think it is, and we strive to make it more reliable than Gentoo, not because we're competitive, but because Funtoo Linux originally started as a version of Gentoo Linux that had several bugs fixed. We like to fix things that we find that aren't working.
* LXC's shell scripts are badly designed and are sure way to destruction, avoid using lxc-create and lxc-destroy.


=== Do you use Gentoo's Guide XML for Documentation? ===
=== network initialization and cleanup ===


I've made the decision to go with MediaWiki as our official documentation format.
* If used network.type = phys after lxc-stop the interface will be renamed to value from lxc.network.link. It supposed to be fixed in 0.7.4, happens still on 0.7.5 - http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg01760.html


=== Are you looking for translators? ===
* Re-starting a container can result in a failure as network resource are tied up from the already-defunct instance: [http://www.mail-archive.com/lxc-devel@lists.sourceforge.net/msg00824.html]


Many kind people have provided translations of the funtoo.org pages, and the old version of the site used to contain these translations. However, after much consideration, I've decided to not provide translated versions of funtoo.org pages, for several reasons:
=== lxc-halt ===


* Translated documents tend to become out-of-date
* Missing tool to graceful shutdown container. 'lxc-halt' should be written and be posix sh-compatible, using lxc-execute to run halt in container.
* Updating the translated documents is quite a bit of work
* Most people online seem to have at least a basic grasp of English


For these reasons, I'm going to focus on improving the quantity and quality of English documentation, and not focus on translations for now.
=== funtoo ===


== Forking the Portage Tree ==
* Our udev should be updated to contain <tt>-lxc</tt> in scripts. (This has been done as of 02-Nov-2011, so should be resolved. But not fixed in our openvz templates, so need to regen them in a few days.)
* Our openrc should be patched to handle the case where it cannot mount tmpfs, and gracefully handle this situation somehow. (Work-around in our docs above, which is to mount tmpfs to <tt>/libexec/rc/init.d</tt> using the container-specific <tt>fstab</tt> file (on the host.)
* Emerging udev within a container can/will fail when realdev is run, if a device node cannot be created (such as /dev/console) if there are no mknod capabilities within the container. This should be fixed.


=== I want to fork the Portage tree. How do I do this? ===
== References ==


Currently, the best way to do it involves forking the [http://www.github.com/funtoo/funtoo-overlay funtoo-overlay], which is much smaller, or creating your own overlay. I have scripts that combine the Funtoo overlay and the Gentoo tree to create a unified Portage tree.
* <tt>man 7 capabilities</tt>
* <tt>man 5 lxc.conf</tt>


=== Where can I learn more about <tt>git</tt>? ===
== Links ==


So, you want to learn more about <tt>git</tt>, do you? A collection of excellent git resources is now available on the [[Git Guide]].
* There are a number of additional lxc features that can be enabled via patches: [http://lxc.sourceforge.net/patches/linux/3.0.0/3.0.0-lxc1/]
* [https://wiki.ubuntu.com/UserNamespace Ubuntu User Namespaces page]
* lxc-gentoo setup script [https://github.com/globalcitizen/lxc-gentoo on GitHub]


=== Where can I learn more about the Funtoo Linux philosophy -- what you are about? ===
* '''IBM developerWorks'''
** [http://www.ibm.com/developerworks/linux/library/l-lxc-containers/index.html LXC: Linux Container Tools]
** [http://www.ibm.com/developerworks/linux/library/l-lxc-security/ Secure Linux Containers Cookbook]


See [[Funtoo Linux Vision]].
* '''Linux Weekly News'''
** [http://lwn.net/Articles/244531/ Smack for simplified access control]


[[Category:FAQ]]
[[Category:Labs]]
[[Category:Official Documentation]]
[[Category:HOWTO]]
[[Category:Virtualization]]

Revision as of 16:22, July 22, 2014

Linux Containers, or LXC, is a Linux feature that allows Linux to run one or more isolated virtual systems (with their own network interfaces, process namespace, user namespace, and power state) using a single Linux kernel on a single server.

Status

As of Linux kernel 3.1.5, LXC is usable for isolating your own private workloads from one another. It is not yet ready to isolate potentially malicious users from one another or the host system. For a more mature containers solution that is appropriate for hosting environments, see OpenVZ.

LXC containers don't yet have their own system uptime, and they see everything that's in the host's dmesg output, among other things. But in general, the technology works.

Basic Info

  • Linux Containers are based on:
    • Kernel namespaces for resource isolation
    • CGroups for resource limitation and accounting

app-emulation/lxc is the userspace tool for Linux containers

Control groups

  • Control groups (cgroups) in kernel since 2.6.24
    • Allows aggregation of tasks and their children
    • Subsystems (cpuset, memory, blkio,...)
    • accounting - to measure how much resources certain systems use
    • resource limiting - groups can be set to not exceed a set memory limit
    • prioritization - some groups may get a larger share of CPU
    • control - freezing/unfreezing of cgroups, checkpointing and restarting
    • No disk quota limitation ( -> image file, LVM, XFS, directory tree quota,...)

Subsystems


root # cat /proc/cgroups 
subsys_name	hierarchy	num_cgroups	enabled
cpuset	
cpu	
cpuacct	
memory	
devices	
freezer	
blkio	
perf_event
hugetlb
  1. cpuset -> limits tasks to specific CPU/CPUs
  2. cpu -> CPU shares
  3. cpuacct -> CPU accounting
  4. memory -> memory and swap limitation and accounting
  5. devices -> device allow deny list
  6. freezer -> suspend/resume tasks
  7. blkio -> I/O priorization (weight, throttle, ...)
  8. perf_event -> support for per-cpu per-cgroup monitoring perf_events
  9. hugetlb -> cgroup resource controller for HugeTLB pages hugetlb

Configuring the Funtoo Host System

Install LXC kernel

Any kernel beyond 3.1.5 will probably work. Personally I prefer No results as these have support for all the namespaces without sacrificing the xfs, FUSE or NFS support for example. These checks were introduced later starting from kernel 3.5, this could also mean that the user namespace is not working optimally.

  • User namespace (EXPERIMENTAL) depends on EXPERIMENTAL and on UIDGID_CONVERTED
    • config UIDGID_CONVERTED
      • True if all of the selected software components are known to have uid_t and gid_t converted to kuid_t and kgid_t where appropriate and are otherwise safe to use with the user namespace.
        • Networking - depends on NET_9P = n
        • Filesystems - 9P_FS = n, AFS_FS = n, AUTOFS4_FS = n, CEPH_FS = n, CIFS = n, CODA_FS = n, FUSE_FS = n, GFS2_FS = n, NCP_FS = n, NFSD = n, NFS_FS = n, OCFS2_FS = n, XFS_FS = n
        • Security options - Grsecurity - GRKERNSEC = n (if applicable)
    • As of 3.10.xx kernel, all of the above options are safe to use with User namespaces, except for XFS_FS, therefore with kernel >=3.10.xx, you should answer XFS_FS = n, if you want User namespaces support.
    • in your kernel source directory, you should check init/Kconfig and find out what UIDGID_CONVERTED depends on

Kernel configuration

These options should be enable in your kernel to be able to take full advantage of LXC.

  • General setup
    • CONFIG_NAMESPACES
      • CONFIG_UTS_NS
      • CONFIG_IPC_NS
      • CONFIG_PID_NS
      • CONFIG_NET_NS
      • CONFIG_USER_NS
    • CONFIG_CGROUPS
      • CONFIG_CGROUP_DEVICE
      • CONFIG_CGROUP_SCHED
      • CONFIG_CGROUP_CPUACCT
      • CONFIG_CGROUP_MEM_RES_CTLR (in 3.6+ kernels it's called CONFIG_MEMCG)
      • CONFIG_CGROUP_MEM_RES_CTLR_SWAP (in 3.6+ kernels it's called CONFIG_MEMCG_SWAP)
      • CONFIG_CPUSETS (on multiprocessor hosts)
  • Networking support
    • Networking options
      • CONFIG_VLAN_8021Q
  • Device Drivers
    • Character devices
      • Unix98 PTY support
        • CONFIG_DEVPTS_MULTIPLE_INSTANCES
    • Network device support
      • Network core driver support
        • CONFIG_VETH
        • CONFIG_MACVLAN

Once you have lxc installed, you can then check your kernel config with: 

root # CONFIG=/path/to/config /usr/sbin/lxc-checkconfig

Emerge lxc

root # emerge app-emulation/lxc

Configure Networking For Container

Typically, one uses a bridge to allow containers to connect to the network. This is how to do it under Funtoo Linux:

  1. create a bridge using the Funtoo network configuration scripts. Name the bridge something like brwan (using /etc/init.d/netif.brwan). Configure your bridge to have an IP address.
  2. Make your physical interface, such as eth0, an interface with no IP address (use the Funtoo interface-noip template.)
  3. Make netif.eth0 a slave of netif.brwan in /etc/conf.d/netif.brwan.
  4. Enable your new bridged network and make sure it is functioning properly on the host.

You will now be able to configure LXC to automatically add your container's virtual ethernet interface to the bridge when it starts, which will connect it to your network.

Setting up a Funtoo Linux LXC Container

Here are the steps required to get Funtoo Linux running inside a container. The steps below show you how to set up a container using an existing Funtoo Linux OpenVZ template. It is now also possible to use Metro to build an lxc container tarball directly, which will save you manual configuration steps and will provide an /etc/fstab.lxc file that you can use for your host container config. See Metro Recipes for info on how to use Metro to generate an lxc container.

Create and Configure Container Filesystem

  1. Start with a Funtoo LXC template, and unpack it to a directory such as /lxc/funtoo0/rootfs/
  2. Create an empty /lxc/funtoo0/fstab file
  3. Ensure c1 line is uncommented (enabled) and c2 through c6 lines are disabled in /lxc/funtoo0/rootfs/etc/inittab

That's almost all you need to get the container filesystem ready to start.

Create Container Configuration Files

Create the following files:

/lxc/funtoo0/config

and also create symlink from

/lxc/funtoo0/config to /etc/lxc/funtoo0.conf 

root # ln -s /lxc/funtoo0/config /etc/lxc/funtoo0.conf
   Note
Daniel Robbins needs to update this config to be more in line with http://wiki.progress-linux.org/software/lxc/ -- this config appears to have nice, refined device node permissions and other goodies. // note by Havis to Daniel, this config is already superior.


Read "man 5 lxc.conf" , to get more information about linux container configuration file. 

## Container
lxc.utsname                             = funtoo0
lxc.rootfs                              = /lxc/funtoo0/rootfs/
lxc.arch                                = x86_64
#lxc.console                            = /var/log/lxc/funtoo0.console  # uncomment if you want to log containers console
lxc.tty                                 = 6  # if you plan to use container with physical terminals (eg F1..F6)
#lxc.tty                                = 0  # set to 0 if you dont plan to use the container with physical terminal, also comment out in your containers /etc/inittab  c1 to c6 respawns (e.g. c1:12345:respawn:/sbin/agetty 38400 tty1 linux)
lxc.pts                                 = 1024


## Capabilities
lxc.cap.drop                            = audit_control
lxc.cap.drop                            = audit_write
lxc.cap.drop                            = mac_admin
lxc.cap.drop                            = mac_override
lxc.cap.drop                            = mknod
lxc.cap.drop                            = setfcap
lxc.cap.drop                            = setpcap
lxc.cap.drop                            = sys_admin
#lxc.cap.drop                            = sys_boot # capability to reboot the container
#lxc.cap.drop                            = sys_chroot # required by SSH
lxc.cap.drop                            = sys_module
#lxc.cap.drop                            = sys_nice
lxc.cap.drop                            = sys_pacct
lxc.cap.drop                            = sys_rawio
lxc.cap.drop                            = sys_resource
lxc.cap.drop                            = sys_time
#lxc.cap.drop                            = sys_tty_config # required by getty

## Devices
#lxc.cgroup.devices.allow               = a # Allow access to all devices
lxc.cgroup.devices.deny                 = a # Deny access to all devices

# Allow to mknod all devices (but not using them)
lxc.cgroup.devices.allow                = c *:* m
lxc.cgroup.devices.allow                = b *:* m

lxc.cgroup.devices.allow                = c 1:3 rwm # /dev/null
lxc.cgroup.devices.allow                = c 1:5 rwm # /dev/zero
lxc.cgroup.devices.allow                = c 1:8 rwm # /dev/random
lxc.cgroup.devices.allow                = c 1:9 rwm # /dev/urandom
#lxc.cgroup.devices.allow                = c 4:0 rwm # /dev/tty0 ttys not required if you have lxc.tty = 0
#lxc.cgroup.devices.allow                = c 4:1 rwm # /dev/tty1 devices with major number 4 are "real" tty devices
#lxc.cgroup.devices.allow                = c 4:2 rwm # /dev/tty2
#lxc.cgroup.devices.allow                = c 4:3 rwm # /dev/tty3
lxc.cgroup.devices.allow                = c 5:0 rwm # /dev/tty
lxc.cgroup.devices.allow                = c 5:1 rwm # /dev/console
lxc.cgroup.devices.allow                = c 5:2 rwm # /dev/ptmx
lxc.cgroup.devices.allow                = c 10:229 rwm # /dev/fuse
lxc.cgroup.devices.allow                = c 136:* rwm # /dev/pts/* devices with major number 136 are pts
lxc.cgroup.devices.allow                = c 254:0 rwm # /dev/rtc0

## Limits#
lxc.cgroup.cpu.shares                  = 1024
lxc.cgroup.cpuset.cpus                 = 0        # limits container to CPU0
lxc.cgroup.memory.limit_in_bytes       = 512M
lxc.cgroup.memory.memsw.limit_in_bytes = 1G
#lxc.cgroup.blkio.weight                = 500      # requires cfq block scheduler

## Filesystem
#containers fstab should be outside it's rootfs dir (e.g. /lxc/funtoo0/fstab is ok, but /lxc/funtoo0/rootfs/etc/fstab is wrong!!!)
#lxc.mount                               = /lxc/funtoo0/fstab       

#lxc.mount.entry is prefered, because it supports relative paths
lxc.mount.entry                         = proc proc proc nosuid,nodev,noexec  0 0
lxc.mount.entry                         = sysfs sys sysfs nosuid,nodev,noexec,ro 0 0
lxc.mount.entry                         = devpts dev/pts devpts nosuid,noexec,mode=0620,ptmxmode=000,newinstance 0 0
lxc.mount.entry                         = tmpfs dev/shm tmpfs nosuid,nodev,mode=1777 0 0
lxc.mount.entry                         = tmpfs run tmpfs nosuid,nodev,noexec,mode=0755,size=128m 0 0
lxc.mount.entry                         = tmpfs tmp tmpfs nosuid,nodev,noexec,mode=1777,size=1g 0 0

##Example of having /var/tmp/portage as tmpfs in container 
#lxc.mount.entry                         = tmpfs var/tmp/portage tmpfs defaults,size=8g,uid=250,gid=250,mode=0775 0 0
##Example of bind mount
#lxc.mount.entry                        = /srv/funtoo0 /lxc/funtoo0/rootfs/srv/funtoo0 none defaults,bind 0 0

## Network
lxc.network.type                        = veth
lxc.network.flags                       = up
lxc.network.hwaddr                      = #put your MAC address here, otherwise you will get a random one
lxc.network.link                        = br0
lxc.network.name                        = eth0
#lxc.network.veth.pair                   = veth-example

Read "man 7 capabilities" to get more information aboout Linux capabilities.

Above, use the following command to generate a random MAC for lxc.network.hwaddr: 

root # openssl rand -hex 6 | sed 's/\(..\)/\1:/g; s/.$//'

It is a very good idea to assign a static MAC address to your container using lxc.network.hwaddr. If you don't, LXC will auto-generate a new random MAC every time your container starts, which may confuse network equipment that expects MAC addresses to remain constant.

It might happen from case to case that you aren't able to start your LXC Container with the above generated MAC address so for all these who run into that problem here is a little script that connects your IP for the container with the MAC address. Just save the following code as /etc/lxc/hwaddr.sh, make it executable and run it like /etc/lxc/hwaddr.sh xxx.xxx.xxx.xxx where xxx.xxx.xxx.xxx represents your Container IP.
/etc/lxc/hwaddr.sh: 

#!/bin/sh
IP=$*
HA=`printf "02:00:%x:%x:%x:%x" ${IP//./ }`
echo $HA

/lxc/funtoo0/fstab

   Note
It is now preferable to have mount entries directly in config file instead of separate fstab:

Edit the file /lxc/funtoo0/fstab: 

none /lxc/funtoo0/dev/pts devpts defaults 0 0
none /lxc/funtoo0/proc proc defaults 0 0
none /lxc/funtoo0/sys sysfs defaults 0 0
none /lxc/funtoo0/dev/shm tmpfs nodev,nosuid,noexec,mode=1777,rw 0 0

LXC Networking

  • veth - Virtual Ethernet (bridge)
  • vlan - vlan interface (requires device able to do vlan tagging)
  • macvlan (mac-address based virtual lan tagging) has 3 modes:
    • private
    • vepa (Virtual Ethernet Port Aggregator)
    • bridge
  • phys - dedicated host NIC

Linux Containers and Networking

Enable routing on the host: By default Linux workstations and servers have IPv4 forwarding disabled. 

root # echo "1" > /proc/sys/net/ipv4/ip_forward
root # cat /proc/sys/net/ipv4/ip_forward
root # 1

Initializing and Starting the Container

You will probably need to set the root password for the container before you can log in. You can use chroot to do this quickly: 

root # chroot /lxc/funtoo0/rootfs
(chroot) # passwd
New password: XXXXXXXX
Retype new password: XXXXXXXX
passwd: password updated successfully
(chroot) # exit

Now that the root password is set, run: 

root # lxc-start -n funtoo0 -d

The -d option will cause it to run in the background.

To attach to the console: 

root # lxc-console -n funtoo0

You should now be able to log in and use the container. In addition, the container should now be accessible on the network.

To directly attach to container: 

root # lxc-attach -n funtoo0

To stop the container: 

root # lxc-stop -n funtoo0

Ensure that networking is working from within the container while it is running, and you're good to go!

Starting LXC container during host boot

  1. You need to create symlink in /etc/init.d/ to /etc/init.d/lxc so that it reflects your container.
  2. ln -s /etc/init.d/lxc /etc/init.d/lxc.funtoo0
  3. now you can add lxc.funtoo0 to default runlevel
  4. rc-update add lxc.funtoo0 default
root # rc
 * Starting funtoo0 ...                  [ ok ]

LXC Bugs/Missing Features

This section is devoted to documenting issues with the current implementation of LXC and its associated tools. We will be gradually expanding this section with detailed descriptions of problems, their status, and proposed solutions.

reboot

By default, lxc does not support rebooting a container from within. It will simply stop and the host will not know to start it.

PID namespaces

Process ID namespaces are functional, but the container can still see the CPU utilization of the host via the system load (ie. in top).

/dev/pts newinstance

  • Some changes may be required to the host to properly implement "newinstance" /dev/pts. See This Red Hat bug.

lxc-create and lxc-destroy

  • LXC's shell scripts are badly designed and are sure way to destruction, avoid using lxc-create and lxc-destroy.

network initialization and cleanup

  • Re-starting a container can result in a failure as network resource are tied up from the already-defunct instance: [1]

lxc-halt

  • Missing tool to graceful shutdown container. 'lxc-halt' should be written and be posix sh-compatible, using lxc-execute to run halt in container.

funtoo

  • Our udev should be updated to contain -lxc in scripts. (This has been done as of 02-Nov-2011, so should be resolved. But not fixed in our openvz templates, so need to regen them in a few days.)
  • Our openrc should be patched to handle the case where it cannot mount tmpfs, and gracefully handle this situation somehow. (Work-around in our docs above, which is to mount tmpfs to /libexec/rc/init.d using the container-specific fstab file (on the host.)
  • Emerging udev within a container can/will fail when realdev is run, if a device node cannot be created (such as /dev/console) if there are no mknod capabilities within the container. This should be fixed.

References

  • man 7 capabilities
  • man 5 lxc.conf

Links

Retrieved from "https://www.funtoo.org/index.php?title=FAQ/Old&oldid=4945"