「LXD」の版間の差分
(→参照: リンクを更新) |
(訳を修正) |
||
(他の1人の利用者による、間の1版が非表示) | |||
48行目: | 48行目: | ||
== 使用方法 == |
== 使用方法 == |
||
+ | LXD は 2 つの部分で構成されます: |
||
− | LXD consists of two parts: |
||
− | * |
+ | * デーモン (''lxd'' バイナリ) |
− | * |
+ | * クライアント (''lxc'' バイナリ) |
− | {{Note | |
+ | {{Note |少しややこしいですが、lxc は LXC ではありません。違いについては、[https://discuss.linuxcontainers.org/t/comparing-lxd-vs-lxc/24 LXD と LXC の比較に関するフォーラムの投稿]を参照してください。}} |
+ | クライアントは、1 つまたは複数のデーモンを制御するために使用されます。 |
||
− | The client is used to control one or multiple daemon(s). |
||
+ | クライアントを使用して、リモート LXD サーバーを制御することもできます。 |
||
− | The client can also be used to control remote LXD servers. |
||
− | === |
+ | === コマンドの概要 === |
+ | |||
− | You can get an overview of all available commands by typing: |
||
+ | 次のように入力すると、使用可能なすべてのコマンドの概要を確認できます: |
||
$ lxc |
$ lxc |
||
− | === |
+ | === コンテナを作成する === |
+ | |||
− | You can create a container with {{ic| lxc launch}}, for example: |
||
+ | 例えば {{ic| lxc launch}} でコンテナを作成できます: |
||
$ lxc launch ubuntu:20.04 |
$ lxc launch ubuntu:20.04 |
||
+ | コンテナは、イメージサーバーまたはリモート LXD サーバーからダウンロードされたイメージに基づいています。<br> |
||
− | Container are based on images, that are downloaded from image servers or remote LXD servers. <br> |
||
+ | すでに追加されているサーバーのリストは、次のコマンドで確認できます: |
||
− | You can see the list of already added servers with: |
||
$ lxc remote list |
$ lxc remote list |
||
+ | 例えば {{ic| lxc image list}} でサーバ上の全ての画像を一覧表示できます: |
||
− | You can list all images on a server with {{ic| lxc image list}}, for example: |
||
$ lxc image list images: |
$ lxc image list images: |
||
− | + | これにより、複数のデフォルトサーバー ([https://images.linuxcontainers.org image.linuxcontainers.org]) のうち1つにある全てのイメージが表示されます。 |
|
+ | ディストリビューション名などの単語を追加してイメージを検索することもできます: |
||
− | You can also search for images by adding terms like the distribution name: |
||
$ lxc image list images:debian |
$ lxc image list images:debian |
||
+ | 次のコマンドを使用して、特定のサーバーからイメージを含むコンテナを起動します: |
||
− | Launch a container with an image from a specific server with: |
||
$ lxc launch servername:imagename |
$ lxc launch servername:imagename |
||
+ | 例えば: |
||
− | For example: |
||
$ lxc launch images:centos/8/amd64 centos |
$ lxc launch images:centos/8/amd64 centos |
||
+ | Amd64 Arch コンテナを作成するには: |
||
− | To create an amd64 Arch container: |
||
$ lxc launch images:archlinux/current/amd64 arch |
$ lxc launch images:archlinux/current/amd64 arch |
||
− | === |
+ | === 仮想マシンを作成する === |
+ | |||
− | Just add the flag {{ic|--vm}} to {{ic|lxc launch}}: |
||
+ | フラグ {{ic|--vm}} を {{ic|lxc launch}} に追加するだけです: |
||
$ lxc launch ubuntu:20.04 --vm |
$ lxc launch ubuntu:20.04 --vm |
||
{{Note| |
{{Note| |
||
− | * |
+ | * 今のところ、仮想マシンはコンテナよりも少ない機能しかサポートしていません (例えば、[https://linuxcontainers.org/lxd/advanced-guide/#difference-between-containers-and-virtual-machines コンテナと仮想マシンの違い] を参照) |
− | * |
+ | * 公式のイメージのうち、特に設定せずに lxd-agent ({{ic|lxc exec}} などの通常の lxc コマンドを使うために必要です) を使えるのは {{ic|cloud}} バリアントのみです。{{ic|lxc image list images: cloud}} や {{ic|lxc image list images: distribution-name cloud}} でクラウドイメージを検索できます。他のイメージを使う場合や、問題に遭遇した場合は、[[#仮想マシン内の lxd-agent]] 章を見てください。 |
}} |
}} |
||
+ | === コンテナまたは VM の使用と管理 === |
||
− | === Use and manage a container or VM === |
||
− | + | [https://linuxcontainers.org/lxd/getting-started-cli/#instance-management LXD の公式スタートガイドのインスタンス管理]を参照してください。 |
|
− | === |
+ | === コンテナ/VM 構成 (オプション) === |
+ | インスタンス (コンテナーと VM) にさまざまなオプションを追加できます。<br> |
||
− | You can add various options to instances (containers and VMs). <br> |
||
− | + | 詳細については、[https://linuxcontainers.org/lxd/advanced-guide/#configuration-of-instances LXD の公式アドバンストガイドのインスタンスの設定]を参照してください。 |
|
+ | == ヒントとテクニック == |
||
− | == Tips and tricks == |
||
=== ホスト上でコンテナーに名前でアクセスする === |
=== ホスト上でコンテナーに名前でアクセスする === |
||
122行目: | 125行目: | ||
# systemd-resolve --interface lxdbr0 --set-domain '~lxd' --set-dns $(lxc network get lxdbr0 ipv4.address | cut -d / -f 1) |
# systemd-resolve --interface lxdbr0 --set-domain '~lxd' --set-dns $(lxc network get lxdbr0 ipv4.address | cut -d / -f 1) |
||
− | これで、名前でコンテナーにアクセスできるようになります |
+ | これで、名前でコンテナーにアクセスできるようになります: |
$ ping ''containername''.lxd |
$ ping ''containername''.lxd |
||
334行目: | 337行目: | ||
=== 仮想マシン内の lxd-agent === |
=== 仮想マシン内の lxd-agent === |
||
− | 一部の仮想マシンイメージ内では、{{ic|lxd-agent}} はデフォルトでは有効になっていません。 |
+ | 一部の仮想マシンイメージ内では、{{ic|lxd-agent}} はデフォルトでは有効になっていません。この場合、たとえば {{ic|9p}} ネットワーク共有をマウントするなどして、手動で有効にする必要があります。これには、有効なユーザーによるコンソールアクセスが必要です。 |
− | この場合、たとえば {{ic|9p}} ネットワーク共有をマウントするなどして、手動で有効にする必要があります。これには、有効なユーザーによるコンソールアクセスが必要です。 |
||
− | 1.{{ic|lxc console}}でログインし |
+ | 1.{{ic|lxc console}}でログインしてください ({{ic|virtualmachine-name}} の部分は適宜置き換えてください): |
− | {{ic|virtualmachine-name}} を適宜置き換えてください。 |
||
$ lxc console virtualmachine-name |
$ lxc console virtualmachine-name |
||
root としてログインします: |
root としてログインします: |
||
+ | |||
− | {{Note | 一部のシステムでは、root としてログインできるようにするには、最初に root パスワードを設定する必要があります。 <br> これには、[https://linuxcontainers.org/lxd/advanced-guide/#cloud-init cloud-init] を使用できます。}} |
||
+ | {{Note | 一部のシステムでは、root としてログインできるようにするには、最初に root パスワードを設定する必要があります。これには、[https://linuxcontainers.org/lxd/advanced-guide/#cloud-init cloud-init] を使用できます。}} |
||
$ su root |
$ su root |
||
− | ネットワーク共有をマウントします |
+ | ネットワーク共有をマウントします: |
$ mount -t 9p config /mnt/ |
$ mount -t 9p config /mnt/ |
||
363行目: | 365行目: | ||
=== カーネルコンフィグの確認 === |
=== カーネルコンフィグの確認 === |
||
+ | |||
デフォルトで Arch Linux のカーネルは Linux Containers とフロントエンドの LXD が動くようにコンパイルされています。カスタムカーネルを使っている場合やカーネルオプションを変更している場合、LXD が動かない場合があります。コンテナを実行できるようにカーネルが設定されているか確認してください: |
デフォルトで Arch Linux のカーネルは Linux Containers とフロントエンドの LXD が動くようにコンパイルされています。カスタムカーネルを使っている場合やカーネルオプションを変更している場合、LXD が動かない場合があります。コンテナを実行できるようにカーネルが設定されているか確認してください: |
||
− | $ lxc-checkconfig |
||
+ | $ lxc-checkconfig |
||
− | === コンテナ内から見た場合、リソース制限は適用されません === |
||
+ | === コンテナ内から見た時にリソース制限が適用されない === |
||
− | {{Pkg|lxcfs}} をインストールして {{ic|lxcfs.service}} を [[起動]] します。 |
||
− | lxd を再起動する必要があります。{{ic|lxcfs.service}} を |
+ | {{Pkg|lxcfs}} をインストールして {{ic|lxcfs.service}} を[[起動]]します。この時、lxd を再起動する必要があります。そして、{{ic|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}] |
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}] |
||
386行目: | 388行目: | ||
$ lxc profile set default security.secureboot=false |
$ lxc profile set default security.secureboot=false |
||
− | === systemd-networkd で |
+ | === systemd-networkd で IPv4 を使用できない === |
− | バージョン version 244.1 以降、systemd は {{ic|/sys}} がコンテナーによって書き込み可能かどうかを検出します。 |
+ | バージョン version 244.1 以降、systemd は {{ic|/sys}} がコンテナーによって書き込み可能かどうかを検出します。もし書き込み可能である場合、udev が自動的に起動され、特権のないコンテナ内の IPv4 の機能が破壊されてしまいます。[https://github.com/systemd/systemd-stable/commit/96d7083c5499b264ecebd6a30a92e0e8fda14cd5 commit bf331d8] および [https://discuss.linuxcontainers.org/t/no-ipv4-on-arch-linux-containers/6395 linuxcontainers におけるディスカッション]を参照してください。 |
− | 2020 年以降に作成されたコンテナには、この問題を回避するための {{ic|systemd.networkd.service}} オーバーライドがすでに存在するはずです。そうでない場合は作成してください: |
+ | 2020 年以降に作成されたコンテナには、この問題を回避するための {{ic|systemd.networkd.service}} に対するオーバーライドがすでに存在するはずです。そうでない場合は作成してください: |
{{hc|1=/etc/systemd/system/systemd-networkd.service.d/lxc.conf|2= |
{{hc|1=/etc/systemd/system/systemd-networkd.service.d/lxc.conf|2= |
||
397行目: | 399行目: | ||
}} |
}} |
||
− | また、コンテナのプロファイルで {{ic|1=raw.lxc: lxc.mount.auto = proc:rw sys:ro}} を設定 |
+ | また、コンテナのプロファイルで {{ic|1=raw.lxc: lxc.mount.auto = proc:rw sys:ro}} を設定することで、コンテナ全体から {{ic|/sys}} を読み取り専用にすることで、この問題を解決することもできますが、先のリンク先の議論にある通り、これは問題になるかもしれません。 |
− | === ufw でネットワークに接続 |
+ | === ufw でネットワークに接続できない === |
− | [[ufw]] を備えたシステムで LXD を実行すると、{{ic|lxc ls}} の出力 |
+ | [[ufw]] を備えたシステムで LXD を実行すると、{{ic|lxc ls}} の出力で IPv4 のフィールドに何も表示されず、送信リクエストはコンテナから転送されず、受信リクエストはコンテナに転送されません。[https://discuss.linuxcontainers.org/t/lxc-containers-ufw-firewall-on-the-lxd-host/11087/2 LXC の Discourse インスタンスのスレッド]にかかれてあるように、デフォルトでは ufw は LXD ブリッジからのトラフィックをブロックします。解決策は、ブリッジごとに 2 つの新しい ufw ルールを設定することです: |
# ufw route allow in on lxdbr0 |
# ufw route allow in on lxdbr0 |
||
# ufw allow in on lxdbr0 |
# ufw allow in on lxdbr0 |
||
− | この2つのコマンドの詳細については、[https://discuss.linuxcontainers.org/t/lxd-bridge-doesnt-work-with-ipv4-and-ufw-with-nftables/10034/17 このスレッド] |
+ | この2つのコマンドの詳細については、[https://discuss.linuxcontainers.org/t/lxd-bridge-doesnt-work-with-ipv4-and-ufw-with-nftables/10034/17 このスレッド]をチェックして下さい。このスレッドでは、これらのコマンドとその制限について詳しく説明されています。 |
=== Docker をインストールしてもネットワークに接続できない === |
=== Docker をインストールしてもネットワークに接続できない === |
||
415行目: | 417行目: | ||
# iptables -I DOCKER-USER -o lxdbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT |
# iptables -I DOCKER-USER -o lxdbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT |
||
− | 1行目の {{ic|''interface''}} |
+ | 1行目の {{ic|''interface''}} の部分は、外部ネットワークインターフェース (ホストをLAN/インターネットに接続するものです、例えば {{ic|enp6so}}、{{ic|wlp5s0}}、...) に置き換えてください。必要に応じて {{ic|lxdbr0}} も置き換えてください。 |
− | 詳細については、[https://documentation.ubuntu.com/lxd/en/latest/howto/network_bridge_firewalld/#prevent-connectivity-issues-with-lxd-and-docker LXD ドキュメントのこのメモ] |
+ | 詳細については、[https://documentation.ubuntu.com/lxd/en/latest/howto/network_bridge_firewalld/#prevent-connectivity-issues-with-lxd-and-docker LXD ドキュメントのこのメモ]を参照してください。 |
== アンインストール == |
== アンインストール == |
||
− | {{ic|lxd.service}} と {{ic|lxd.socket}} を |
+ | {{ic|lxd.service}} と {{ic|lxd.socket}} を[[停止]]して無効にします。次に、{{Pkg|lxd}} パッケージを[[アンインストール]]します。 |
サービスを無効にせずにパッケージをアンインストールした場合、{{ic|/etc/systemd/system/multi-user.wants/lxd.service}} に壊れたシンボリックリンクが残る可能性があります。 |
サービスを無効にせずにパッケージをアンインストールした場合、{{ic|/etc/systemd/system/multi-user.wants/lxd.service}} に壊れたシンボリックリンクが残る可能性があります。 |
2023年11月6日 (月) 11:44時点における版
関連記事
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 バイナリ)
クライアントは、1 つまたは複数のデーモンを制御するために使用されます。
クライアントを使用して、リモート LXD サーバーを制御することもできます。
コマンドの概要
次のように入力すると、使用可能なすべてのコマンドの概要を確認できます:
$ lxc
コンテナを作成する
例えば lxc launch
でコンテナを作成できます:
$ lxc launch ubuntu:20.04
コンテナは、イメージサーバーまたはリモート LXD サーバーからダウンロードされたイメージに基づいています。
すでに追加されているサーバーのリストは、次のコマンドで確認できます:
$ lxc remote list
例えば lxc image list
でサーバ上の全ての画像を一覧表示できます:
$ lxc image list images:
これにより、複数のデフォルトサーバー (image.linuxcontainers.org) のうち1つにある全てのイメージが表示されます。
ディストリビューション名などの単語を追加してイメージを検索することもできます:
$ 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
コンテナまたは VM の使用と管理
LXD の公式スタートガイドのインスタンス管理を参照してください。
コンテナ/VM 構成 (オプション)
インスタンス (コンテナーと VM) にさまざまなオプションを追加できます。
詳細については、LXD の公式アドバンストガイドのインスタンスの設定を参照してください。
ヒントとテクニック
ホスト上でコンテナーに名前でアクセスする
これは、デフォルトのブリッジである 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 のホストのソケットへのアクセスを許可します。
コンテナのプロファイルに以下のデバイスを追加
LXD のデバイスに関するドキュメントも参照してください。
GPU 用の一般的なデバイス:
mygpu: type: gpu
Wayland ソケット用のデバイス:
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)ソケット用のデバイス:
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
コンテナ内でソケットを適切な場所にリンク
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
コンテナ内のユーザー設定に環境変数を追加
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 を試してみてください。
特権コンテナ
特権コンテナを設定したい場合、設定キーとして 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 としてログインします:
$ 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 および linuxcontainers におけるディスカッションを参照してください。
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
ネットワーク構成例のいずれかを使用した場合は、それらも削除する必要があります。