Changes

Jump to: navigation, search

LXD

22,136 bytes removed, 4 months ago
Network Troubleshooting
<languages/>{{Subpages|GPU Acceleration,GPU Acceleration (NVIDIA),What are subuids and subgids?,Administration Tutorial,Features and Concepts}}<translate>== Introduction ==<!--T:1-->
<!--T:2-->
LXD is a container "hypervisor" designed to provide an easy set of tools to manage Linux containers, and its development is currently being led by employees at Canonical. You can learn more about the project in general at https://linuxcontainers.org/lxd/ .
<!--T:3-->LXD is currently used for container infrastructure for [[Special:MyLanguage/Funtoo Containers|Funtoo Containers]] and is also very well-supported under Funtoo Linux. For this reason, it's recommended that you check out LXD and see what it can do for you.
== Basic Setup on Funtoo ==<!--T:4-->
<!--T:5-->The following steps will show you how to set up a basic LXD environment under Funtoo Linux. This environment will essentially use the default LXD setup -- a will be created called {{c|lxdbr0}} which will use NAT to provide Internet access to your containers. In addition, a default storage pool will be created that will simply use your existing filesystem's storage, creating a directory at {{f|/var/lib/lxd/storage-pools/default}} to store any containers you create. More sophisticated configurations are possible that use dedicated network bridges connected to physical interfaces without NAT, as well as dedicated storage pools that use [[Special:MyLanguage/ZFS|ZFS]] and [[BTRFSSpecial:MyLanguage/btrfs|btrfs]] -- however, these types of configurations are generally overkill for a developer workstation and should only be attempted by advanced users. So we won't cover them here.
=== Requirements ===<!--T:6-->
This section will guide you through setting up the basic requirements for creating an LXD environment.
<!--T:8-->
The first step is to emerge LXD and its dependencies. Perform the following:
</translate>
{{console|body=
# ##i##emerge -a lxd
}}
<translate>
<!--T:9-->
Once LXD is done emerging, we will want to enable it to start by default:
</translate>
{{console|body=
# ##i##rc-update add lxd default
}}
<translate>
<!--T:10-->
In addition, we will want to set up the following files. {{f|/etc/security/limits.conf}} should be modified to have the following lines in it:
</translate>
{{file|name=/etc/security/limits.conf|body=
* soft nofile 1048576
# End of file
}}
<translate>
<!--T:11-->
In addition, we will want to map a set of user ids and group ids to the root user so they are available for its use. Do this by creating the {{f|/etc/subuid}} and {{f|/etc/subgid}} files with the following identical contents:
</translate>
{{file|name=/etc/subuid|body=
root:100000:1000000000
}}
<translate>
</translate>
{{file|name=/etc/subgid|body=
root:100000:1000000000
}}
<translate>
<!--T:12-->
At this point we are ready to initialize and start LXD.
=== Initialization ===<!--T:13-->
<!--T:14-->
To configure LXD, first we will need to start LXD. This can be done as follows:
</translate>
{{console|body=
# ##i##/etc/init.d/lxd start
}}
<translate>
<!--T:15-->
At this point, we can run {{c|lxd init}} to run a configuration wizard to set up LXD:
</translate>
{{console|body=
# ##i##lxd init
Do you want to configure a new storage pool? (yes/no) [default=yes]: ##i##↵
Name of the new storage pool [default=default]: ##i##↵
Name of the storage backend to use (btrfs, dir, lvm) [default=btrfs]: ##i##dir↵dir ↵
Would you like to connect to a MAAS server? (yes/no) [default=no]: ##i##↵
Would you like to create a new local network bridge? (yes/no) [default=yes]: ##i##↵
What should the new bridge be called? [default=lxdbr0]: ##i##↵
What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: ##i##↵
What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: ##i##none
Would you like LXD to be available over the network? (yes/no) [default=no]: ##i##↵
Would you like stale cached images to be updated automatically? (yes/no) [default=yes] ##i##↵
#
}}
<translate>
<!--T:16-->As you can see, we chose all the default ''except'' for :;storage pool, where we : We opted for using a directory-based containerstorage rather than [[BTRFSSpecial:MyLanguage/btrfs|btrfs]]volumes. Now, we should Directory-based may be able the default option during LXD configuration -- it depends if you have btrfs-tools installed or not.;IPv6 address: It is recommended you turn this off unless you are specifically wanting to run play with IPv6 in your containers. It may cause {{c|lxc image listdhcpcd}} and in your container to only retrieve an IPv6 address if you leave it enabled. This is great if you have IPv6 working -- otherwise, you'll get a response from the LXD daemon:dud IPv6 address and no IPv4 address, and thus no network.
{{Warning|As explained above, turn off IPv6 NAT in LXD unless you specifically intend to use it! It can confuse {{c|dhcpcd}}.}}
 
Now, we should be able to run {{c|lxc image list}} and get a response from the LXD daemon:
 
</translate>
{{console|body=
# ##i##lxc image list
#
}}
<translate> <!--T:18-->
If you are able to do this, you have successfully set up the core parts of LXD! Note that we used the command {{c|lxc}} and not {{c|lxd}} like we did for {{c|lxd init}} -- from this point forward, you will use the {{c|lxc}} command. Don't let this
confuse you -- the {{c|lxc}} command is the primary command-line tool for working with LXD containers.
<!--T:19-->
Above, you can see that no images are installed. Images are installable snapshots of containers that we can use to create new containers ourselves. So, as a first step, let's go ahead and grab an image we can use. You will want to browse https://build.funtoo.org for an LXD image that will work on your computer hardware. For example, I was able to download
the following file using {{c|wget}}:
</translate>
{{console|body=
# ##i##wget https://build.funtoo.org/1.3-release-std/x86-64bit/intel64-skylake/lxd-intel64-skylake-1.3-release-std-2019-06-11.tar.xz
}}
<translate>
<!--T:20-->
Once downloaded, this image can be installed using the following command:
</translate>
{{console|body=
# ##i##lxc image import lxd-intel64-skylake-1.3-release-std-2019-06-11.tar.xz --alias funtoo
Image imported with fingerprint: fe4d27fb31bfaf3bd4f470e0ea43d26a6c05991de2a504b9e0a3b1a266dddc69
}}
<translate>
<!--T:21-->
Now you will see the image available in our image list:
</translate>
{{console|body=
# ##i##lxc image list
#
}}
<translate>
=== Final Prep First Container === Now, we are almost ready to create our first container, but first we want to modify the default profile to contain some useful settings. LXD (like Funtoo and Gentoo) also use profiles to manage settings, and there is a default profile thatapplies to all containers. Let's add the following settings to it with these commands<!--T{{console|body=# ##i##lxc profile set default environment.LANG "en_US.UTF24-8"# ##i##lxc profile set default environment.LC_ALL "en_US.UTF-8"# ##i##lxc profile set default environment.LC_COLLATE "POSIX"}} These settings simply serve the purpose of setting some default environment variables, so that when we enter the container with {{c|lxc exec}} without a login shell, it will still have all these environment settings at reasonable defaults. This will get rid of some annoying warning messages when we enter the container. === First Containeer ===>
<!--T:25-->
It is now time to launch our first container. This can be done as follows:
</translate>
{{console|body=
# ##i##lxc launch funtoo testcontainer
Starting testcontainer
}}
<translate>
<!--T:26-->
We can now see the container running via {{c|lxc list}}:
</translate>
{{console|body=
# ##i##lxc list
+---------------+---------+------+-----------------------------------------------+------------+-----------+
{{!}} NAME {{!}} STATE {{!}} IPV4 {{!}} IPV6 {{!}} TYPE {{!}} SNAPSHOTS {{!}}
+---------------+---------+------+-----------------------------------------------+------------+-----------+
{{!}} testcontainer {{!}} RUNNING {{!}} {{!}} fd42:8063:81cb:988c:216:3eff:fe2a:f901 (eth0) {{!}} PERSISTENT {{!}} {{!}}
#
}}
<translate><!--T:29-->
By default, our new container {{c|testcontainer}} will use the default profile, which will connect an {{c|eth0}} interface in the container to NAT, and will also use our directory-based LXD storage pool. We can now enter the container as follows:
</translate>
{{console|body=
# ##i##lxc exec testcontainer -- /bin/bashsu --login##r##%testcontainer ##bl##~ #%
}}
<translate>
<!--T:30-->
As you might have noticed, we do not yet have any IPv4 networking configured. While LXD has set up a bridge and NAT for us, along with a DHCP server to query, we actually need to use {{c|dhcpcd}} to query for an IP address, so let's get that set up:
</translate>
{{console|body=
##r##%testcontainer ##bl##~ # % ##i##echo "template=dhcpcd" > /etc/conf.d/netif.eth0##r##%testcontainer ##bl##~ # % ##i##cd /etc/init.d##r##%testcontainer ##bl##/etc/init.d # % ##i##ln -s netif.tmpl netif.eth0##r##%testcontainer ##bl##/etc/init.d # % ##i##rc-update add netif.eth0 default
* service netif.eth0 added to runlevel default
##r##%testcontainer ##bl##/etc/init.d # % ##i##rc
* rc is deprecated, please use openrc instead.
* Caching service dependencies ... [ ##g##ok ##!g##]
* Starting DHCP Client Daemon ... [ ##g##ok ##!g##]
* Network dhcpcd eth0 up ... [ ##g##ok ##!g##]
##r##%testcontainer ##bl##/etc/init.d # % ##i##
}}
<translate>
=== Features === Some of the biggest features of LXD are: * Secure by design (unprivileged containers, resource restrictions and much more)* Scalable (from containers on your laptop to thousand of compute nodes)* Intuitive (simple, clear API and crisp command line experience)* Image based (no more distribution templates, only good, trusted images)* Live migration ==== Unprivileged Containers ==== LXD uses unprivileged containers by default. The difference between an unprivileged container and a privileged one is whether the root user in the container is the “real” root user (uid 0 at the kernel level). The way unprivileged containers are created is by taking a set of normal UIDs and GIDs from the host, usually at least 65536 of each (to be POSIX compliant) and mapping those into the container. The most common example and what most LXD users will end up with by default is a map of 65536 UIDs and GIDs, with a host base id of 100000. This means that root in the container (uid 0) will be mapped to the host uid 100000 and uid 65535 in the container will be mapped to uid 165535 on the host. UID/GID 65536 and higher in the container aren’t mapped and will return an error if you attempt to use them. From a security point of view, that means that anything which is not owned by the users and groups mapped into the container will be inaccessible. Any such resource will show up as being owned by uid/gid “-1” (rendered as 65534 or nobody/nogroup in userspace). It also means that should there be a way to escape the container, even root in the container would find itself with just as much privileges on the host as a nobody user. LXD does offer a number of options related to unprivileged configuration: * Increasing the size of the default uid/gid map* Setting up per-container maps* Punching holes into the map to expose host users and groups === Relationship with LXC ===LXD isn't a rewrite of LXC, in fact it's building on top of LXC to provide a new, better user experience. Under the hood, LXD uses LXC through liblxc and its Go bindingto create and manage the containers. It's basically an alternative to LXC's tools and distribution template system with the added features that come from being controllable over the network. === Licensing ===LXD is free software and is developed under the Apache 2 license. <hr><hr>Let's break this tutorial into smaller parts. Please click on the headings to go to the section's text. <hr><hr> == [[LXD/LXD Installation|PART II - LXD Installation]] == == [[LXD/LXD Setup|PART III - LXD Setup]] == == Containers, snapshots and images =='''Containers''' in LXD are made of:* A filesystem (rootfs)* A list of configuration options, including resource limits, environment, security options and more* A bunch of devices like disks, character/block unix devices and network interfaces* A set of profiles the container inherits configuration from (see below)* Some properties (container architecture, ephemeral or persistent and the name)* Some runtime state (when using CRIU for checkpoint/restore) Container '''snapshots''' as the name states snapshots of the container in time and cannot be modified in any way. It is worth noting that because snapshots can store the container runtime state, which gives us ability of “stateful” snapshots. That is, the ability to rollback the container including its cpu and memory state at the time of the snapshot. LXD is '''image''' based, all LXD containers come from an image. Images are typically clean Linux distribution images similar to what you would use for a virtual machine or cloud instance. It is possible to “publish” a container, making an image from it which can then be used by the local or remote LXD hosts. === Our first image ===Let's get our hands even more dirty and create our first image. We will be using a generic 64 bit Funtoo Linux image.  {{note|The Funtoo's default build host is building only westmere stage for now.}} Grab the image here:https://build.funtoo.org/funtoo-current/x86-64bit/intel64-westmere/lxd-latest.tar.xz Grab also the hash file:https://build.funtoo.org/funtoo-current/x86-64bit/intel64-westmere/lxd-latest.tar.xz.hash.txt {{tip|Check the hash of the downloaded file against the one from server. Proceed if they match. }} ==== Import the image ====After we have successfully downloaded the archive we can now finally import it into LXD and start using it as our "seed" image for all our containers.{{console|body=###i## lxc image import lxd-latest.tar.xz --alias funtooImage imported with fingerprint: 6c2ca3af0222d503656f5a1838885f1b9b6aed2c1994f1d7ef94e2efcb7233c4###i## lxc image ls<nowiki>+--------+--------------+--------+------------------------------------+--------+----------+-----------------------------+| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCH | SIZE | UPLOAD DATE |+--------+--------------+--------+------------------------------------+--------+----------+---------------------!--------+| funtoo | 6c2ca3af0222 | no | Funtoo Current Generic Pure 64-bit | x86_64 |227.99MB | Dec 13, 2017 at 11T:01pm (UTC) |+--------+--------------+--------+------------------------------------+--------+----------+--------------------31---------+</nowiki>}}And there we have our very first Funtoo Linux image imported inside LXD. You can reference the image through the alias or through the fingerprint. Aliases can be added also later. Let me show you some basic usage then. === Creating your first container ===So now we can launch our first container. That is done using this command: see that {{console|body=###i## lxc launch funtoo fun-1Creating fun-1Starting fun-1###i## lxc ls<nowiki>+-------+---------+------+-----------------------------------------------+------------+-----------+| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |+-------+---------+------+-----------------------------------------------+------------+-----------+| fun-1 | RUNNING | c| fd42:156d:4593:a619:216:3eff:fef7:c1c2 (eth0) | PERSISTENT | 0 |+-------+---------+------+-----------------------------------------------+------------+-----------+</nowiki>}} {{tip|lxc launch is a shortcut for lxc init and lxc start, lxc init creates the container without starting it. }} ==== Profiles intermezzo ====LXD has the ability to change quite a few container settings, including resource limitation, control of container startup and a variety of device pass-through options using what is called profiles. Multiple profiles can be applied to a single container, and the last profile overrides the other ones it the resources being configured is the same for multiple profiles. Let me show you how can this be used. This is the default profile that gets inherited by all containers.{{console|body=###i## lxc profile list<nowiki>+---------+---------+| NAME | USED BY |+---------+---------+| default | 1 |+---------+---------+</nowiki>###i## lxc profile show defaultconfig: {}description: Default LXD profiledevices: eth0: nictype: bridged parent: lxdbr0 type: nic root: path: / pool: default type: diskname: defaultused_byvalid IPv4 address:- /1.0/containers/fun-1}} Now let's edit this profile for our funtoo containers. It will include some useful stuff.
</translate>
{{console|body=
#%testcontainer% ##i## lxc profile set default raw.lxc "lxc.mount.entry ifconfigeth0: flags= none dev/shm tmpfs rw4163<UP,nosuidBROADCAST,nodevRUNNING,create=dir"MULTICAST> mtu 1500###i## lxc profile set default environment inet 10.212.194.17 netmask 255.255.255.0 broadcast 10.212.LANG "en_US194.UTF-8"255###i## lxc profile set default environment inet6 fd42:8063:81cb:988c:25ea:b5bd:603d:8b0d prefixlen 64 scopeid 0x0<global> inet6 fe80::216:3eff:fe2a:f901 prefixlen 64 scopeid 0x20<link> ether 00:16:3e:2a:f9:01 txqueuelen 1000 (Ethernet) RX packets 45 bytes 5385 (5.LC_ALL "en_US2 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 20 bytes 2232 (2.UTF-8"1 KiB)###i## lxc profile set default environment.LC_COLLATE "POSIX" TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
}}
<translate>
Profiles can store any configuration What happened is that LXD set up a container can DHCP server for us (key/value or devicesdnsmasq) running on our private container network, and any number of profiles can be applied automatically offers IP addresses to a containerour containers. Profiles are applied in It also configured iptables for us to NAT the order they are specified connection so the last profile to specify a specific key wins. In any case, resource-specific configuration always overrides that coming from the profilesoutbound Internet access should magically workThe default profile is set for any new You should also be able to see this IPv4 address listed in the container created which doesn't specify a different profiles listwhen you type {{c|lxc list}} on your host system.
{{note|LXD supports simple instance types. Those are represented as a string which can be passed at container creation time. [https://github.com/lxc/lxd/blob/master/doc/containers.md#instance-types containers.md#instance-types]}}=== Network Troubleshooting ===
=== Using our first container ===After we have done all these customizations we can now start using our Note that if you are having issues with your containergetting an IPv4 address via DHCP, make sure that you turn IPv6 off in LXD.Do thisThe next command will give us shell inside the container.by running:
{{console|body=
###i## lxc exec fun-1 bashnetwork edit lxdbr0
}}
Now you should see a different prompt starting withThen, change {{c|ipv6.nat}} to {{c|"false"}} and restart lxd and the container:
{{console|body=
fun-1 ~ ###i## /etc/init.d/lxd restart###i## lxc restart testcontainer
}}
If we run top or ps for example we will see only This should resolve the processes of the containerissue.
{{console|body=fun-1 ~ # ps auxUSER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMANDroot 1 0.0 0.0 4248 748 ? Ss+ 13:20 0:00 init [3]root 266 0.0 0.0 30488 472 ? Ss 13:20 0:00 /usr/sbin/sshdroot 312 0.2 0.0 17996 3416 ? Ss 13:29 0:00 bashroot 317 0.0 0.0 19200 2260 ? R+ 13:29 0:00 ps aux}} As you can see only the container's processes are shown. User running the processes is root here. What happens if we search for all sshd processes for example on the host box? {{console|body=###i## <nowiki>ps aux|grep sshroot 14505 0.0 0.0 30564 1508 ? Ss Sep07 0:00 /usr/sbin/sshd 100000 25863 0.0 0.0 30488 472 ? Ss 15:20 0:00 /usr/sbin/sshd root 29487 0.0 0.0 8324 828 pts/2 S+ 15:30 0:00 grep --colour=auto sshd</nowiki>###i##}} So as you can see, the sshd process is running under user with uid 100000 on the host machine and has a different PID.Finishing Steps ===
=== Basic actions with containers ===<!--T:32-->==== Listing containers ====Assuming your network is now working, you are ready to start using your new Funtoo container. Time to have some fun! Go ahead and run {{c|ego sync}} and then emerge your favorite things:</translate>
{{console|body=
#%testcontainer% ##i## lxc lsego sync<nowiki>+-------+---------+----------------\##g##Syncing meta-------+------------------------------------------------+------------+-----------+repo| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |+-------+---------+-----------------------+------------------------------------------------+-----Cloning into '/var/git/meta-------+-----------+| fun-1 | RUNNING | 10.214.101repo'.187 (eth0) | fd42:156d:4593:a619:a5ad:edaf:7270:e6c4 (eth0) | PERSISTENT | 0 || | | | fd42:156d:4593:a619:216:3eff:fef7:c1c2 (eth0) | | |+-------+---------+-----------------------+------------------------------------------------+------------+-----------+</nowiki>}}lxc ls also accepts arguments as filters. For example lxc ls web will list all containers that have web in their name.
==== Container details ====
{{console|body=
###i## lxc info c1
Name: c1
Remote: unix://
Architecture: x86_64
Created: 2017/09/08 02:07 UTC
Status: Running
Type: persistent
Profiles: default, prf-funtoo
Pid: 6366
Ips:
eth0: inet 10.214.101.79 vethFG4HXG
eth0: inet6 fd42:156d:4593:a619:8619:546e:43f:2089 vethFG4HXG
eth0: inet6 fd42:156d:4593:a619:216:3eff:fe4a:3d4f vethFG4HXG
eth0: inet6 fe80::216:3eff:fe4a:3d4f vethFG4HXG
lo: inet 127.0.0.1
lo: inet6 ::1
Resources:
Processes: 6
CPU usage:
CPU usage (in seconds): 25
Memory usage:
Memory (current): 69.01MB
Memory (peak): 258.92MB
Network usage:
eth0:
Bytes received: 83.65kB
Bytes sent: 9.44kB
Packets received: 188
Packets sent: 93
lo:
Bytes received: 0B
Bytes sent: 0B
Packets received: 0
Packets sent: 0
}}
 ==== Container configuration ===={{console|body=###i## lxc config edit c1### This is a yaml representation of the configuration.### Any line starting with a '# will be ignored.###### A sample configuration looks like:### name: container1### profiles:### - default### config:### volatile.eth0.hwaddr: 00:16:3e:e9:f8:7f### devices:### homedir:### path: /extra### source: /home/user### type: disk### ephemeral: false###### Note that the name is shown but cannot be changed architecture: x86_64config: image.architecture: x86_64 image.description: Funtoo Current Generic Pure 64-bit image.name: funtoo-generic_64-pure64-funtoo-current-2016-12-10 image.os: funtoo image.release: "1.0" image.variant: current volatile.base_image: e279c16d1a801b2bd1698df95e148e0a968846835f4769b24988f2eb3700100f volatile.eth0.hwaddr: 00:16:3e:4a:3d:4f volatile.eth0.name: eth0 volatile.idmap.base: "0" volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]' volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]' volatile.last_state.power: RUNNINGdevices: {}ephemeral: falseprofiles:- default- prf-funtoostateful: falsedescription: ""}} One can also add environment variables.{{console|body=###i## lxc config set <containertranslate> environment.LANG en_US.UTF-8###i## lxc config set <container> environment.LC_COLLATE POSIX}} === Managing files === === Snapshots === === Cloning, copying and moving containers === === Resource control ===LXD offers a variety of resource limits. Some of those are tied to the container itself, like memory quotas, CPU limits and I/O priorities. Some are tied to a particular device instead, like I/O bandwidth or disk usage limits. As with all LXD configuration, resource limits can be dynamically changed while the container is running. Some may fail to apply, for example if setting a memory value smaller than the current memory usage, but LXD will try anyway and report back on failure. All limits can also be inherited through profiles in which case each affected container will be constrained by that limit. That is, if you set limits.memory=256MB in the default profile, every container using the default profile (typically all of them) will have a memory limit of 256MB. ==== Disk ====Setting a size limit on the container’s filesystem and have it enforced against the container. Right now LXD only supports disk limits if you’re using the ZFS or btrfs storage backend. To set a disk limit (requires btrfs or ZFS): {{console|body=###i## lxc config device set c1 root size 20GB}} ==== CPU ====To just limit a container to any 2 CPUs, do: {{console|body=###i## lxc config set c1 limits.cpu 2}} To pin to specific CPU cores, say the second and fourth: {{console|body=###i## lxc config set c1 limits.cpu 1,3}} More complex pinning ranges like this works too: {{console|body=###i## lxc config set c1 limits.cpu 0!-3,7-11}} ==== Memory ====To apply a straightforward memory limit runT{{console|body=###i## lxc config set c1 limits.memory 256MB}} (The supported suffixes are kB, MB, GB, TB, PB and EB) To turn swap off for the container (defaults to enabled): {{console|body=###i## lxc config set c1 limits.memory.swap false}}To tell the kernel to swap this container’s memory first: {{console|body=###i## lxc config set c1 limits.memory.swap.priority 0}}And finally if you don’t want hard memory limit enforcement: {{console|body=###i## lxc config set c1 limits.memory.enforce soft}} ==== Network ======== Block I/O ==== === Resource limits using profile 121-- Funtoo Containers example ===So I am going to create 3 profiles to mimic the resource limits for current Funtoo Containers.  {{TableStart}}<tr class="danger"><th>Price</th><th>RAM</th><th>CPU Threads</th><th>Disk Space</th><th>Sign Up</th></tr><tr><td>'''$15/mo'''</td><td>4GB</td><td>6 CPU Threads</td><td>50GB</td><td>[https://funtoo.chargebee.com/hosted_pages/plans/container_small Sign Up! (small)]</td></tr><tr><td>'''$30/mo'''</td><td>12GB</td><td>12 CPU Threads</td><td>100GB</td><td>[https://funtoo.chargebee.com/hosted_pages/plans/container_medium Sign Up! (medium)]</td></tr><tr><td>'''$45/mo'''</td><td>48GB</td><td>24 CPU Threads</td><td>200GB</td><td>[httpsCategory://funtoo.chargebee.com/hosted_pages/plans/container_large Sign Up! (large)]</td></tr>{{TableEnd}} I am going to create one profile and copy/edit it for the remaining two options. {{console|body=###i## lxc profile create res-small###i## lxc profile edit res-smallconfig: limits.cpu: "6" limits.memory: 4GBdescription: Small Variant of Funtoo Containersdevices: root: path: / pool: default size: 50GB type: diskname: smallused_by: []###i## lxc profile copy res-small res-medium###i## lxc profile copy res-small res-large###i## lxc profile set res-medium limits.cpu 12###i## lxc profile set res-medium limits.memory 12GB###i## lxc profile device set res-medium root size 100GB###i## lxc profile set res-large limits.cpu 24###i## lxc profile set res-large limits.memory 48GB###i## lxc profile device set res-large root size 200GB}}Now let's create a container and assign the res-small and funtoo profiles to it.{{console|body=###i## lxc init funtoo c-small###i## lxc profile assign c-small res-small###i## lxc profile add c-small funtoo}} === Image manipulations === === Remote hosts === == Running systemd container on a non-systemd host ==To use systemd in the container, a recent enough (>=4.6) kernel version with support for cgroup namespaces is needed. Funtoo's openrc has the fix to mount systemd cgroups, which is sufficient to run systemd based distributions lxd containers.  If you want to get <code>systemd</code> hierarchy mounted automatically on system startup, using <code>/etc/fstab</code> will not work, but the {{Package|dev-libs/libcgroup}} can be used for this. First you needed to edit the <code>/etc/cgroup/cgconfig.conf</code> and add:{{file|name=/etc/cgroup/cgconfig.conf|body=mount { "name=systemd" = /sys/fs/cgroup/systemd;}}}Then you need to start the cgconfig daemon:{{console|body=###i## rc-service cgconfig start}}The daemon can be started as needed, or automatically at system start by simply adding it to default group:{{console|body=###i## rc-update add cgconfig default}} <hr><hr> == [[LXD/LXD in LXD|PART X - LXD in LXD]] ==== [[LXD/Docker in LXD|PART Y - Docker in Category:LXD]] == == [[LXD/FAQ|PART Z - LXD FAQCategory:Official Documentation]] == == List of tested and working images ==These are images from the https://images.linuxcontainers.org repository available by default in lxd. You can list all available images by typing following command (beware the list is very long):{{console|body=###i## lxc image list images:<nowiki>+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCH | SIZE | UPLOAD DATE |+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+| alpine/3.3 (3 more) | ef69c8dc37f6 | yes | Alpine 3.3 amd64 (20171018_17:50) | x86_64 | 2.00MB | Oct 18, 2017 at 12:00am (UTC) |+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+| alpine/3.3/armhf (1 more) | 5ce4c80edcf3 | yes | Alpine 3.3 armhf (20170103_17:50) | armv7l | 1.53MB | Jan 3, 2017 at 12:00am (UTC) |+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+| alpine/3.3/i386 (1 more) | cd1700cb7c97 | yes | Alpine 3.3 i386 (20171018_17:50) | i686 | 1.84MB | Oct 18, 2017 at 12:00am (UTC) |+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+| alpine/3.4 (3 more) | bd4f1ccfabb5 | yes | Alpine 3.4 amd64 (20171018_17:50) | x86_64 | 2.04MB | Oct 18, 2017 at 12:00am (UTC) |+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+| alpine/3.4/armhf (1 more) | 9fe7c201924c | yes | Alpine 3.4 armhf (20170111_20:27) | armv7l | 1.58MB | Jan 11, 2017 at 12:00am (UTC) |+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+| alpine/3.4/i386 (1 more) | 188a31315773 | yes | Alpine 3.4 i386 (20171018_17:50) | i686 | 1.88MB | Oct 18, 2017 at 12:00am (UTC) |+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+| alpine/3.5 (3 more) | 63bebc672163 | yes | Alpine 3.5 amd64 (20171018_17:50) | x86_64 | 1.70MB | Oct 18, 2017 at 12:00am (UTC) |+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+| alpine/3.5/i386 (1 more) | 48045e297515 | yes | Alpine 3.5 i386 (20171018_17:50) | i686 | 1.73MB | Oct 18, 2017 at 12:00am (UTC) |+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+...+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+| | fd95a7a754a0 | yes | Alpine 3.5 amd64 (20171016_17:50) | x86_64 | 1.70MB | Oct 16, 2017 at 12:00am (UTC) |+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+| | fef66668f5a2 | yes | Debian stretch arm64 (20171016_22:42) | aarch64 | 96.56MB | Oct 16, 2017 at 12:00am (UTC) |+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+| | ff18aa2c11d7 | yes | Opensuse 42.3 amd64 (20171017_00:53) | x86_64 | 58.92MB | Oct 17, 2017 at 12:00am (UTC) |+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+| | ff4ef0d824b6 | yes | Ubuntu zesty s390x (20171017_03:49) | s390x | 86.88MB | Oct 17, 2017 at 12:00am (UTC) |+---------------------------------+--------------+--------+------------------------------------------+---------+----------+-------------------------------+</nowikitranslate>}} These are the images that are known to work with current LXD setup on Funtoo Linux:{| class="wikitable sortable"|-! Image !! Init !! Status|-| CentOS 7 || systemd || Working|-| Debian Jessie (8) - EOL April/May 2020|| systemd || Working (systemd - no failed units)|-| Debian Stretch (9) - EOL June 2022|| systemd || Working|-| Fedora 26 || systemd with cgroup v2|| Not Working|-| Fedora 25 || systemd || Working|-| Fedora 24 || systemd || Working|-| Oracle 7 || systemd || Working (systemd - no failed units)|-| OpenSUSE 42.2 || systemd || Working|-| OpenSUSE 42.3 || systemd || Working|-| Ubuntu Xenial (16.04 LTS) - EOL 2021-04 || systemd || Working|-| Ubuntu Zesty (17.04) - EOL 2018-01 || systemd || Working|-| Alpine 3.3 || OpenRC || Working|-| Alpine 3.4 || OpenRC || Working|-| Alpine 3.5 || OpenRC || Working|-| Alpine 3.6 || OpenRC || Working|-| Alpine Edge || OpenRC || Working|-| Archlinux || systemd with cgroup v2 || Not Working|-| CentOS 6 || upstart || Working (systemd - no failed units)|-| Debian Buster || systemd with cgroup v2 || Not Working|-| Debian Sid || systemd with cgroup v2 || Not working|-| Debian Wheezy (7) - EOL May 2018 || ? || ? (more testing needed)|-| Gentoo || OpenRC || Working (all services started)|-| Oracle 6 || upstart || ? (mount outputs nothing)|-| Plamo 5 || ? || ?|-| Plamo 6 || ? || ?|-| Sabayon || systemd with cgroup v2 || Not Working|-| Ubuntu Artful (17.10) - EOL 2018-07|| systemd with cgroup v2 || Not Working|-| Ubuntu Core 16 || ? || ?|-| Ubuntu Trusty (14.04 LTS) - EOL 2019-04 || upstart || Working|} [[Category:Virtualization]]
110
edits

Navigation menu