Incus

これは元の保守者による LXD のフォークです。LXD Wiki ページのドキュメントはまだ大部分が関連しており、読むことを推奨します。

インストール

incus パッケージをインストールし、incus.socketを有効化します。

また、例えばインスタンスを自動起動させたい場合は、incus.service を直接、有効化/起動することもできます。

コンテナ作成をユーザーに委任するには、incus-user.socket ユニットを有効化/起動します。グループ委任については #Accessing Incus as an unprivileged user を参照してください。

LXD からの移行

既存の LXD インストールから移行する場合は、この時点で行う必要があります。移行ツールは空のターゲット Incus サーバーに対してのみ実行されるためです。

lxc info と incus info コマンドが正しく動作していることを確認した後、上流の documentation を読み、その後で移行ツールを実行してください:

# lxd-to-incus

設定

非特権コンテナ

非特権コンテナの使用を推奨します (違いの説明については Linux コンテナ#特権コンテナと非特権コンテナを参照)。

これを行うには、コンテナ化された uid/gid ペアに対するマッピングを含むように /etc/subuid と /etc/subgid (これらのファイルが存在しない場合は作成する) を変更します。以下の例は単に root ユーザー (および systemd システムユニット) 用です:

以下のように usermod を使用することもできます:

usermod -v 1000000-1000999999 -w 1000000-1000999999 root

または、上記のファイルを直接以下のように変更します:

/etc/subuid

root:1000000:1000000000

/etc/subgid

root:1000000:1000000000

これで、すべてのコンテナはデフォルトで非特権で起動されます。

代替案については LXD#特権コンテナを参照してください。

Incus の設定

最初の起動時に、Incus を設定する必要があります。

root として実行:

# incus admin init

これにより、ストレージ、ネットワークなどの異なるトピックをカバーする対話式の設定ガイドがターミナルで開始されます。

公式の Getting Started Guide で概要を確認できます。

非特権ユーザーとして Incus にアクセスする

Incus は2つのユーザーグループを定義しています:

incus "基本的なユーザーアクセスを許可し、設定なしで全てのアクションはユーザープロジェクトごとに制限されます。"
incus-admin "Incus の完全な制御を許可します。"

すべてのコマンドを root として実行する必要なく Incus を制御するためには、あなたのユーザーをこれらのグループに追加します。

警告: incus-admin グループに追加された人は root と同等です。詳細は [1] と [2] を参照してください。

Usage

Overview of commands

You can get an overview of all available commands by typing:

$ incus

Create a container

You can create a container with incus launch, for example:

$ incus launch ubuntu:20.04

Container are based on images, that are downloaded from image servers or remote LXD servers.

You can see the list of already added servers with:

$ incus remote list

You can list all images on a server with incus image list, for example:

$ incus image list images:

This will show you all images on one of the default servers: images.linuxcontainers.org

You can also search for images by adding terms like the distribution name:

$ incus image list images:debian

Launch a container with an image from a specific server with:

$ incus launch servername:imagename

For example:

$ incus launch images:centos/8/amd64 centos

To create an amd64 Arch container:

$ incus launch images:archlinux/current/amd64 arch

Tips and tricks

Access the containers by name on the host

This assumes that you are using the default bridge that it is named incusbr0 and that you are using systemd-resolved.

# systemd-resolve --interface incusbr0 --set-domain '~incus' --set-dns $(incus network get incusbr0 ipv4.address | cut -d / -f 1)

You can now access the containers by name:

$ ping containername.incus

Troubleshooting

Starting a virtual machine fails

If you see the error:

Error: Couldn't find one of the required UEFI firmware files: [{code:OVMF_CODE.4MB.fd vars:OVMF_VARS.4MB.ms.fd} {code:OVMF_CODE.2MB.fd vars:OVMF_VARS.2MB.ms.fd} {code:OVMF_CODE.fd vars:OVMF_VARS.ms.fd} {code:OVMF_CODE.fd vars:qemu.nvram}]

It's because Arch Linux does not distribute secure boot signed ovmf firmware. To boot virtual machines, you need to disable secure boot for the time being:

$ incus launch ubuntu:18.04 test-vm --vm -c security.secureboot=false

This can also be added to the default profile by doing:

$ incus profile set default security.secureboot=false

Incus does not respect Shell's environment proxy variables

Examples are incus launch or incus image commands not using value of *_proxy/*_PROXY variables when downloading images.

Incus implements a server-client paradigm. It simply means that operations are done by incusd acting as the Incus server — usually running in the background, unless invoked from an interactive shell. And incus commandline interface is used to communicate with Incus server acting as the Incus client.

That makes incusd, typically started as a service, not inheriting shell's environment variables of the client. But respecting variables of the environment that it's invoked from, instead.[3] In Arch Linux, Incus server is started by systemd.

There can be many workarounds to this difficulty, following exist some examples. See Incus's issue#574 for more information.

Temporary

Import Shell variables to systemd's environment

First, export *_PROXY variables:

$ export ALL_PROXY="socks://proxy_server_address:port/"

Import them to systemd's environment:

# systemctl import-environment ALL_PROXY

Re/start incus.service unit.

ヒント: Use systemctl unset-environment command to unset a variable and restart the service.

Persistent

Edit incus service unit

If you want Incus daemon to always start with some static environment variables, like *_proxy, you can use Environment directive of systemd. systemctl set-property command cannot manipulate Environment directive. Edit incus.service and add Environment key with appropriate variableテンプレート:=value pair. For example:

# systemctl edit incus.service

...

[Service]
Environmentテンプレート:=ALL_PROXYテンプレート:="socks://proxy_server_address:port/"

...

Use Incus core.proxy options

One can make Incus server use a desired proxy with configuring Incus's server with core.proxy options. For instance:

# incus config set core.proxy_http "proxy_address:proxy_port"

ノート: core.proxy options have global scopes. I.e. they apply to cluster members, immediately.

Uninstall

Stop and disable the services. Then uninstall the incus package.

If you want to remove all data:

# rm -r /var/lib/incus

If you used any of the example networking configuration, you should remove those as well.