Difference between pages "LXC Fun" and "Install/Stage3"

(Difference between pages)
 
(Your SubArch)
 
Line 1: Line 1:
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. To learn more take a look at the [[LXC]] article.
+
<noinclude>
 +
{{InstallPart|the process of installing the Stage3 tarball}}
 +
</noinclude>
 +
=== Installing the Stage 3 tarball ===
 +
After creating filesystems, the next step is downloading the initial Stage 3 tarball. The Stage 3 is a pre-compiled system used as a starting point to install Funtoo Linux. Load one of the following URLs in another browser window:
  
In this Howto you will be shown how to create containers, how to start, stop, freeze and unfreeze them and also some more fun parts like snapshoting and clonig. To have all this working you will have to have your lxc store (/var/lib/lxc/ and /var/lib/lxcsnaps) to be on a '''btrfs filesystem'''.
+
{{MirrorList}}
  
__TOC__
+
Now, let's navigate the directories on the mirrors to find the appropriate build of Funtoo Linux for you.
  
== Creating containers ==
+
==== Stable or Current? ====
Creating containers is quite easy using lxc-templates. They are located in the /usr/share/lxc/templates directory. You can find there many distributions like archlinux, centos, debian, fedora, opensuse, ubuntu, gentoo and some more. There is also an inofficial funtoo template that can be found at https://github.com/golodhrim/lxc-funtoo/blob/master/lxc-funtoo. The script creates funtoo container, however I was not able to use it with lxc-create script from the lxc utils. You have to run it as a stand-alone script.
+
Funtoo Linux has a "stable" build and a "current" build. Most people use the "current" build of Funtoo Linux, and it's generally recommended that you do too. You will find "current' builds in the main <code>/funtoo-current</code> directory on our mirrors, and "stable" builds in <code>/funtoo-stable</code>.
 +
<br />If you want to read more about this, have a look at [[Funtoo_Linux#What_are_the_differences_between_.27stable.27.2C_.27current.27_and_.27experimental.27_.3F|Differences between stable, current and experimental]].
  
So how do you create other containers? I am going to use a debian container for this howto. You will have to emerge debootstrap.
+
==== 32 or 64-bit? ====
 +
There are three different types of Funtoo Linux that you can install. If you are installing on an older 32-bit system (if you don't know, then you probably are not) then you want to grab a stage3 tarball from the <code>x86-32bit</code> sub-directory. Most likely, you'll want to grab a 64-bit build from the <code>x86-64bit</code> sub-directory.
  
<console>
+
==== Your SubArch ====
###i## emerge -av debootstrap
+
Inside <code>/funtoo-current/x86-64bit/</code> on one of our mirrors, you'll see a bunch of directories for various ''subarches'' of Funtoo Linux.
  
* IMPORTANT: 8 news items need reading for repository 'gentoo'.
+
Subarches are builds of Funtoo Linux that are designed to run on a particular type of CPU, to offer the best possible performance. They take advantage of the instruction sets available for each CPU.  
* Use eselect news to read news items.
+
  
 +
For example, the <code>corei7</code> and <code>corei7-pure64</code> sub-arches require an Intel Core i7 processor to run (this includes Xeon x3400+ series, or other Nehalem-based CPUs such as Xeon x5500/x5600 series.)
  
These are the packages that would be merged, in order:
+
If you are using an AMD-based CPU, download a stage3 from <code>generic_64</code>, <code>amd64-k8</code>, <code>amd64-k10</code>, <code>amd-bulldozer</code>, <code>amd-piledriver</code> or <code>amd64-steamroller</code>.
  
Calculating dependencies... done!
+
If you are using an Intel-based CPU, download a stage3 from <code>generic_64</code>, <code>atom_64</code>, <code>core2_64</code> or <code>corei7</code>.
[ebuild  N    ] dev-perl/TimeDate-2.300.0  31 kB
+
[ebuild  N    ] app-arch/dpkg-1.17.10  USE="bzip2 lzma nls unicode update-alternatives zlib -dselect {-test}" 4,100 kB
+
[ebuild  N    ] dev-util/debootstrap-1.0.59  96 kB
+
  
Total: 3 packages (3 new), Size of downloads: 4,226 kB
+
===== Pure64 Builds =====
  
Would you like to merge these packages? [Yes/No]
+
Inside <code>/funtoo-current/</code>, you may notice a sub-directory named <code>pure64</code>. These 64-bit builds are recommended for server systems, and they do not offer any 32-bit compatibility, which is generally not needed on server systems. If you are setting up a desktop or workstation system, it's recommended that you avoid these builds as you will need 32-bit compatibility to run several binary desktop-oriented applications such as Skype. But for servers, pure64 is recommended.
</console>
+
  
After installing debootstrap, you can create your debian container using:
+
==== Setting the Date ====
  
<console>
+
{{fancyimportant|If your system's date and time are too far off (typically by months or years,) then it may prevent Portage from properly downloading source tarballs. This is because some of our sources are downloaded via HTTPS, which use SSL certificates and are marked with an activation and expiration date.}}
###i## lxc-create -B btrfs -n vm1 -t debian
+
debootstrap is /usr/bin/debootstrap
+
Checking cache download in /var/cache/lxc/debian/rootfs-wheezy-armhf ...
+
Copying rootfs to /var/lib/lxc/vm1/rootfs...Generating locales (this might take a while)...
+
  en_US.UTF-8... done
+
Generation complete.
+
update-rc.d: using dependency based boot sequencing
+
update-rc.d: using dependency based boot sequencing
+
update-rc.d: using dependency based boot sequencing
+
update-rc.d: using dependency based boot sequencing
+
Creating SSH2 RSA key; this may take some time ...
+
Creating SSH2 DSA key; this may take some time ...
+
Creating SSH2 ECDSA key; this may take some time ...
+
invoke-rc.d: policy-rc.d denied execution of restart.
+
Timezone in container is not configured. Adjust it manually.
+
Root password is 'root', please change !
+
</console>
+
  
We will see that the lxc-create command created a subvolume on BTRFS backing file system (-B switch took care of this).
+
Now is a good time to verify the date and time are correctly set to UTC. Use the <code>date</code> command to verify the date and time:
<console>
+
###i## btrfs sub list /
+
---- snip ----
+
ID 1143 gen 437 top level 5 path var/lib/lxc/vm1/rootfs
+
---- snip ----
+
</console>
+
 
+
Now you are ready to do all the fun stuff with your LXCs.
+
 
+
== Starting/stoping containers ==
+
To start a previously created container use the lxc utils:
+
  
 
<console>
 
<console>
###i## lxc-start -n vm1 -d
+
# ##i##date
###i## lxc-info -n vm1
+
Fri Jul 15 19:47:18 UTC 2011
Name:           vm1
+
State:          RUNNING
+
PID:            29742
+
IP:            172.16.65.234
+
CPU use:        2.92 seconds
+
BlkIO use:      260.00 KiB
+
Memory use:    2.99 MiB
+
KMem use:      0 bytes
+
Link:          vethTN4NGU
+
TX bytes:      2.33 KiB
+
RX bytes:      39.54 KiB
+
Total bytes:  41.87 KiB
+
###i## lxc-attach -n vm1
+
###r## root@vm1:~#
+
###r## root@vm1:~# exit
+
###i## lxc-stop -n vm1
+
Name:          vm1
+
State:         STOPPED
+
 
</console>
 
</console>
  
== Freezing/unfreezing containers ==
+
If the date and/or time need to be corrected, do so using <code>date MMDDhhmmYYYY</code>, keeping in mind <code>hhmm</code> are in 24-hour format. The example below changes the date and time to "July 16th, 2011 @ 8:00PM" UTC:
The command lxc-freeze freezes all the processes running inside the container.  The processes will be blocked until they are explicitly thawed by the lxc-unfreeze command. To freeze a previously started container use the lxc utils:
+
  
 
<console>
 
<console>
###i## lxc-freeze -n vm1
+
# ##i##date 071620002011
###i## lxc-info -n vm1
+
Fri Jul 16 20:00:00 UTC 2011
Name:          vm1
+
State:          FROZEN
+
PID:            6817
+
IP:            172.16.65.234
+
CPU use:       2.78 seconds
+
BlkIO use:      0 bytes
+
Memory use:    2.47 MiB
+
KMem use:      0 bytes
+
Link:          veth7E1J8R
+
TX bytes:      1.45 KiB
+
RX bytes:      3.85 KiB
+
Total bytes:  5.31 KiB
+
###i## lxc-unfreeze -n vm1
+
###i## lxc-info -n vm1
+
Name:          vm1
+
State:          RUNNING
+
PID:            6817
+
IP:            172.16.65.234
+
CPU use:        2.78 seconds
+
BlkIO use:      0 bytes
+
Memory use:    2.47 MiB
+
KMem use:      0 bytes
+
Link:          veth7E1J8R
+
TX bytes:      1.58 KiB
+
RX bytes:      11.13 KiB
+
Total bytes:   12.71 KiB
+
 
</console>
 
</console>
  
== Clones and snapshots  ==
+
==== Download the Stage3 ====
Now the really nice features of LXC are snapshots of containers and also creating clones of containers. The command lxc-snapshot creates snapshot under /var/lib/lxcsnaps/ directory, this directory must also reside on a BTRFS filesystem. To snapshot a previously created container use the lxc utils:
+
Once you are in your Funtoo Linux root filesystem, use <code>wget</code> to download the Stage 3 tarball you have chosen to use as the basis for your new Funtoo Linux system. It should be saved to the <code>/mnt/funtoo</code> directory as follows:
  
<console>
+
<console># ##i##cd /mnt/funtoo
###i## lxc-snapshot -n vm1
+
# ##i##wget http://ftp.osuosl.org/pub/funtoo/funtoo-current/x86-64bit/generic_64/stage3-latest.tar.xz
###i## lxc-snapshot -L -n vm1                                                                                                       
+
snap0 (/var/lib/lxcsnaps/vm1) 2014:11:15 14:01:18
+
###i## btrfs sub list /
+
--- snip ---
+
ID 1144 gen 448 top level 1136 path var/lib/lxcsnaps/vm1/snap0/rootfs
+
--- snip ---
+
 
</console>
 
</console>
  
You can also add comments (using a comment file and -c switch). Lets pretend something didn't go well after an upgrade. No big deal if you remembered to create a snapshot before the upgrade. Now you can restore the container to the last good state.
+
Note that 64-bit systems can run 32-bit or 64-bit stages, but 32-bit systems can only run 32-bit stages. Make sure that you select a Stage 3 build that is appropriate for your CPU. If you are not certain, it is a safe bet to choose the <code>generic_64</code> or <code>generic_32</code> stage. Consult the [[Download]] page for more information.
  
 +
Once the stage is downloaded, extract the contents with the following command, substituting in the actual name of your stage 3 tarball:
 
<console>
 
<console>
###i## btrfs sub list /
+
# ##i##tar xpf stage3-latest.tar.xz
--- snip ---
+
ID ''1143'' gen 437 top level 5 path var/lib/lxc/vm1/rootfs
+
ID 1144 gen 448 top level 1136 path var/lib/lxcsnaps/vm1/snap0/rootfs
+
--- snip ---
+
###i## lxc-snapshot -L -n vm1                                                                                                       
+
snap0 (/var/lib/lxcsnaps/vm1) 2014:11:15 14:01:18
+
###i## lxc-snapshot -n vm1 -r snap0
+
###i## lxc-snapshot -L -n vm1                                                                                                       
+
snap0 (/var/lib/lxcsnaps/vm1) 2014:11:15 14:01:18
+
###i## btrfs sub list /
+
--- snip ---
+
ID 1144 gen 448 top level 1136 path var/lib/lxcsnaps/vm1/snap0/rootfs
+
ID ''1147'' gen 453 top level 5 path var/lib/lxc/vm1/rootfs
+
--- snip ---
+
 
</console>
 
</console>
  
Notice the ID change in btrfs subvolume list command (ID in italics). BTRFS took care of the lxc-snapshot call and restored the snapshot contained in the lxcsnaps/vm1/snap0 directory.
+
{{important|It is very important to use <code>tar's</code> "<code>'''p'''</code>" option when extracting the Stage 3 tarball - it tells <code>tar</code> to ''preserve'' any permissions and ownership that exist within the archive. Without this option, your Funtoo Linux filesystem permissions will be incorrect.}}
 
+
Now clones are containers that are exactly the same as the originating container. So for example you will configure a basic LAMP stack (LXC Apache Mariadb PHP) in one container and want to use different container for different websites. So after doing all the hard work of setting up LAMP you just clone the container using lxc tools.
+
 
+
<console>
+
###i## btrfs sub list /
+
--- snip ---
+
ID 1144 gen 448 top level 1136 path var/lib/lxcsnaps/vm1/snap0/rootfs
+
ID 1147 gen 453 top level 5 path var/lib/lxc/vm1/rootfs
+
--- snip ---
+
###i## lxc-clone -B btrfs -s vm1 vm2
+
Created container vm2 as snapshot of vm1
+
###i## btrfs sub list /
+
--- snip ---
+
ID 1144 gen 448 top level 1136 path var/lib/lxcsnaps/vm1/snap0/rootfs
+
ID 1147 gen 455 top level 5 path var/lib/lxc/vm1/rootfs
+
ID 1148 gen 455 top level 5 path var/lib/lxc/vm2/rootfs
+
--- snip ---
+
</console>
+
 
+
== Cgroups control ==
+
Get or set the value of a state object (for example, 'cpuset.cpus') in the container's cgroup for the corresponding subsystem.
+
* TODO
+
 
+
== Managing devices ==
+
* TODO
+
 
+
== Monitoring containers ==
+
There is a utility lxc-top that shows some basic information about running containers.
+
 
+
<console>
+
###i## lxc-top
+
Container            CPU      CPU      CPU      BlkIO        Mem
+
Name                Used      Sys    User      Total      Used
+
vm1                3.16    3.00    0.95  13.05 MB  12.70 MB
+
vm2                0.14    0.06    0.10    0.00    372.00 KB
+
vm3                3.39    2.09    1.98  868.00 KB    1.44 MB
+
vm4                3.15    2.01    1.71    0.00    912.00 KB
+
TOTAL (4 )          9.84    7.16    4.74  13.89 MB  15.40 MB
+
</console>
+
 
+
== Web GUI ==
+
There are a few web GUIs available for LXC. LXC-Web-Panel is a simple one that does the work good. You can get it from https://github.com/trick77/LXC-Web-Panel (it is a fork of LXC-Web-Panel from https://github.com/lxc-webpanel/LXC-Web-Panel, but supports LXC 1.0).  You need flask (dev-python/flask).
+
<console>
+
###i## emerge -av flask
+
These are the packages that would be merged, in order:
+
 
+
Calculating dependencies... done!
+
[ebuild  N    ] dev-python/blinker-1.3-r1000  USE="-doc {-test}" PYTHON_ABIS="2.7 3.3 -2.6 -2.7-jython -2.7-pypy-2.0 -3.1 -3.2 -3.4 (-3.5)" 90 kB
+
[ebuild  N    ] dev-python/werkzeug-0.9.6-r1000  USE="-redis" PYTHON_ABIS="2.7 3.3 -2.6 -2.7-jython -2.7-pypy-2.0 -3.4 (-3.5)" 1,102 kB
+
[ebuild  N    ] dev-python/itsdangerous-0.24-r1000  USE="-doc" PYTHON_ABIS="2.7 3.3 -2.6 -2.7-jython -2.7-pypy-2.0 -3.1 -3.2 -3.4 (-3.5)" 46 kB
+
[ebuild  N    ] dev-python/markupsafe-0.23-r1000  PYTHON_ABIS="2.7 3.3 -2.6 -2.7-jython -2.7-pypy-2.0 -3.1 -3.2 -3.4 (-3.5)" 14 kB
+
[ebuild  N    ] dev-python/jinja-2.7.3-r1000  USE="-doc -examples -i18n -vim-syntax" PYTHON_ABIS="2.7 3.3 -2.6 -2.7-jython -2.7-pypy-2.0 -3.1 -3.2 -3.4 (-3.5)" 370 kB
+
[ebuild  N    ] dev-python/flask-0.10.1-r1000  USE="-doc -examples" PYTHON_ABIS="2.7 3.3 -2.6 -2.7-jython -2.7-pypy-2.0 -3.4 (-3.5)" 532 kB
+
 
+
Total: 6 packages (6 new), Size of downloads: 2,152 kB
+
 
+
Would you like to merge these packages? [Yes/No]
+
</console>
+
 
+
<console>
+
###i## git clone https://github.com/trick77/LXC-Web-Panel
+
###i## cd LXC-Web-Panel
+
###i## python lwp.py
+
</console>
+
 
+
[[File:Lxc-web.png|800px|LXC Web Panel]]
+
 
+
== Summary ==
+
LXC is a very powerful virtualization technology, in Linux it is one one many to choose from and that is nice. LXC works off the host's existing vanilla kernel, thanks to functionality called cgroups that was merged into the Linux kernel v2.6.24. This allows operating system-level virtualization, and the ability to run multiple isolated Linux systems in "containers" -- a lightweight version of virtual machines (VM).
+
 
+
[[Category:Virtualization]]
+

Revision as of 19:26, November 15, 2014


Note

This is a template that is used as part of the Installation instructions which covers: the process of installing the Stage3 tarball. Templates are being used to allow multiple variant install guides that use most of the same re-usable parts.


Installing the Stage 3 tarball

After creating filesystems, the next step is downloading the initial Stage 3 tarball. The Stage 3 is a pre-compiled system used as a starting point to install Funtoo Linux. Load one of the following URLs in another browser window:

Now, let's navigate the directories on the mirrors to find the appropriate build of Funtoo Linux for you.

Stable or Current?

Funtoo Linux has a "stable" build and a "current" build. Most people use the "current" build of Funtoo Linux, and it's generally recommended that you do too. You will find "current' builds in the main /funtoo-current directory on our mirrors, and "stable" builds in /funtoo-stable.
If you want to read more about this, have a look at Differences between stable, current and experimental.

32 or 64-bit?

There are three different types of Funtoo Linux that you can install. If you are installing on an older 32-bit system (if you don't know, then you probably are not) then you want to grab a stage3 tarball from the x86-32bit sub-directory. Most likely, you'll want to grab a 64-bit build from the x86-64bit sub-directory.

Your SubArch

Inside /funtoo-current/x86-64bit/ on one of our mirrors, you'll see a bunch of directories for various subarches of Funtoo Linux.

Subarches are builds of Funtoo Linux that are designed to run on a particular type of CPU, to offer the best possible performance. They take advantage of the instruction sets available for each CPU.

For example, the corei7 and corei7-pure64 sub-arches require an Intel Core i7 processor to run (this includes Xeon x3400+ series, or other Nehalem-based CPUs such as Xeon x5500/x5600 series.)

If you are using an AMD-based CPU, download a stage3 from generic_64, amd64-k8, amd64-k10, amd-bulldozer, amd-piledriver or amd64-steamroller.

If you are using an Intel-based CPU, download a stage3 from generic_64, atom_64, core2_64 or corei7.

Pure64 Builds

Inside /funtoo-current/, you may notice a sub-directory named pure64. These 64-bit builds are recommended for server systems, and they do not offer any 32-bit compatibility, which is generally not needed on server systems. If you are setting up a desktop or workstation system, it's recommended that you avoid these builds as you will need 32-bit compatibility to run several binary desktop-oriented applications such as Skype. But for servers, pure64 is recommended.

Setting the Date

Important

If your system's date and time are too far off (typically by months or years,) then it may prevent Portage from properly downloading source tarballs. This is because some of our sources are downloaded via HTTPS, which use SSL certificates and are marked with an activation and expiration date.

Now is a good time to verify the date and time are correctly set to UTC. Use the date command to verify the date and time:

# date
Fri Jul 15 19:47:18 UTC 2011

If the date and/or time need to be corrected, do so using date MMDDhhmmYYYY, keeping in mind hhmm are in 24-hour format. The example below changes the date and time to "July 16th, 2011 @ 8:00PM" UTC:

# date 071620002011
Fri Jul 16 20:00:00 UTC 2011

Download the Stage3

Once you are in your Funtoo Linux root filesystem, use wget to download the Stage 3 tarball you have chosen to use as the basis for your new Funtoo Linux system. It should be saved to the /mnt/funtoo directory as follows:

# cd /mnt/funtoo
# wget http://ftp.osuosl.org/pub/funtoo/funtoo-current/x86-64bit/generic_64/stage3-latest.tar.xz

Note that 64-bit systems can run 32-bit or 64-bit stages, but 32-bit systems can only run 32-bit stages. Make sure that you select a Stage 3 build that is appropriate for your CPU. If you are not certain, it is a safe bet to choose the generic_64 or generic_32 stage. Consult the Download page for more information.

Once the stage is downloaded, extract the contents with the following command, substituting in the actual name of your stage 3 tarball:

# tar xpf stage3-latest.tar.xz

Important

It is very important to use tar's "p" option when extracting the Stage 3 tarball - it tells tar to preserve any permissions and ownership that exist within the archive. Without this option, your Funtoo Linux filesystem permissions will be incorrect.