LXD

提供: ArchWiki
ナビゲーションに移動 検索に移動

関連記事

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

仮想マシンを作成する

フラグ --vmlxc launch に追加するだけです:

$ lxc launch ubuntu:20.04 --vm
ノート:
  • 今のところ、仮想マシンはコンテナよりも少ない機能しかサポートしていません (例えば、コンテナと仮想マシンの違い を参照)
  • 公式のイメージのうち、特に設定せずに lxd-agent (lxc exec などの通常の lxc コマンドを使うために必要です) を使えるのは cloud バリアントのみです。lxc image list images: cloudlxc 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 を使用する方法があります(xy をあなたのブリッジ 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/インターネットに接続するものです、例えば enp6sowlp5s0、...) に置き換えてください。必要に応じて lxdbr0 も置き換えてください。

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

アンインストール

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

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

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

# rm -r /var/lib/lxd

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

参照