「LXD」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(→‎ヒントとテクニック: 記事を最新に更新)
(訳を修正)
 
(2人の利用者による、間の16版が非表示)
48行目: 48行目:
 
== 使用方法 ==
  
== 使用方法 ==
   
  +
LXD は 2 つの部分で構成されます:
−
LXD consists of two parts:
  
−
* the daemon (the ''lxd'' binary)
 +
* デーモン (''lxd'' バイナリ)
−
* the client (the ''lxc'' binary)
 +
* クライアント (''lxc'' バイナリ)
   
−
{{Note | lxc is not LXC; the naming is a bit confusing, you can read the [https://discuss.linuxcontainers.org/t/comparing-lxd-vs-lxc/24 forum post on comparing LXD vs LXC] regarding the difference.}}
 +
{{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.
  
   
−
=== Overview of commands ===
 +
=== コマンドの概要 ===
  +
−
You can get an overview of all available commands by typing:
  
  +
次のように入力すると、使用可能なすべてのコマンドの概要を確認できます:
 
 
 
$ lxc
  
$ lxc
   
−
=== Create a container ===
 +
=== コンテナを作成する ===
  +
−
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:
   
−
This will show you all images on one of the default servers: [https://images.linuxcontainers.org images.linuxcontainers.org]
 +
これにより、複数のデフォルトサーバー ([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
   
−
=== Create a virtual machine ===
 +
=== 仮想マシンを作成する ===
  +
−
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|
−
* For now virtual machines support less features than containers (see [https://linuxcontainers.org/lxd/advanced-guide/#difference-between-containers-and-virtual-machines Difference between containers and virtual machines] for example).
+
* 今のところ、仮想マシンはコンテナよりも少ない機能しかサポートしていません (例えば、[https://linuxcontainers.org/lxd/advanced-guide/#difference-between-containers-and-virtual-machines コンテナと仮想マシンの違い] を参照)
−
* Only {{ic|cloud}} variants of the official images enable the lxd-agent out-of-the-box (which is needed for the usual lxc commands like {{ic|lxc exec}}). <br> You can search for cloud images with {{ic|lxc image list images: cloud}} or {{ic|lxc image list images: distribution-name cloud}}. <br> If you use other images or encounter problems take a look at [[#lxd-agent_inside_a_virtual_machine]].
 +
* 公式のイメージのうち、特に設定せずに 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 ===
  
   
−
See [https://linuxcontainers.org/lxd/getting-started-cli/#instance-management Instance managament in the official Getting Started Guide of LXD].
 +
[https://linuxcontainers.org/lxd/getting-started-cli/#instance-management LXD の公式スタートガイドのインスタンス管理]を参照してください。
   
−
=== Container/VM configuration (optional) ===
 +
=== コンテナ/VM 構成 (オプション) ===
   
  +
インスタンス (コンテナーと VM) にさまざまなオプションを追加できます。<br>
−
You can add various options to instances (containers and VMs). <br>
  
−
See [https://linuxcontainers.org/lxd/advanced-guide/#configuration-of-instances Configuration of instances in the official Advanced Guide of LXD] for details.
 +
詳細については、[https://linuxcontainers.org/lxd/advanced-guide/#configuration-of-instances LXD の公式アドバンストガイドのインスタンスの設定]を参照してください。
   
 
== ヒントとテクニック ==
  
== ヒントとテクニック ==
   
  +
=== ホスト上でコンテナーに名前でアクセスする ===
−
=== Access the containers by name on the host ===
  
   
  +
これは、デフォルトのブリッジである {{ic|lxdbr0}} を使用していて、[[systemd-resolved]] を使用している場合を前提としています。
−
This assumes that you are using the default bridge that it is named {{ic|lxdbr0}} and that you are using [[systemd-resolved]].
  
   
 
# 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)
   
  +
これで、名前でコンテナーにアクセスできるようになります:
−
You can now access the containers by name:
  
   
 
$ ping ''containername''.lxd
  
$ ping ''containername''.lxd
   
−
==== Other solution ====
 +
==== その他の解決策 ====
   
−
{{Accuracy|When does ''systemd-resolve'' stop working? Is there a bug report or some other reference?}}
 +
{{Accuracy|''systemd-resolve'' がいつ動かなくなるのか？バグレポートや他の参考資料はありますか？}}
   
  +
一定時間が経過すると、''systemd-resolve'' の解決策は機能しなくなるようです。
−
It seems that the ''systemd-resolve'' solution stops working after some time.
  
   
  +
別の解決策としては、以下の {{ic|lxd.network}} を用いて [[systemd-networkd]] を使用する方法があります（{{ic|''x''}} と {{ic|''y''}} をあなたのブリッジ IP に合わせて置き換えてください）：
−
Another solution is to use [[systemd-networkd]] with the following {{ic|lxd.network}} (replace {{ic|''x''}} and {{ic|''y''}} to match your bridge IP):
  
   
 
{{hc|/etc/systemd/network/lxd.network|2=
  
{{hc|/etc/systemd/network/lxd.network|2=
148行目: 151行目:
 
}}
  
}}
   
−
=== Use Wayland and Xorg applications ===
 +
=== Wayland と Xorg アプリケーションの使用 ===
   
  +
{{Note|セキュリティの影響を常に考慮してください。記載されている方法のいくつかは、コンテナとホストとの分離を弱める可能性があります。}}
−
{{Note|Always consider security implications, as some of the described methods may weaken the seperation between container and host.}}
  
   
−
There are multiple methods to use GUI applications inside containers, you can find an overview in the [https://discuss.linuxcontainers.org/t/overview-gui-inside-containers/8767 official LXD forum].
 +
コンテナ内で GUI アプリケーションを使用するための複数の方法があります。[https://discuss.linuxcontainers.org/t/overview-gui-inside-containers/8767 公式 LXD フォーラム] で概要が見れます。
   
  +
以下の方法は、コンテナに Wayland（+Xwayland）または Xorg のホストのソケットへのアクセスを許可します。
−
The following method grants containers access to the host's sockets of Wayland (+Xwayland) or Xorg.
  
   
  +
{{Note|Xorg を使用することで、コンテナとホストとの分離が弱まる可能性があります。なぜなら、Xorg はアプリケーションが他のアプリケーションのウィンドウにアクセスできるようにするからです。代わりに Wayland を使用してください（ただし、Xorg のデメリットも Xwayland に適用されることに注意してください）。}}
−
{{Note|Using Xorg might weaken the seperation between container and host, because Xorg allows applications to access other applications windows. So container applications might have access to host applications windows. Use Wayland instead (but be aware that Xorg downsides also apply to Xwayland).}}
  
   
  +
==== コンテナのプロファイルに以下のデバイスを追加 ====
−
==== Add the following devices to a containers profile ====
  
   
−
See also [https://linuxcontainers.org/lxd/docs/master/instances#device-types LXD documentation regarding devices].
 +
[https://linuxcontainers.org/lxd/docs/master/instances#device-types LXD のデバイスに関するドキュメント]も参照してください。
   
  +
GPU 用の一般的なデバイス：
−
General device for the GPU:
  
   
 
mygpu:
  
mygpu:
 
type: gpu
  
type: gpu
   
−
{{Note|The path under "listen" is different, because {{ic|/run}} and {{ic|/tmp}} directories might be overridden, see https://github.com/lxc/lxd/issues/4540{{Dead link|2023|09|16|status=404}}.}}
 +
{{Note|「listen」の下のパスが異なる理由は、{{ic|/run}} および {{ic|/tmp}} ディレクトリが上書きされる可能性があるためです。https://github.com/lxc/lxd/issues/4540{{Dead link|2023|09|16|status=404}} を参照してください。}}
   
  +
Wayland ソケット用のデバイス：
−
Device for the Wayland socket:
  
   
 
{{Note|
  
{{Note|
  +
* ディスプレイ（wayland-0）を適宜調整してください。
−
* Adjust the Display (wayland-0) accordingly.
  
−
* Add the directories in {{ic|/mnt}} and {{ic|/tmp}} inside the container, if they do not already exist.
 +
* コンテナ内の {{ic|/mnt}} および {{ic|/tmp}} ディレクトリがまだ存在しない場合は追加してください。
 
}}
  
}}
   
187行目: 190行目:
 
type: proxy
  
type: proxy
   
  +
Xorg（または Xwayland）ソケット用のデバイス：
−
Device for the Xorg (or Xwayland) Socket:
  
   
  +
{{Note|ディスプレイ番号を適宜調整してください（例：X0 の代わりに X1 など）。}}
−
{{Note|Adjust the Display Number accordingly (for example X1 instead of X0).}}
  
   
 
Xsocket:
  
Xsocket:
202行目: 205行目:
 
type: proxy
  
type: proxy
   
  +
==== コンテナ内でソケットを適切な場所にリンク ====
−
==== Link the sockets to the right location inside the container ====
  
   
  +
{{Note|これらのスクリプトは、コンテナの各起動後に実行する必要があります。たとえば、systemd を使用してこれを自動化できます。}}
−
{{Note|These scripts need to be run after each start of the container; you can automate this with systemd for example.}}
  
   
  +
Wayland ソケットをリンクするシェルスクリプト：
−
Shell script to link the Wayland socket:
  
   
 
#!/bin/sh
  
#!/bin/sh
212行目: 215行目:
 
ln -s /mnt/wayland1/wayland-0 /run/user/1000/wayland-0
  
ln -s /mnt/wayland1/wayland-0 /run/user/1000/wayland-0
   
  +
Xorg（または Xwayland）ソケットをリンク：
−
Link the Xorg (or Xwayland) socket:
  
   
 
#!/bin/sh
  
#!/bin/sh
 
ln -s /mnt/xorg1/X0 /tmp/.X11-unix/X0
  
ln -s /mnt/xorg1/X0 /tmp/.X11-unix/X0
   
  +
==== コンテナ内のユーザー設定に環境変数を追加 ====
−
==== Add environment variables to the users config inside the container ====
  
   
  +
{{Note|ディスプレイ番号やファイル名（.profile）を適宜調整してください。}}
−
{{Note|Adjust the Display Numbers and/or the filename (.profile) accordingly.}}
  
   
−
For Wayland:
 +
Wayland 用：
   
 
$ echo "export XDG_RUNTIME_DIR=/run/user/1000" >> ~/.profile
  
$ echo "export XDG_RUNTIME_DIR=/run/user/1000" >> ~/.profile
227行目: 230行目:
 
$ echo "export QT_QPA_PLATFORM=wayland" >> ~/.profile
  
$ echo "export QT_QPA_PLATFORM=wayland" >> ~/.profile
   
  +
Xorg（または Xwayland）用：
−
For Xorg (or Xwayland):
  
   
 
$ echo "export DISPLAY=:0" >> ~/.profile
  
$ echo "export DISPLAY=:0" >> ~/.profile
   
−
Reload the {{ic|~/.profile}}:
 +
{{ic|~/.profile}} をリロード：
   
 
$ source ~/.profile
  
$ source ~/.profile
   
  +
==== コンテナ内で必要なソフトウェアをインストール ====
−
==== Install necessary software in the container ====
  
   
  +
必要なソフトウェアを追加する必要があります。今のところ、例として GUI アプリケーションをインストールできます。これによって、必要なパッケージもすべてインストールされるでしょう。
−
Necessary software needs to be added. For now, you can install an example GUI application; this will probably install all necessary packages as well.
  
   
−
==== Start GUI applications ====
 +
==== GUI アプリケーションを起動 ====
   
  +
これで、コンテナ内で GUI アプリケーションを起動することができます（例えば、ターミナル経由で）そして、それらをホストのディスプレイ上にウィンドウとして表示させることができます。
−
Now, you should be able to start GUI applications inside the container (via terminal for example) and make them appear as a window on your hosts display.
  
   
−
You can try out ''glxgears'' for example.
 +
例として ''glxgears'' を試してみてください。
   
−
=== Privileged containers ===
 +
=== 特権コンテナ ===
   
 
{{Note|
  
{{Note|
  +
* 特権コンテナはホストから隔離されていません！
−
* Privileged containers are not isolated from the host!
  
  +
* コンテナ内の root ユーザーはホストの root ユーザーです。
−
* The root user in the container is the root user on the host.
  
  +
* 可能な限り、特権でないコンテナを使用してください。
−
* Use unprivileged containers instead whenever possible.
  
 
}}
  
}}
   
−
If you want to set up a privileged container, you must provide the config key {{ic|1=security.privileged=true}}.
 +
特権コンテナを設定したい場合、設定キーとして {{ic|1=security.privileged=true}} を提供する必要があります。
   
  +
コンテナ作成中に：
−
Either during container creation:
  
   
 
$ lxc launch ubuntu:20.04 ubuntu -c security.privileged=true
  
$ lxc launch ubuntu:20.04 ubuntu -c security.privileged=true
   
  +
既存のコンテナで設定を編集する場合：
−
Or for an already existing container, you may edit the configuration:
  
   
 
{{hc|$ lxc config edit ubuntu|
  
{{hc|$ lxc config edit ubuntu|
271行目: 274行目:
 
}}
  
}}
   
  +
=== ディスクデバイスを追加 ===
−
=== Add a disk device ===
  
   
−
==== Read-Only ====
 +
==== 読み取り専用 ====
   
  +
ホストからコンテナにディスクデバイスを共有したいだけなら、コンテナに {{ic|disk}} デバイスを追加するだけです。仮想の {{ic|disk}} デバイスは名前（LXC 設定ファイル内でのみ使用）、ホストのファイルシステム上で指すべきディスクへのパス、そしてコンテナのファイルシステム上でのマウントポイントが必要です。
−
If you want to share a disk device from the host to a container, all you need to do is add a {{ic|disk}} device to your container. The virtual {{ic|disk}} device needs a name (only used internally in the LXC configuration file), a path on the host's filesystem pointing to the disk you want to mount, as well as a desired mountpoint on the container's filesystem.
  
   
 
$ lxc config device add ''containername'' ''virtualdiskname'' disk source=''/path/to/host/disk/'' path=''/path/to/mountpoint/on/container''
  
$ lxc config device add ''containername'' ''virtualdiskname'' disk source=''/path/to/host/disk/'' path=''/path/to/mountpoint/on/container''
   
  +
==== 読み書き可能（特権でないコンテナ） ====
−
==== Read-Write (unprivileged container) ====
  
   
  +
読み書きアクセスの推奨される方法は、LXD に含まれる "shift" メソッドを使用することです。
−
The preferred method for read/write access is to use the "shift" method included in LXD.
  
   
  +
shift は Linux カーネルの機能に基づいており、二つの異なるバージョンで利用可能です：
−
shift is based on Linux kernel functionality and available in two different versions:
  
   
−
* the most recent version is called "idmapped mounts" and is included in all upstream kernels >5.12 by default. So it is also included in the regular Arch Linux kernel ({{Pkg|linux}}).
 +
* 最新のバージョンは "idmapped mounts" と呼ばれ、すべての upstream カーネル >5.12 にデフォルトで含まれています。したがって、通常の Arch Linux カーネル（{{Pkg|linux}}）にも含まれています。
  +
* 古いバージョンは "shiftfs" と呼ばれ、ほとんどのカーネルに手動で追加する必要があります。これはレガシーバージョンとして、古いカーネルをサポートするためにあります。この GitHub リポジトリは Ubuntu カーネルからの shiftfs カーネルモジュールを使用しています：https://github.com/toby63/shiftfs-dkms
−
* the old version is called "shiftfs" and needs to be added manually to most kernels as a kernel module. It is available as a legacy version to support older kernels. You can take a look at this GitHub repo that uses the shiftfs kernel module from Ubuntu kernels: https://github.com/toby63/shiftfs-dkms
  
   
  +
shift は、通常の Arch Linux カーネル（{{Pkg|linux}}）と {{Pkg|lxd}} パッケージによって、デフォルトで利用可能であり、有効になっているはずです。
−
Shift should be available and activated by default on Arch with the regular Arch Linux kernel ({{Pkg|linux}}) and the {{Pkg|lxd}} package.
  
   
−
'''1. To check whether shift is available on your system''', run {{ic|lxc info}}
 +
'''1. システムで shift が利用可能かどうかを確認するには''', {{ic|lxc info}} を実行します。
   
  +
出力の最初の部分で表示されるのは：
−
The first part of the output shows you:
  
   
 
{{bc| kernel_features:
  
{{bc| kernel_features:
299行目: 302行目:
 
}}
  
}}
   
  +
idmapped_mounts または shiftfs のいずれかが true の場合、そのカーネルはすでにそれを含んでおり、shift を使用できます。
−
If either idmapped_mounts or shiftfs is true, then your kernel includes it already and you can use shift.
  
  +
true でない場合、カーネルバージョンを確認し、上記で述べた "shiftfs" レガシーバージョンを試すことができます。
−
If it is not true, you should check your kernel version and might try the "shiftfs" legacy version mentioned above.
  
   
  +
出力の第二部では、次のいずれかが表示されます：
−
The second part of the output shows you either:
  
   
 
{{bc| lxc_features:
  
{{bc| lxc_features:
308行目: 311行目:
 
}}
  
}}
   
  +
または:
−
or:
  
   
 
{{bc| lxc_features:
  
{{bc| lxc_features:
314行目: 317行目:
 
}}
  
}}
   
−
If either idmapped_mounts or shiftfs is true, then LXD has already enabled it.
 +
idmapped_mounts または shiftfs のいずれかが true の場合、LXD は既にそれを有効にしています。
  +
有効にされていない場合、最初にそれを有効にする必要があります。
−
If it is not enabled, you must enable it first.
  
   
−
'''2. Usage'''
 +
'''2. 使い方'''
   
  +
ディスクデバイスのオプションで "shift" 設定キーを "true" に設定するだけです。
−
Then you can simply set the "shift" config key to "true" in the disk device options.
  
−
See: [https://linuxcontainers.org/lxd/docs/master/reference/devices_disk/ LXD Documentation on disk devices]
 +
参照：[https://linuxcontainers.org/lxd/docs/master/reference/devices_disk/ LXD のディスクデバイスに関する文書]
   
−
See also: [https://discuss.linuxcontainers.org/t/share-folders-and-volumes-between-host-and-containers/7735 tutorial in the LXD forums]
 +
また、[https://discuss.linuxcontainers.org/t/share-folders-and-volumes-between-host-and-containers/7735 LXD フォーラムのチュートリアル] も参照してください。
   
−
=== Bash completion doesn't work ===
 +
=== Bash 補完が動作しない ===
   
  +
このワークアラウンドで問題が解決するかもしれません：
−
This workaround may fix the issue:
  
   
 
# ln -s /usr/share/bash-completion/completions/lxd /usr/share/bash-completion/completions/lxc
  
# ln -s /usr/share/bash-completion/completions/lxd /usr/share/bash-completion/completions/lxc
332行目: 335行目:
 
== トラブルシューティング ==
  
== トラブルシューティング ==
   
−
=== lxd-agent inside a virtual machine ===
 +
=== 仮想マシン内の lxd-agent ===
   
  +
一部の仮想マシンイメージ内では、{{ic|lxd-agent}} はデフォルトでは有効になっていません。この場合、たとえば {{ic|9p}} ネットワーク共有をマウントするなどして、手動で有効にする必要があります。これには、有効なユーザーによるコンソールアクセスが必要です。
−
Inside some virtual machine images the {{ic|lxd-agent}} is not enabled by default. <br>
  
−
In this case you have to enable it manually, for example by mounting a {{ic|9p}} network share. This requires console access with a valid user.
  
   
  +
1.{{ic|lxc console}}でログインしてください ({{ic|virtualmachine-name}} の部分は適宜置き換えてください):
−
1. Login with {{ic|lxc console}}: <br>
  
−
Replace {{ic|virtualmachine-name}} accordingly.
  
   
 
$ lxc console virtualmachine-name
  
$ lxc console virtualmachine-name
   
  +
root としてログインします:
−
Login as root:
  
  +
−
{{Note | On some systems you have to setup a root password first to be able to login as root. <br> You can use [https://linuxcontainers.org/lxd/advanced-guide/#cloud-init cloud-init] for this for example.}}
  
  +
{{Note | 一部のシステムでは、root としてログインできるようにするには、最初に root パスワードを設定する必要があります。これには、[https://linuxcontainers.org/lxd/advanced-guide/#cloud-init cloud-init] を使用できます。}}
   
 
$ su root
  
$ su root
   
  +
ネットワーク共有をマウントします:
−
Mount the network share:
  
   
 
$ mount -t 9p config /mnt/
  
$ mount -t 9p config /mnt/
   
  +
フォルダーに移動し、インストールスクリプトを実行します (これにより、VM 内の lxd-agent が有効になります):
−
Go into the folder and run the install script (this will enable the lxd-agent inside the VM):
  
   
 
$ cd /mnt/
  
$ cd /mnt/
 
$ ./install.sh
 
$ ./install.sh
   
  +
インストールが成功したら、次のようにして再起動します:
−
After sucessful install, reboot with:
  
   
 
$ reboot
  
$ reboot
   
−
Afterwards the {{ic|lxd-agent}} is available and {{ic|lxc exec}} should work.
 +
その後、{{ic|lxd-agent}} が利用可能になり、{{ic|lxc exec}} が動作するはずです。
   
 
=== カーネルコンフィグの確認 ===
  
=== カーネルコンフィグの確認 ===
  +
 
デフォルトで Arch Linux のカーネルは Linux Containers とフロントエンドの LXD が動くようにコンパイルされています。カスタムカーネルを使っている場合やカーネルオプションを変更している場合、LXD が動かない場合があります。コンテナを実行できるようにカーネルが設定されているか確認してください:
  
デフォルトで Arch Linux のカーネルは Linux Containers とフロントエンドの LXD が動くようにコンパイルされています。カスタムカーネルを使っている場合やカーネルオプションを変更している場合、LXD が動かない場合があります。コンテナを実行できるようにカーネルが設定されているか確認してください:
  +
 
$ lxc-checkconfig
  
$ lxc-checkconfig
   
  +
=== コンテナ内から見た時にリソース制限が適用されない ===
−
=== Resource limits are not applied when viewed from inside a container ===
  
   
  +
{{Pkg|lxcfs}} をインストールして {{ic|lxcfs.service}} を[[起動]]します。この時、lxd を再起動する必要があります。そして、{{ic|lxcfs.service}} を[[有効化]]して起動時にサービスが開始されるようにします。
−
Install {{Pkg|lxcfs}} and [[start]] {{ic|lxcfs.service}}.
  
   
  +
=== 仮想マシンの起動に失敗する ===
−
lxd will need to be restarted. [[Enable]] {{ic|lxcfs.service}} for the service to be started at boot time.
  
   
  +
以下のようなエラーが表示された場合:
−
=== Starting a virtual machine fails ===
  
   
  +
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}]
−
If you see the error: {{ic|Error: Required EFI firmware settings file missing: /usr/share/ovmf/x64/OVMF_VARS.ms.fd}}
  
   
  +
Arch Linux はセキュアブート署名付き ovmf ファームウェアを配布しないため、仮想マシンを起動するには、当面はセキュアブートを無効にする必要があります:
−
Arch Linux does not distribute secure boot signed ovmf firmware, to boot virtual machines you need to disable secure boot for the time being.
  
   
 
$ lxc launch ubuntu:18.04 test-vm --vm -c security.secureboot=false
  
$ lxc launch ubuntu:18.04 test-vm --vm -c security.secureboot=false
   
  +
これは、次のようにしてデフォルトのプロファイルに追加することもできます:
−
This can also be added to the default profile by doing:
  
   
 
$ lxc profile set default security.secureboot=false
  
$ lxc profile set default security.secureboot=false
   
−
=== No IPv4 with systemd-networkd ===
 +
=== systemd-networkd で IPv4 を使用できない ===
   
−
Starting with version version 244.1, systemd detects if {{ic|/sys}} is writable by containers. If it is, udev is automatically started and breaks IPv4 in unprivileged containers. See [https://github.com/systemd/systemd-stable/commit/96d7083c5499b264ecebd6a30a92e0e8fda14cd5 commit bf331d8] and [https://discuss.linuxcontainers.org/t/no-ipv4-on-arch-linux-containers/6395 discussion on linuxcontainers].
 +
バージョン 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}} に対するオーバーライドがすでに存在するはずです。そうでない場合は作成してください:
−
On containers created past 2020, there should already be a {{ic|systemd.networkd.service}} override to work around this issue, create it if it is not:
  
   
 
{{hc|1=/etc/systemd/system/systemd-networkd.service.d/lxc.conf|2=
  
{{hc|1=/etc/systemd/system/systemd-networkd.service.d/lxc.conf|2=
395行目: 399行目:
 
}}
  
}}
   
  +
また、コンテナのプロファイルで {{ic|1=raw.lxc: lxc.mount.auto = proc:rw sys:ro}} を設定することで、コンテナ全体から {{ic|/sys}} を読み取り専用にすることで、この問題を解決することもできますが、先のリンク先の議論にある通り、これは問題になるかもしれません。
−
You could also work around this issue by setting {{ic|1=raw.lxc: lxc.mount.auto = proc:rw sys:ro}} in the profile of the container to ensure {{ic|/sys}} is read-only for the entire container, although this may be problematic, as per the linked discussion above.
  
  +
  +
=== ufw でネットワークに接続できない ===
  +
  +
[[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 allow in on lxdbr0
  +
  +
この2つのコマンドの詳細については、[https://discuss.linuxcontainers.org/t/lxd-bridge-doesnt-work-with-ipv4-and-ufw-with-nftables/10034/17 このスレッド]をチェックして下さい。このスレッドでは、これらのコマンドとその制限について詳しく説明されています。
  +
  +
=== 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行目の {{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 ドキュメントのこのメモ]を参照してください。
   
 
== アンインストール ==
  
== アンインストール ==
   
−
[[Stop]] and disable {{ic|lxd.service}} and {{ic|lxd.socket}}. Then [[uninstall]] the {{Pkg|lxd}} package.
 +
{{ic|lxd.service}} と {{ic|lxd.socket}} を[[停止]]して無効にします。次に、{{Pkg|lxd}} パッケージを[[アンインストール]]します。
   
−
If you uninstalled the package without disabling the service, you might have a lingering broken symlink at {{ic|/etc/systemd/system/multi-user.wants/lxd.service}}.
 +
サービスを無効にせずにパッケージをアンインストールした場合、{{ic|/etc/systemd/system/multi-user.wants/lxd.service}} に壊れたシンボリックリンクが残る可能性があります。
   
  +
すべてのデータを削除したい場合:
−
If you want to remove all data:
  
   
 
# rm -r /var/lib/lxd
  
# rm -r /var/lib/lxd
   
  +
ネットワーク構成例のいずれかを使用した場合は、それらも削除する必要があります。
−
If you used any of the example networking configuration, you should remove those as well.
  
   
 
== 参照 ==
  
== 参照 ==
   
−
* [https://lxd.readthedocs.io 公式ドキュメント]
 +
* [https://linuxcontainers.org/lxd/ LXD の公式ホームページ]
−
* [https://linuxcontainers.org/lxd/ LXD 公式ホームページ]
 +
* [https://linuxcontainers.org/lxd/docs/master/ 公式ドキュメント]
  +
* [https://linuxcontainers.org/lxd/getting-started-cli/ スタートガイド]
  +
* [https://linuxcontainers.org/lxd/advanced-guide/ アドバンスガイド]
  +
* [https://discuss.linuxcontainers.org/ 公式フォーラム]
 
* [https://github.com/lxc/lxd LXD の GitHub ページ]
  
* [https://github.com/lxc/lxd LXD の GitHub ページ]
  +
* [https://github.com/lxc/lxd LXD のチュートリアル]
  +
* [https://discuss.linuxcontainers.org/c/tutorials/16 チュートリアル in LXD フォーラム]
  +
* [https://discuss.linuxcontainers.org/c/tutorials/16 リリースノート in LXD フォーラム]
  +
* [https://discuss.linuxcontainers.org/tag/release LXD フォーラムのリリースノート]

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 バイナリ)
ノート: 少しややこしいですが、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) のうち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
ノート:
  • 今のところ、仮想マシンはコンテナよりも少ない機能しかサポートしていません (例えば、コンテナと仮想マシンの違い を参照)
  • 公式のイメージのうち、特に設定せずに lxd-agent (lxc exec などの通常の lxc コマンドを使うために必要です) を使えるのは cloud バリアントのみです。lxc image list images: cloud や lxc image list images: distribution-name cloud でクラウドイメージを検索できます。他のイメージを使う場合や、問題に遭遇した場合は、#仮想マシン内の lxd-agent 章を見てください。

コンテナまたは 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#)

一定時間が経過すると、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 および 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

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

参照

「https://wiki.archlinux.jp/index.php?title=LXD&oldid=34730」から取得