「LXD」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(→‎参照: リンクを更新)
433行目: 433行目:
 
== 参照 ==
 
== 参照 ==
   
* [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日 (月) 02:33時点における版

関連記事

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 consists of two parts:

  • the daemon (the lxd binary)
  • the client (the lxc binary)
ノート: lxc is not LXC; the naming is a bit confusing, you can read the forum post on comparing LXD vs LXC regarding the difference.

The client is used to control one or multiple daemon(s).

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

Create a container

You can create a container with lxc launch, for example:

$ lxc launch ubuntu:20.04

Container are based on images, that are downloaded from image servers or remote LXD servers.
You can see the list of already added servers with:

$ lxc remote list

You can list all images on a server with lxc image list, for example:

$ lxc image list images:

This will show you all images on one of the default servers: images.linuxcontainers.org

You can also search for images by adding terms like the distribution name:

$ lxc image list images:debian

Launch a container with an image from a specific server with:

$ lxc launch servername:imagename

For example:

$ lxc launch images:centos/8/amd64 centos

To create an amd64 Arch container:

$ lxc launch images:archlinux/current/amd64 arch

Create a virtual machine

Just add the flag --vm to lxc launch:

$ lxc launch ubuntu:20.04 --vm
ノート:
  • For now virtual machines support less features than containers (see Difference between containers and virtual machines for example).
  • Only cloud variants of the official images enable the lxd-agent out-of-the-box (which is needed for the usual lxc commands like lxc exec).
    You can search for cloud images with lxc image list images: cloud or lxc image list images: distribution-name cloud.
    If you use other images or encounter problems take a look at #lxd-agent_inside_a_virtual_machine.

Use and manage a container or VM

See Instance managament in the official Getting Started Guide of LXD.

Container/VM configuration (optional)

You can add various options to instances (containers and VMs).
See Configuration of instances in the official Advanced Guide of LXD for details.

Tips and tricks

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

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

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

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

$ ping containername.lxd

その他の解決策

この記事またはセクションの正確性には問題があります。
理由: systemd-resolve がいつ動かなくなるのか?バグレポートや他の参考資料はありますか? (議論: トーク:LXD#)

一定時間が経過すると、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 および の Linux コンテナに関するディスカッションを参照してください。

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

/etc/systemd/system/systemd-networkd.service.d/lxc.conf
[Service]
BindReadOnlyPaths=/sys

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

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

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

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

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

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

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

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

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

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

アンインストール

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

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

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

# rm -r /var/lib/lxd

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

参照