LXD

関連記事

• Linux Containers

LXD はコンテナ(LXC経由)および仮想マシン(QEMU経由)のマネージャー/ハイパーバイザーです。

必要なソフトウェア

lxd パッケージをインストールします。 あるいは、インスタンスを自動起動する場合など、lxd.service を直接、有効にすることもできます。

セットアップ

一般ユーザー用のコンテナ設定

一般ユーザー用のコンテナ（unprivileged containers）を使用することが推奨されます（違いについては Linux_Containers#Privileged_containers_or_unprivileged_containers を参照してください）。

このために、/etc/subuid と /etc/subgid の両方を変更します（これらのファイルが存在しない場合は、作成してください）。コンテナで使用する uid / gid のマッピングを各ユーザーに設定する必要があります。以下の例は単に root ユーザー（および systemd システムユニット）のためのものです：

usermod コマンドを以下のように使用することもできます：

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

または、上記のファイルを直接以下のように変更することもできます：

/etc/subuid

root:1000000:1000000000

/etc/subgid

root:1000000:1000000000

これで、すべてのコンテナはデフォルトで unprivileged として起動されます。

代替方法については、特権コンテナの設定方法 を参照してください。

LXD の設定

LXD を使うにはストレージプールと (インターネットを使いたい場合) ネットワークを設定する必要があります。以下のコマンドを root で実行してください:

# lxd init

非特権ユーザーとして LXD にアクセス

デフォルトでは LXD デーモンは lxd グループのユーザーからのアクセスを許可するので、ユーザーをグループに追加してください:

# usermod -a -G lxd <user>

使用方法

LXD は 2 つの部分で構成されます:

• デーモン (lxd バイナリ)
• クライアント (lxc バイナリ)

ノート: lxc は LXC ではありません。名前は少し混乱しています。違いについては、LXD と LXC の比較に関するフォーラムの投稿 を参照してください。

クライアントは、1 つまたは複数のデーモンを制御するために使用されます。

クライアントを使用して、リモート LXD サーバーを制御することもできます。

コマンドの概要

次のように入力すると、使用可能なすべてのコマンドの概要を確認できます:

$ lxc

コンテナを作成する

例えば lxc launch でコンテナを作成できます:

$ lxc launch ubuntu:20.04

コンテナは、イメージサーバーまたはリモート LXD サーバーからダウンロードされたイメージに基づいています。
すでに追加されているサーバーのリストは、次のコマンドで確認できます:

$ lxc remote list

例えば lxc image list でサーバ上の全ての画像を一覧表示できます:

$ lxc image list images:

これにより、デフォルトサーバー image.linuxcontainers.org のいずれかにあるすべてのイメージが表示されます。

ディストリビューション名などの用語を追加して画像を検索することもできます:

$ lxc image list images:debian

次のコマンドを使用して、特定のサーバーからイメージを含むコンテナを起動します:

$ lxc launch servername:imagename

例えば:

$ lxc launch images:centos/8/amd64 centos

amd64 Arch コンテナを作成するには:

$ lxc launch images:archlinux/current/amd64 arch

仮想マシンを作成する

フラグ --vm を lxc launch に追加するだけです:

$ lxc launch ubuntu:20.04 --vm

ノート:

• 今のところ、仮想マシンはコンテナよりも少ない機能しかサポートしていません (例えば、コンテナと仮想マシンの違い を参照)
• 公式イメージの cloud バリエーションのみが、すぐに使えるようにしています (lxc exec のような通常の lxc コマンドに必要です。)
  クラウドの画像を検索するには、lxc image list images: cloud もしくは、lxc image list images: distribution-name cloud.
  他の画像を使用する場合、または問題が発生した場合は、以下を参照してください。仮想マシン内の lxd-agent

コンテナまたは VM の使用と管理

LXD の公式スタートガイドのインスタンス管理 を参照してください。

コンテナ/VM 構成 (オプション)

インスタンス (コンテナーと VM) にさまざまなオプションを追加できます。
詳細については、LXD の公式アドバンストガイドのインスタンスの設定 を参照してください。

Tips and tricks

ホスト上でコンテナーに名前でアクセスする

これは、デフォルトのブリッジである lxdbr0 を使用していて、systemd-resolved を使用している場合を前提としています。

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

これで、名前でコンテナーにアクセスできるようになります：

$ ping containername.lxd

その他の解決策

一定時間が経過すると、systemd-resolve の解決策は機能しなくなるようです。

別の解決策としては、以下の lxd.network を用いて systemd-networkd を使用する方法があります（x と y をあなたのブリッジ IP に合わせて置き換えてください）：

/etc/systemd/network/lxd.network

[Match]
Name=lxdbr0

[Network]
DNS=10.x.y.1
Domains=~lxd
IgnoreCarrierLoss=yes

[Address]
Address=10.x.y.1/24
Gateway=10.x.y.1

Wayland と Xorg アプリケーションの使用

ノート: セキュリティの影響を常に考慮してください。記載されている方法のいくつかは、コンテナとホストとの分離を弱める可能性があります。

コンテナ内で GUI アプリケーションを使用するための複数の方法があります。公式 LXD フォーラム で概要が見れます。

以下の方法は、コンテナに Wayland（+Xwayland）または Xorg のホストのソケットへのアクセスを許可します。

ノート: Xorg を使用することで、コンテナとホストとの分離が弱まる可能性があります。なぜなら、Xorg はアプリケーションが他のアプリケーションのウィンドウにアクセスできるようにするからです。代わりに Wayland を使用してください（ただし、Xorg のデメリットも Xwayland に適用されることに注意してください）。

コンテナのプロファイルに以下のデバイスを追加

LXD のデバイスに関するドキュメントも参照してください。

GPU 用の一般的なデバイス：

mygpu:
   type: gpu

ノート: 「listen」の下のパスが異なる理由は、/run および /tmp ディレクトリが上書きされる可能性があるためです。https://github.com/lxc/lxd/issues/4540^{[リンク切れ 2023-09-16]} を参照してください。

Wayland ソケット用のデバイス：

ノート:

• ディスプレイ（wayland-0）を適宜調整してください。
• コンテナ内の /mnt および /tmp ディレクトリがまだ存在しない場合は追加してください。

Waylandsocket:
    bind: container
    connect: unix:/run/user/1000/wayland-0
    listen: unix:/mnt/wayland1/wayland-0
    uid: "1000"
    gid: "1000"
    security.gid: "1000"
    security.uid: "1000"
    mode: "0777"
    type: proxy

Xorg（または Xwayland）ソケット用のデバイス：

ノート: ディスプレイ番号を適宜調整してください（例：X0 の代わりに X1 など）。

Xsocket:
    bind: container
    connect: unix:/tmp/.X11-unix/X0
    listen: unix:/mnt/xorg1/X0
    uid: "1000"
    gid: "1000"
    security.gid: "1000"
    security.uid: "1000"
    mode: "0777"
    type: proxy

コンテナ内でソケットを適切な場所にリンク

ノート: これらのスクリプトは、コンテナの各起動後に実行する必要があります。たとえば、systemd を使用してこれを自動化できます。

Wayland ソケットをリンクするシェルスクリプト：

#!/bin/sh
mkdir /run/user/1000
ln -s /mnt/wayland1/wayland-0 /run/user/1000/wayland-0

Xorg（または Xwayland）ソケットをリンク：

#!/bin/sh
ln -s /mnt/xorg1/X0 /tmp/.X11-unix/X0

コンテナ内のユーザー設定に環境変数を追加

ノート: ディスプレイ番号やファイル名（.profile）を適宜調整してください。

Wayland 用：

$ echo "export XDG_RUNTIME_DIR=/run/user/1000" >> ~/.profile
$ echo "export WAYLAND_DISPLAY=wayland-0" >> ~/.profile
$ echo "export QT_QPA_PLATFORM=wayland" >> ~/.profile

Xorg（または Xwayland）用：

$ echo "export DISPLAY=:0" >> ~/.profile

~/.profile をリロード：

$ source ~/.profile

コンテナ内で必要なソフトウェアをインストール

必要なソフトウェアを追加する必要があります。今のところ、例として GUI アプリケーションをインストールできます。これによって、必要なパッケージもすべてインストールされるでしょう。

GUI アプリケーションを起動

これで、コンテナ内で GUI アプリケーションを起動することができます（例えば、ターミナル経由で）そして、それらをホストのディスプレイ上にウィンドウとして表示させることができます。

例として glxgears を試してみてください。

特権コンテナ

ノート:

• 特権コンテナはホストから隔離されていません！
• コンテナ内の root ユーザーはホストの root ユーザーです。
• 可能な限り、特権でないコンテナを使用してください。

特権コンテナを設定したい場合、設定キーとして security.privileged=true を提供する必要があります。

コンテナ作成中に：

$ lxc launch ubuntu:20.04 ubuntu -c security.privileged=true

既存のコンテナで設定を編集する場合：

$ lxc config edit ubuntu

name: ubuntu
profiles:
- default
config:
  ...
  security.privileged: "true"
  ...

ディスクデバイスを追加

読み取り専用

ホストからコンテナにディスクデバイスを共有したいだけなら、コンテナに disk デバイスを追加するだけです。仮想の disk デバイスは名前（LXC 設定ファイル内でのみ使用）、ホストのファイルシステム上で指すべきディスクへのパス、そしてコンテナのファイルシステム上でのマウントポイントが必要です。

$ lxc config device add containername virtualdiskname disk source=/path/to/host/disk/ path=/path/to/mountpoint/on/container

読み書き可能（特権でないコンテナ）

読み書きアクセスの推奨される方法は、LXD に含まれる "shift" メソッドを使用することです。

shift は Linux カーネルの機能に基づいており、二つの異なるバージョンで利用可能です：

• 最新のバージョンは "idmapped mounts" と呼ばれ、すべての upstream カーネル >5.12 にデフォルトで含まれています。したがって、通常の Arch Linux カーネル（linux）にも含まれています。
• 古いバージョンは "shiftfs" と呼ばれ、ほとんどのカーネルに手動で追加する必要があります。これはレガシーバージョンとして、古いカーネルをサポートするためにあります。この GitHub リポジトリは Ubuntu カーネルからの shiftfs カーネルモジュールを使用しています：https://github.com/toby63/shiftfs-dkms

shift は、通常の Arch Linux カーネル（linux）と lxd パッケージによって、デフォルトで利用可能であり、有効になっているはずです。

1. システムで shift が利用可能かどうかを確認するには, lxc info を実行します。

出力の最初の部分で表示されるのは：

 kernel_features:
    idmapped_mounts: "true"
    shiftfs: "false"

idmapped_mounts または shiftfs のいずれかが true の場合、そのカーネルはすでにそれを含んでおり、shift を使用できます。 true でない場合、カーネルバージョンを確認し、上記で述べた "shiftfs" レガシーバージョンを試すことができます。

出力の第二部では、次のいずれかが表示されます：

  lxc_features:
    idmapped_mounts_v2: "true"

または:

  lxc_features:
    shiftfs: "true"

idmapped_mounts または shiftfs のいずれかが true の場合、LXD は既にそれを有効にしています。 有効にされていない場合、最初にそれを有効にする必要があります。

2. 使い方

ディスクデバイスのオプションで "shift" 設定キーを "true" に設定するだけです。 参照：LXD のディスクデバイスに関する文書

また、LXD フォーラムのチュートリアル も参照してください。

Bash 補完が動作しない

このワークアラウンドで問題が解決するかもしれません：

# ln -s /usr/share/bash-completion/completions/lxd /usr/share/bash-completion/completions/lxc

トラブルシューティング

仮想マシン内の lxd-agent

一部の仮想マシンイメージ内では、lxd-agent はデフォルトでは有効になっていません。
この場合、たとえば 9p ネットワーク共有をマウントするなどして、手動で有効にする必要があります。これには、有効なユーザーによるコンソールアクセスが必要です。

1.lxc consoleでログインします:
virtualmachine-name を適宜置き換えてください。

$ lxc console virtualmachine-name

root としてログインします:

ノート: 一部のシステムでは、root としてログインできるようにするには、最初に root パスワードを設定する必要があります。
これには、cloud-init を使用できます。

$ su root

ネットワーク共有をマウントします。

$ mount -t 9p config /mnt/

フォルダーに移動し、インストールスクリプトを実行します (これにより、VM 内の lxd-agent が有効になります):

$ cd /mnt/
$ ./install.sh 

インストールが成功したら、次のようにして再起動します:

$ reboot

その後、lxd-agent が利用可能になり、lxc exec が動作するはずです。

カーネルコンフィグの確認

デフォルトで Arch Linux のカーネルは Linux Containers とフロントエンドの LXD が動くようにコンパイルされています。カスタムカーネルを使っている場合やカーネルオプションを変更している場合、LXD が動かない場合があります。コンテナを実行できるようにカーネルが設定されているか確認してください:

$ lxc-checkconfig

コンテナ内から見た場合、リソース制限は適用されません

lxcfs をインストールして lxcfs.service を 起動 します。

lxd を再起動する必要があります。lxcfs.service を 有効化 して起動時にサービスが開始されるようにします。

仮想マシンの起動に失敗する

エラーが表示された場合:

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}]

Arch Linux はセキュアブート署名付き ovmf ファームウェアを配布しないため、仮想マシンを起動するには、当面はセキュアブートを無効にする必要があります:

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

これは、次のようにしてデフォルトのプロファイルに追加することもできます:

$ lxc profile set default security.secureboot=false

systemd-networkd では IPv4 は使用できません

バージョン version 244.1 以降、systemd は /sys がコンテナーによって書き込み可能かどうかを検出します。存在する場合、udev が自動的に起動され、特権のないコンテナ内の IPv4 が中断されます。commit bf331d8 および の Linux コンテナに関するディスカッションを参照してください。

2020 年以降に作成されたコンテナには、この問題を回避するための systemd.networkd.service オーバーライドがすでに存在するはずです。そうでない場合は作成してください:

/etc/systemd/system/systemd-networkd.service.d/lxc.conf

[Service]
BindReadOnlyPaths=/sys

また、コンテナのプロファイルで raw.lxc: lxc.mount.auto = proc:rw sys:ro を設定して、/sys が確実に機能するようにすることで、この問題を回避することもできます。コンテナ全体は読み取り専用ですが、上記のリンク先の説明にあるように、これには問題がある可能性があります。

ufw でネットワークに接続しない

ufw を備えたシステムで LXD を実行すると、lxc ls の出力には空の IPv4 フィールドが含まれ、送信リクエストはコンテナから転送されず、受信リクエストはコンテナに転送されません。LXC の Discourse インスタンスのスレッド に見られるように、デフォルトでは ufw は LXD ブリッジからのトラフィックをブロックします。解決策は、ブリッジごとに 2 つの新しい ufw ルールを設定することです。

# ufw route allow in on lxdbr0
# ufw allow in on lxdbr0

この2つのコマンドの詳細については、このスレッド をチェックして下さい。このスレッドでは、これらのコマンドとその制限について詳しく説明しています。

Docker をインストールしてもネットワークに接続できない

ホストに Docker がインストールされていて、lxc コンテナ内から LAN やインターネットにアクセスできない。

# iptables -I DOCKER-USER -i lxdbr0 -o interface -j ACCEPT
# iptables -I DOCKER-USER -o lxdbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

1行目の interface を外部ネットワークインターフェース (ホストをLAN/インターネットに接続するもの、例えばenp6so、wlp5s0、...) に置き換えます。必要に応じて lxdbr0 も置き換えてください。

詳細については、LXD ドキュメントのこのメモ を参照してください。

アンインストール

lxd.service と lxd.socket を 停止 して無効にします。次に、lxd パッケージを アンインストール します。

サービスを無効にせずにパッケージをアンインストールした場合、/etc/systemd/system/multi-user.wants/lxd.service に壊れたシンボリックリンクが残る可能性があります。

すべてのデータを削除したい場合:

# rm -r /var/lib/lxd

ネットワーク構成例のいずれかを使用した場合は、それらも削除する必要があります。

参照

• LXD の公式ホームページ
• 公式ドキュメント
• スタートガイド
• アドバンスガイド
• 公式フォーラム
• LXD の GitHub ページ
• LXD のチュートリアル
• チュートリアル in LXD フォーラム
• リリースノート in LXD フォーラム
• LXD フォーラムのリリースノート