「LXD」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(序文の和訳)
(リンクを修正)
 
(4人の利用者による、間の35版が非表示)
2行目: 2行目:
 
[[en:LXD]]
  
[[en:LXD]]
 
{{Related articles start}}
  
{{Related articles start}}
−
{{Related|Linux Containers}}
 +
{{Related|Linux コンテナ}}
 
{{Related articles end}}
  
{{Related articles end}}
−
'''[https://linuxcontainers.org/lxd/ LXD]''' はコンテナ(LXC経由)および仮想マシン([[Qemu]]経由)のマネージャー/ハイパーバイザーです。
 +
'''[https://linuxcontainers.org/lxd/ LXD]''' はコンテナ(LXC経由)および仮想マシン([[QEMU]]経由)のマネージャー/ハイパーバイザーです。
  +
  +
== 必要なソフトウェア ==
  +
{{Pkg|lxd}} パッケージをインストールします。
  +
あるいは、インスタンスを自動起動する場合など、{{ic|lxd.service}} を直接、[[systemd#ユニットを使う|有効]]にすることもできます。
   
 
== セットアップ ==
  
== セットアップ ==
−
=== 必要なソフトウェア ===
  
−
{{Pkg|lxd}} パッケージをインストールして、{{ic|lxd.service}} を[[systemd#ユニットを使う|有効]]にします。
  
   
−
=== 他のインストール方法 ===
 +
=== 一般ユーザー用のコンテナ設定 ===
  +
  +
一般ユーザー用のコンテナ（unprivileged containers）を使用することが推奨されます（違いについては [[Linux_Containers#Privileged_containers_or_unprivileged_containers]] を参照してください）。
  +
  +
このために、{{ic|/etc/subuid}} と {{ic|/etc/subgid}} の両方を変更します（これらのファイルが存在しない場合は、作成してください）。コンテナで使用する uid / gid のマッピングを各ユーザーに設定する必要があります。以下の例は単に root ユーザー（および systemd システムユニット）のためのものです：
  +
  +
{{ic|usermod}} コマンドを以下のように使用することもできます：
  +
  +
{{ic|usermod -v 1000000-1000999999 -w 1000000-1000999999 root}}
  +
  +
または、上記のファイルを直接以下のように変更することもできます：
  +
  +
{{hc|/etc/subuid|
  +
root:1000000:1000000000
  +
}}
  +
  +
{{hc|/etc/subgid|
  +
root:1000000:1000000000
  +
}}
   
  +
これで、すべてのコンテナはデフォルトで {{ic|unprivileged}} として起動されます。
−
{{AUR|snapd}} パッケージをインストールしてから以下のコマンドを実行することで [[snapd]] を使って LXD をインストールできます:
  
   
  +
代替方法については、[[#特権コンテナ|特権コンテナの設定方法]] を参照してください。
−
# snap install lxd
  
   
 
=== LXD の設定 ===
  
=== LXD の設定 ===
26行目: 46行目:
 
# usermod -a -G lxd <user>
  
# usermod -a -G lxd <user>
   
−
== 基本的な使い方 ==
 +
== 使用方法 ==
   
  +
LXD は 2 つの部分で構成されます:
−
=== コンテナの作成 ===
  
  +
* デーモン (''lxd'' バイナリ)
  +
* クライアント (''lxc'' バイナリ)
   
  +
{{Note |少しややこしいですが、lxc は LXC ではありません。違いについては、[https://discuss.linuxcontainers.org/t/comparing-lxd-vs-lxc/24 LXD と LXC の比較に関するフォーラムの投稿]を参照してください。}}
−
LXD はデーモン (lxd バイナリ) とクライアント (lxc バイナリ) の2つに分かれています。デーモンを設定して実行したら、コンテナを作成できます:
  
   
  +
クライアントは、1 つまたは複数のデーモンを制御するために使用されます。
−
$ lxc launch ubuntu:16.04
  
   
−
もしくは、リモートの LXD ホストをイメージソースとして使うこともできます。LXD で設定済みのイメージを使用するには (images.linuxcontainers.org):
 +
クライアントを使用して、リモート LXD サーバーを制御することもできます。
   
  +
=== コマンドの概要 ===
−
$ lxc launch images:centos/7/amd64 centos
  
  +
  +
次のように入力すると、使用可能なすべてのコマンドの概要を確認できます:
  +
  +
$ lxc
  +
  +
=== コンテナを作成する ===
  +
  +
例えば {{ic| lxc launch}} でコンテナを作成できます:
  +
  +
$ lxc launch ubuntu:20.04
  +
  +
コンテナは、イメージサーバーまたはリモート LXD サーバーからダウンロードされたイメージに基づいています。<br>
  +
すでに追加されているサーバーのリストは、次のコマンドで確認できます:
  +
  +
$ lxc remote list
  +
  +
例えば {{ic| lxc image list}} でサーバ上の全ての画像を一覧表示できます:
  +
  +
$ lxc image list images:
  +
  +
これにより、複数のデフォルトサーバー ([https://images.linuxcontainers.org 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
  +
  +
=== 仮想マシンを作成する ===
  +
  +
フラグ {{ic|--vm}} を {{ic|lxc launch}} に追加するだけです:
  +
  +
$ lxc launch ubuntu:20.04 --vm
  +
  +
{{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 の使用と管理 ===
  +
  +
[https://linuxcontainers.org/lxd/getting-started-cli/#instance-management LXD の公式スタートガイドのインスタンス管理]を参照してください。
  +
  +
=== コンテナ/VM 構成 (オプション) ===
  +
  +
インスタンス (コンテナーと VM) にさまざまなオプションを追加できます。<br>
  +
詳細については、[https://linuxcontainers.org/lxd/advanced-guide/#configuration-of-instances LXD の公式アドバンストガイドのインスタンスの設定]を参照してください。
   
 
== ヒントとテクニック ==
  
== ヒントとテクニック ==
   
−
=== LXD のネットワーク ===
 +
=== ホスト上でコンテナーに名前でアクセスする ===
   
  +
これは、デフォルトのブリッジである {{ic|lxdbr0}} を使用していて、[[systemd-resolved]] を使用している場合を前提としています。
−
LXD は LXC のネットワーク機能を使います。デフォルトではコンテナを {{ic|lxcbr0}} ネットワークデバイスに接続します。コンテナのブリッジを設定する方法は LXC の[[Linux Containers#ホストネットワークの設定|ネットワーク設定]]のドキュメントを読んでください。
  
   
  +
# systemd-resolve --interface lxdbr0 --set-domain '~lxd' --set-dns $(lxc network get lxdbr0 ipv4.address | cut -d / -f 1)
−
{{ic|lxcbr0}} 以外のインターフェイスを使いたい場合、lxc のコマンドラインツールを使ってデフォルト設定を編集してください:
  
   
  +
これで、名前でコンテナーにアクセスできるようになります:
−
$ lxc profile edit default
  
   
  +
$ ping ''containername''.lxd
−
エディタで設定ファイルが開きます。デフォルトでは以下の内容になっています:
  
   
  +
==== その他の解決策 ====
−
name: default
  
−
config: {}
  
−
devices:
  
−
eth0:
  
−
name: eth0
  
−
nictype: bridged
  
−
parent: lxcbr0
  
−
type: nic
  
   
  +
{{Accuracy|''systemd-resolve'' がいつ動かなくなるのか？バグレポートや他の参考資料はありますか？}}
−
{{ic|parent}} パラメータを設定することで LXD でコンテナに接続するブリッジを決めることができます。
  
   
  +
一定時間が経過すると、''systemd-resolve'' の解決策は機能しなくなるようです。
−
==== ネットワーク設定例 ====
  
   
  +
別の解決策としては、以下の {{ic|lxd.network}} を用いて [[systemd-networkd]] を使用する方法があります（{{ic|''x''}} と {{ic|''y''}} をあなたのブリッジ IP に合わせて置き換えてください）：
−
LXD パッケージにはネットワークの設定例が付属しており {{ic|/usr/share/lxd/}} に保存されます。設定を使用するには以下のコマンドを実行してください:
  
   
  +
{{hc|/etc/systemd/network/lxd.network|2=
−
$ ln -s /usr/share/lxd/dnsmasq-lxd.conf /etc/dnsmasq-lxd.conf
  
  +
[Match]
−
$ ln -s /usr/share/lxd/systemd/system/dnsmasq@lxd.service /etc/systemd/system/dnsmasq@lxd.service
 
  +
Name=lxdbr0
−
$ 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
  
   
  +
[Network]
−
[[NetworkManager]] を使用する場合、以下のようにシンボリックリンクを作成してください:
  
  +
DNS=''10.x.y.1''
  +
Domains=~lxd
  +
IgnoreCarrierLoss=yes
   
  +
[Address]
−
$ ln -s /usr/share/lxd/NetworkManager/dnsmasq.d/lxd.conf /etc/NetworkManager/dnsmasq.d/lxd.conf
  
  +
Address=''10.x.y.1''/24
  +
Gateway=''10.x.y.1''
  +
}}
   
  +
=== Wayland と Xorg アプリケーションの使用 ===
−
{{ic|parent: lxcbr0}} を {{ic|parent: lxd}} に変更してください:
  
   
  +
{{Note|セキュリティの影響を常に考慮してください。記載されている方法のいくつかは、コンテナとホストとの分離を弱める可能性があります。}}
−
$ lxc profile edit default
  
   
  +
コンテナ内で GUI アプリケーションを使用するための複数の方法があります。[https://discuss.linuxcontainers.org/t/overview-gui-inside-containers/8767 公式 LXD フォーラム] で概要が見れます。
−
最後に、{{ic|dnsmasq@lxd.service}} と {{ic|netctl@lxd.service}} を[[起動]]・[[有効化]]してください。
  
   
  +
以下の方法は、コンテナに Wayland（+Xwayland）または Xorg のホストのソケットへのアクセスを許可します。
−
上記のサンプル設定で問題が発生する場合、{{AUR|lxd}} のページにコメントを投稿してください。
  
   
  +
{{Note|Xorg を使用することで、コンテナとホストとの分離が弱まる可能性があります。なぜなら、Xorg はアプリケーションが他のアプリケーションのウィンドウにアクセスできるようにするからです。代わりに Wayland を使用してください（ただし、Xorg のデメリットも Xwayland に適用されることに注意してください）。}}
−
=== プロセスやファイルの制限を変更する ===
  
   
  +
==== コンテナのプロファイルに以下のデバイスを追加 ====
−
ファイル記述子の制限やユーザーが使用できる最大プロセス数の制限を増やしたい場合 (Arch Linux ではデフォルトで1024になっています)、{{ic|lxd.service}} を[[systemd#ユニットファイルの編集|編集]]してください:
  
   
  +
[https://linuxcontainers.org/lxd/docs/master/instances#device-types LXD のデバイスに関するドキュメント]も参照してください。
−
{{hc|# systemctl edit lxd.service|2=
  
  +
−
[Service]
  
  +
GPU 用の一般的なデバイス：
−
LimitNOFILE=infinity
  
  +
−
LimitNPROC=infinity
  
  +
mygpu:
−
TasksMax=infinity
  
  +
type: gpu
  +
  +
{{Note|「listen」の下のパスが異なる理由は、{{ic|/run}} および {{ic|/tmp}} ディレクトリが上書きされる可能性があるためです。https://github.com/lxc/lxd/issues/4540{{Dead link|2023|09|16|status=404}} を参照してください。}}
  +
  +
Wayland ソケット用のデバイス：
  +
  +
{{Note|
  +
* ディスプレイ（wayland-0）を適宜調整してください。
  +
* コンテナ内の {{ic|/mnt}} および {{ic|/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）ソケット用のデバイス：
−
=== カーネルコンフィグの確認 ===
  
  +
−
デフォルトで Arch Linux のカーネルは Linux Containers とフロントエンドの LXD が動くようにコンパイルされています。カスタムカーネルを使っている場合やカーネルオプションを変更している場合、LXD が動かない場合があります。コンテナを実行できるようにカーネルが設定されているか確認してください:
  
  +
{{Note|ディスプレイ番号を適宜調整してください（例：X0 の代わりに X1 など）。}}
−
$ lxc-checkconfig
  
  +
  +
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
  +
  +
==== コンテナ内でソケットを適切な場所にリンク ====
  +
  +
{{Note|これらのスクリプトは、コンテナの各起動後に実行する必要があります。たとえば、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
  +
  +
==== コンテナ内のユーザー設定に環境変数を追加 ====
  +
  +
{{Note|ディスプレイ番号やファイル名（.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
  +
  +
{{ic|~/.profile}} をリロード：
  +
  +
$ source ~/.profile
  +
  +
==== コンテナ内で必要なソフトウェアをインストール ====
  +
  +
必要なソフトウェアを追加する必要があります。今のところ、例として GUI アプリケーションをインストールできます。これによって、必要なパッケージもすべてインストールされるでしょう。
  +
  +
==== GUI アプリケーションを起動 ====
  +
  +
これで、コンテナ内で GUI アプリケーションを起動することができます（例えば、ターミナル経由で）そして、それらをホストのディスプレイ上にウィンドウとして表示させることができます。
  +
  +
例として ''glxgears'' を試してみてください。
  +
  +
=== 特権コンテナ ===
  +
  +
{{Note|
  +
* 特権コンテナはホストから隔離されていません！
  +
* コンテナ内の root ユーザーはホストの root ユーザーです。
  +
* 可能な限り、特権でないコンテナを使用してください。
  +
}}
  +
  +
特権コンテナを設定したい場合、設定キーとして {{ic|1=security.privileged=true}} を提供する必要があります。
   
−
=== CONFIG_USER_NS 無しでコンテナを起動する ===
 +
コンテナ作成中に：
−
イメージを起動するにはイメージの生成時に {{ic|1=security.privileged=true}} が必要です:
  
   
−
$ lxc launch ubuntu:16.04 ubuntu -c security.privileged=true
 +
$ lxc launch ubuntu:20.04 ubuntu -c security.privileged=true
   
−
もしくは既存のイメージを使う場合は設定を編集してください:
 +
既存のコンテナで設定を編集する場合：
   
 
{{hc|$ lxc config edit ubuntu|
  
{{hc|$ lxc config edit ubuntu|
114行目: 272行目:
 
security.privileged: "true"
  
security.privileged: "true"
 
...
  
...
−
devices:
  
−
root:
  
−
path: /
  
−
type: disk
  
−
ephemeral: false
  
 
}}
  
}}
   
  +
=== ディスクデバイスを追加 ===
−
新しいコンテナで {{ic|1=security.privileged=true}} を有効にしたい場合、デフォルトプロファイルの設定を編集してください:
  
  +
  +
==== 読み取り専用 ====
  +
  +
ホストからコンテナにディスクデバイスを共有したいだけなら、コンテナに {{ic|disk}} デバイスを追加するだけです。仮想の {{ic|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 カーネル（{{Pkg|linux}}）にも含まれています。
  +
* 古いバージョンは "shiftfs" と呼ばれ、ほとんどのカーネルに手動で追加する必要があります。これはレガシーバージョンとして、古いカーネルをサポートするためにあります。この GitHub リポジトリは Ubuntu カーネルからの shiftfs カーネルモジュールを使用しています：https://github.com/toby63/shiftfs-dkms
  +
  +
shift は、通常の Arch Linux カーネル（{{Pkg|linux}}）と {{Pkg|lxd}} パッケージによって、デフォルトで利用可能であり、有効になっているはずです。
  +
  +
'''1. システムで shift が利用可能かどうかを確認するには''', {{ic|lxc info}} を実行します。
  +
  +
出力の最初の部分で表示されるのは：
  +
  +
{{bc| kernel_features:
  +
idmapped_mounts: "true"
  +
shiftfs: "false"
  +
}}
  +
  +
idmapped_mounts または shiftfs のいずれかが true の場合、そのカーネルはすでにそれを含んでおり、shift を使用できます。
  +
true でない場合、カーネルバージョンを確認し、上記で述べた "shiftfs" レガシーバージョンを試すことができます。
  +
  +
出力の第二部では、次のいずれかが表示されます：
  +
  +
{{bc| lxc_features:
  +
idmapped_mounts_v2: "true"
  +
}}
  +
  +
または:
  +
  +
{{bc| lxc_features:
  +
shiftfs: "true"
  +
}}
  +
  +
idmapped_mounts または shiftfs のいずれかが true の場合、LXD は既にそれを有効にしています。
  +
有効にされていない場合、最初にそれを有効にする必要があります。
  +
  +
'''2. 使い方'''
  +
  +
ディスクデバイスのオプションで "shift" 設定キーを "true" に設定するだけです。
  +
参照：[https://linuxcontainers.org/lxd/docs/master/reference/devices_disk/ LXD のディスクデバイスに関する文書]
  +
  +
また、[https://discuss.linuxcontainers.org/t/share-folders-and-volumes-between-host-and-containers/7735 LXD フォーラムのチュートリアル] も参照してください。
  +
  +
=== Bash 補完が動作しない ===
  +
  +
このワークアラウンドで問題が解決するかもしれません：
  +
  +
# ln -s /usr/share/bash-completion/completions/lxd /usr/share/bash-completion/completions/lxc
  +
  +
== トラブルシューティング ==
  +
  +
=== 仮想マシン内の lxd-agent ===
  +
  +
一部の仮想マシンイメージ内では、{{ic|lxd-agent}} はデフォルトでは有効になっていません。この場合、たとえば {{ic|9p}} ネットワーク共有をマウントするなどして、手動で有効にする必要があります。これには、有効なユーザーによるコンソールアクセスが必要です。
  +
  +
1.{{ic|lxc console}}でログインしてください ({{ic|virtualmachine-name}} の部分は適宜置き換えてください):
  +
  +
$ lxc console virtualmachine-name
  +
  +
root としてログインします:
  +
  +
{{Note | 一部のシステムでは、root としてログインできるようにするには、最初に root パスワードを設定する必要があります。これには、[https://linuxcontainers.org/lxd/advanced-guide/#cloud-init cloud-init] を使用できます。}}
  +
  +
$ su root
  +
  +
ネットワーク共有をマウントします:
  +
  +
$ mount -t 9p config /mnt/
  +
  +
フォルダーに移動し、インストールスクリプトを実行します (これにより、VM 内の lxd-agent が有効になります):
  +
  +
$ cd /mnt/
  +
$ ./install.sh
  +
  +
インストールが成功したら、次のようにして再起動します:
  +
  +
$ reboot
  +
  +
その後、{{ic|lxd-agent}} が利用可能になり、{{ic|lxc exec}} が動作するはずです。
  +
  +
=== カーネルコンフィグの確認 ===
  +
  +
デフォルトで Arch Linux のカーネルは Linux Containers とフロントエンドの LXD が動くようにコンパイルされています。カスタムカーネルを使っている場合やカーネルオプションを変更している場合、LXD が動かない場合があります。コンテナを実行できるようにカーネルが設定されているか確認してください:
  +
  +
$ lxc-checkconfig
  +
  +
=== コンテナ内から見た時にリソース制限が適用されない ===
  +
  +
{{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}]
  +
  +
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 は {{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}} に対するオーバーライドがすでに存在するはずです。そうでない場合は作成してください:
  +
  +
{{hc|1=/etc/systemd/system/systemd-networkd.service.d/lxc.conf|2=
  +
[Service]
  +
BindReadOnlyPaths=/sys
  +
}}
  +
  +
また、コンテナのプロファイルで {{ic|1=raw.lxc: lxc.mount.auto = proc:rw sys:ro}} を設定することで、コンテナ全体から {{ic|/sys}} を読み取り専用にすることで、この問題を解決することもできますが、先のリンク先の議論にある通り、これは問題になるかもしれません。
  +
  +
=== 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 ドキュメントのこのメモ]を参照してください。
  +
  +
== アンインストール ==
   
  +
{{ic|lxd.service}} と {{ic|lxd.socket}} を[[停止]]して無効にします。次に、{{Pkg|lxd}} パッケージを[[アンインストール]]します。
−
$ lxc profile edit default
  
   
  +
サービスを無効にせずにパッケージをアンインストールした場合、{{ic|/etc/systemd/system/multi-user.wants/lxd.service}} に壊れたシンボリックリンクが残る可能性があります。
−
=== 非特権の Arch コンテナ で IPv4 アドレスが取得できない ===
  
   
  +
すべてのデータを削除したい場合:
−
LXD v2.20 ではコンテナが {{ic|1=systemd-networkd}} サービスを起動できずに IPv4 アドレスが取得できません。LXD ホストで以下のコマンドを実行してからコンテナを再起動することで解決できます ([https://github.com/lxc/lxd/issues/4071 Github Issue]):
  
   
  +
# rm -r /var/lib/lxd
−
$ lxc profile set default security.syscalls.blacklist "keyctl errno 38"
  
   
  +
ネットワーク構成例のいずれかを使用した場合は、それらも削除する必要があります。
−
原因は systemd の networkd ユニットが利用しているカーネルキーリングが非特権コンテナで機能しないためです。上記のコマンドを使うことでシステムコールは未実装を返すようになります。
  
   
 
== 参照 ==
  
== 参照 ==
   
−
* [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 フォーラムのリリースノート]

2024年7月10日 (水) 19:10時点における最新版

関連記事

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=37915」から取得