Difference between revisions of "LXD"
(→Setup: Remove lxd init and user configuration from snap installation method) |
(→No ipv4 on unprivileged Arch container: flag with Template:Remove) |
||
| (6 intermediate revisions by 3 users not shown) | |||
| Line 17: | Line 17: | ||
An alternative method of installation is via [[snapd]], by installing the {{AUR|snapd}} package and running: | An alternative method of installation is via [[snapd]], by installing the {{AUR|snapd}} package and running: | ||
| − | + | # snap install lxd | |
=== Configure LXD === | === Configure LXD === | ||
| Line 29: | Line 29: | ||
# usermod -a -G lxd <user> | # usermod -a -G lxd <user> | ||
| + | == Basic usage == | ||
| + | === Create container === | ||
| + | |||
| + | LXD has two parts, the daemon (the lxd binary), and the client (the lxc binary). Now that the daemon is all configured and running, you can create a container: | ||
| + | |||
| + | $ lxc launch ubuntu:16.04 | ||
| + | |||
| + | Alternatively, you can also use a remote LXD host as a source of images. One comes pre-configured in LXD, called "images" (images.linuxcontainers.org) | ||
| + | |||
| + | $ lxc launch images:centos/7/amd64 centos | ||
| + | |||
| + | == Advance usage == | ||
=== LXD Networking === | === LXD Networking === | ||
| Line 71: | Line 83: | ||
If you encounter issue with the provided example configuration, or have suggestions to improve it, please leave a comment on the {{AUR|lxd}} page. | If you encounter issue with the provided example configuration, or have suggestions to improve it, please leave a comment on the {{AUR|lxd}} page. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
=== Modify processes and files limit === | === Modify processes and files limit === | ||
| Line 98: | Line 98: | ||
== Troubleshooting == | == Troubleshooting == | ||
=== Check kernel config === | === Check kernel config === | ||
| − | Verify that the running kernel is properly configured to run a container: | + | By default Arch Linux kernel is compiled correctly for Linux Containers and its frontend LXD. However, if you're using a custom kernel, or changed kernel options the kernel might be configured incorrectly. Verify that the running kernel is properly configured to run a container: |
$ lxc-checkconfig | $ lxc-checkconfig | ||
| + | |||
=== Launching container without CONFIG_USER_NS === | === Launching container without CONFIG_USER_NS === | ||
For launching images you must provide {{ic|1=security.privileged=true}} during image creation: | For launching images you must provide {{ic|1=security.privileged=true}} during image creation: | ||
| Line 127: | Line 128: | ||
=== No ipv4 on unprivileged Arch container === | === No ipv4 on unprivileged Arch container === | ||
| + | |||
| + | {{Remove|As of systemd v239, this issue has been [https://github.com/lxc/lxd/issues/4071#issuecomment-405868612 fixed]. Updating {{pkg|systemd}} should fix this issue without the workaround below.}} | ||
This was tested and validated on LXD v.2.20. The container can not start the {{ic|1=systemd-networkd}} service so does not get a valid ipv4 address. A work-around was suggested by Stéphane Graber ([https://github.com/lxc/lxd/issues/4071 Github Issue]), execute on the host and restart the container: | This was tested and validated on LXD v.2.20. The container can not start the {{ic|1=systemd-networkd}} service so does not get a valid ipv4 address. A work-around was suggested by Stéphane Graber ([https://github.com/lxc/lxd/issues/4071 Github Issue]), execute on the host and restart the container: | ||
| Line 133: | Line 136: | ||
:stgraber: "The reason is that the networkd systemd unit somehow makes use of the kernel keyring, which doesn't work inside unprivileged containers right now. The line above makes that system call return not-implemented which is enough of a workaround to get things going again." | :stgraber: "The reason is that the networkd systemd unit somehow makes use of the kernel keyring, which doesn't work inside unprivileged containers right now. The line above makes that system call return not-implemented which is enough of a workaround to get things going again." | ||
| + | |||
| + | === Resource limits are not applied when viewed from inside a container === | ||
| + | |||
| + | The service lxcfs (found in the Community repository) needs to be installed and started : | ||
| + | |||
| + | $ systemctl start lxcfs | ||
| + | |||
| + | lxd will need to be restarted. Enable lxcfs for the service to be started at boot time. | ||
== See also == | == See also == | ||
Latest revision as of 08:06, 23 July 2018
LXD is a container "hypervisor" and a new user experience for Linux Containers.
Setup
Required software
Install LXC and the lxdAUR package, then start lxd.service.
See Linux Containers#Enable support to run unprivileged containers (optional) if you want to run unprivileged containers. Otherwise see #Launching container without CONFIG_USER_NS.
Alternative installation method
An alternative method of installation is via snapd, by installing the snapdAUR package and running:
# snap install lxd
Configure LXD
LXD needs to configure a storage pool, and (if you want internet access) network configuration. To do so, run the following as root:
# lxd init
Accessing LXD as a unprivileged user
By default the LXD daemon allows users in the lxd group access, so add your user to the group:
# usermod -a -G lxd <user>
Basic usage
Create container
LXD has two parts, the daemon (the lxd binary), and the client (the lxc binary). Now that the daemon is all configured and running, you can create a container:
$ lxc launch ubuntu:16.04
Alternatively, you can also use a remote LXD host as a source of images. One comes pre-configured in LXD, called "images" (images.linuxcontainers.org)
$ lxc launch images:centos/7/amd64 centos
Advance usage
LXD Networking
LXD uses LXC's networking capabilities. By default it connects containers to the lxcbr0 network device. Refer to the LXC documentation on network configuration to set up a bridge for your containers.
If you want to use a different interface than lxcbr0 edit the default using the lxc command line tool:
$ lxc profile edit default
An editor will open with a config file that by default contains:
name: default
config: {}
devices:
eth0:
name: eth0
nictype: bridged
parent: lxcbr0
type: nic
You can set the parent parameter to whichever bridge you want LXD to attach the containers to by default.
Example network configuration
Thanks to @jpic, the LXD package now provides some example networking configuration in /usr/share/lxd/. To use this configuration run the following commands:
$ ln -s /usr/share/lxd/dnsmasq-lxd.conf /etc/dnsmasq-lxd.conf $ ln -s /usr/share/lxd/systemd/system/dnsmasq@lxd.service /etc/systemd/system/dnsmasq@lxd.service $ ln -s /usr/share/lxd/netctl/lxd /etc/netctl/lxd $ ln -s /usr/share/lxd/dbus-1/system.d/dnsmasq-lxd.conf /etc/dbus-1/system.d/dnsmasq-lxd.conf
If you use NetworkManager, also symlink the following file:
$ ln -s /usr/share/lxd/NetworkManager/dnsmasq.d/lxd.conf /etc/NetworkManager/dnsmasq.d/lxd.conf
Change parent: lxcbr0 to parent: lxd:
$ lxc profile edit default
Finally, enable and start dnsmasq@lxd.service and netctl@lxd.service.
If you encounter issue with the provided example configuration, or have suggestions to improve it, please leave a comment on the lxdAUR page.
Modify processes and files limit
You may want to increase file descriptor limit or max user processes limit, since default file descriptor limit is 1024 on Arch Linux.
Edit the lxd.service:
# systemctl edit lxd.service
[Service] LimitNOFILE=infinity LimitNPROC=infinity TasksMax=infinity
Troubleshooting
Check kernel config
By default Arch Linux kernel is compiled correctly for Linux Containers and its frontend LXD. However, if you're using a custom kernel, or changed kernel options the kernel might be configured incorrectly. Verify that the running kernel is properly configured to run a container:
$ lxc-checkconfig
Launching container without CONFIG_USER_NS
For launching images you must provide security.privileged=true during image creation:
$ lxc launch ubuntu:16.04 ubuntu -c security.privileged=true
Or for already existed image you may edit config:
$ lxc config edit ubuntu
name: ubuntu
profiles:
- default
config:
...
security.privileged: "true"
...
devices:
root:
path: /
type: disk
ephemeral: false
Or to enable security.privileged=true for new containers, edit the config for the default profile:
$ lxc profile edit default
No ipv4 on unprivileged Arch container
This was tested and validated on LXD v.2.20. The container can not start the systemd-networkd service so does not get a valid ipv4 address. A work-around was suggested by Stéphane Graber (Github Issue), execute on the host and restart the container:
$ lxc profile set default security.syscalls.blacklist "keyctl errno 38"
- stgraber: "The reason is that the networkd systemd unit somehow makes use of the kernel keyring, which doesn't work inside unprivileged containers right now. The line above makes that system call return not-implemented which is enough of a workaround to get things going again."
Resource limits are not applied when viewed from inside a container
The service lxcfs (found in the Community repository) needs to be installed and started :
$ systemctl start lxcfs
lxd will need to be restarted. Enable lxcfs for the service to be started at boot time.