diff --git a/doc/api-extensions.md b/doc/api-extensions.md index 2790de0..98d45be 100644 --- a/doc/api-extensions.md +++ b/doc/api-extensions.md @@ -2076,7 +2076,6 @@ ACME サポートを追加します。これにより [Let's Encrypt](https://le これは `StorageVolume` と `StorageVolumeSnapshot` API タイプに `CreatedAt` フィールドを追加します。 ## `cpu_hotplug` - これは VM に CPU ホットプラグを追加します。 CPU ピンニング使用時はホットプラグは無効になります。CPU ピンニングには NUMA デバイスのホットプラグも必要ですが、これはできないためです。 @@ -2108,3 +2107,25 @@ NICデバイスの`txqueuelen`パラメータを制御する`txqueuelen`キー StarlarkスクリプトレットをLXDに提供し、クラスタ内の新規インスタンスの配置を制御するカスタムロジックを使えるようにします。 Starlarkスクリプトレットは新しいグローバル設定オプション`instances.placement.scriptlet`によりLXDに提供されます。 + +## `storage_pool_source_wipe` +ストレージプールに`source.wipe`ブール値を追加し、LXDは要求されたディスクのパーティションヘッダーを消去する必要があることを示します。これにより、既存のファイルシステムがあることによる潜在的な失敗を回避できます。 + +## `zfs_block_mode` + +これにより、ZFSブロック`filesystem`ボリュームを使用して、ZFSの上に異なるファイルシステムを使用することができるようになります。 + +これにより、ZFSストレージプールに以下の新しい設定オプションが追加されます： + +* `volume.zfs.block_mode` +* `volume.block.mount_options` +* `volume.block.filesystem` + +## `instance_generation_id` + +インスタンスの世代IDのサポートが追加されます。VMまたはコンテナの世代IDは、インスタンスの時間内での位置が後方に移動するたびに変更されます。現時点では、世代IDはVMタイプのインスタンスを通じてのみ公開されています。これにより、VMゲストOSは、既に発生した可能性のある状態の複製を回避するために必要な状態を再初期化できます： + +* `volatile.uuid.generation` + +## `disk_io_cache` +これは、ディスクデバイスに新しい`io.cache`プロパティを導入し、VMのキャッシング動作を上書きするために使用できます。 diff --git a/doc/authentication.md b/doc/authentication.md index e2d5541..106db6f 100644 --- a/doc/authentication.md +++ b/doc/authentication.md @@ -118,8 +118,8 @@ PKIモードを有効にするには、以下の手順を実行します。 1. すべてのマシンに{abbr}`CA（認証局）`の証明書を追加します。 - - クライアントの設定ディレクトリ（`~/.config/lxc`）に`client.ca`ファイルを配置する。 - - `server.ca`ファイルをサーバの設定ディレクトリ（`/var/lib/lxd`またはsnapユーザの場合は`/var/snap/lxd/common/lxd`）に置く。 + - クライアントの設定ディレクトリ(`~/.config/lxc`またはSnapユーザーの場合は`~/snap/lxd/common/config`)に`client.ca`ファイルを配置する。 + - `server.ca`ファイルをサーバの設定ディレクトリ(`/var/lib/lxd`またはSnapユーザーの場合は`/var/snap/lxd/common/lxd`)に置く。 1. CAから発行された証明書をクライアントとサーバーに配置し、自動生成された証明書を置き換える。 1. サーバーを再起動します。 diff --git a/doc/cloud-init.md b/doc/cloud-init.md index 0a1a2f5..e7c6e07 100644 --- a/doc/cloud-init.md +++ b/doc/cloud-init.md @@ -4,107 +4,139 @@ relatedlinks: https://cloudinit.readthedocs.org/ --- (cloud-init)= -# cloud-init +# `cloud-init`を使用するには ```{youtube} https://www.youtube.com/watch?v=8OCG15TAldI ``` -LXD は次のインスタンスまたはプロファイル設定キーを使用して [cloud-init](https://launchpad.net/cloud-init) をサポートします。 +[`cloud-init`](https://cloud-init.io/)はLinuxディストリビューションのインスタンスの自動的な初期化とカスタマイズのためのツールです。 -* `cloud-init.vendor-data` -* `cloud-init.user-data` -* `cloud-init.network-config` +インスタンスに`cloud-init`設定を追加することで、インスタンスの最初の起動時に`cloud-init`に特定のアクションを実行させることができます。 +可能なアクションには、例えば以下のようなものがあります： -詳細な情報は[`cloud-init` インスタンスオプション](instance-options-cloud-init)と`cloud-init`ドキュメント内の[LXDデータソース](https://cloudinit.readthedocs.io/en/latest/reference/datasources/lxd.html)を参照してください。 +* パッケージの更新とインストール +* 特定の設定の適用 +* ユーザーの追加 +* サービスの有効化 +* コマンドやスクリプトの実行 +* VMのファイルシステムをディスクのサイズに自動的に拡張する -`cloud-init`を使おうとする前に、これから使おうとするイメージ・ソースをどれにするかをまず決めてください。 +詳細な情報は{ref}`cloud-init:index`を参照してください。 -`ubuntu` と `ubuntu-daily` の remote にあるイメージは全て cloud-init が有効です。 -`images` remote のイメージで `cloud-init` が有効なイメージがあるものは `/cloud` という接尾辞がつきます（例: `images:ubuntu/22.04/cloud`）。 +```{note} +`cloud-init`アクションはインスタンスの最初の起動時に一度だけ実行されます。 +インスタンスの再起動ではアクションは再実行されません。 +``` -`vendor-data` と `user-data` は同じルールに従いますが、以下の制約があります。 +## イメージ内の`cloud-init`サポート -* ユーザーは vendor data に対して究極のコントロールが可能です。実行を無効化したりマルチパートの入力の特定のパートの処理を無効化できます。 -* デフォルトでは初回ブート時のみ実行されます。 -* vendor data はユーザーにより無効化できます。インスタンスの実行に vendor data の使用が必須な場合は vendor data を使うべきではありません。 -* ユーザーが指定した `cloud-config` は vendor data の `cloud-config` の上にマージされます。 +`cloud-init`を使用するには、`cloud-init`がインストールされたイメージをベースにインスタンスを作る必要があります。 -LXD のインスタンスではインスタンスの設定よりもプロファイル内の `vendor-data` を使うべきです。 +* `ubuntu`および`ubuntu-daily` {ref}`イメージサーバ `からのすべてのイメージは`cloud-init`をサポートしています。 +* [`images`リモート](https://images.linuxcontainers.org/)からのイメージには`cloud-init`が有効化されたバリアントがあり、通常デフォルトバリアントよりもサイズが大きくなります。 +クラウドバリアントは`/cloud`接尾辞を使用します。例えば、`images:ubuntu/22.04/cloud`。 -`cloud-config` の例は [cloud-init のドキュメント](https://cloudinit.readthedocs.io/en/latest/topics/examples.html) にあります。 +## 設定オプション -```{note} -`cloud-init.user-data`と`cloud-init.vendor-data`の両方が指定された場合、`cloud-init`は2つの設定をマージします。 +LXDは、`cloud-init`の設定に対して`cloud-init.*`と`user.*`の2つの異なる設定オプションセットをサポートしています。 +どちらのセットを使用する必要があるかは、使用するイメージの`cloud-init`サポートによって異なります。 +一般的には、新しいイメージは`cloud-init.*`設定オプションをサポートし、古いイメージは`user.*`をサポートしていますが、例外も存在する可能性があります。 -しかし、両方の設定で同じキーを使った場合、マージは不可能になるかもしれません。 -この場合、指定されたデータをどのようにマージするべきかを`clout-init`に指定してください。 -手順は`clou-init`ドキュメントの[Merging User-Data Sections](https://cloudinit.readthedocs.io/en/latest/reference/merging.html)を参照してください。 -``` +以下の設定オプションがサポートされています。 -[`cloud-init`ドキュメント](https://cloudinit.readthedocs.io/en/latest/topics/examples.html)内に -`cloud-config`の例があります。 +* `cloud-init.vendor-data`または`user.vendor-data` ({ref}`cloud-init:vendordata`を参照) +* `cloud-init.user-data`または`user.user-data` ({ref}`cloud-init:user_data_formats`を参照) +* `cloud-init.network-config`または`user.network-config` ({ref}`cloud-init:network_config`を参照) -## cloud-init と連携する +設定オプションの詳細については、[`cloud-init`インスタンスオプション](instance-options-cloud-init)と、`cloud-init`ドキュメント内の{ref}`LXDデータソース `を参照してください。 -安全にテストする方法としては、デフォルトプロファイルからコピーした新しいプロファイルを使います。 +### ベンダーデータとユーザーデータ - lxc profile copy default test +`vendor-data`と`user-data`の両方が、`cloud-init`に{ref}`クラウド構成データ `を提供するために使用されます。 -次に新しい `test` プロファイルを編集します。まず `EDITOR` 環境変数を設定しておくと良いでしょう。 +主な考え方は、`vendor-data`は一般的なデフォルト構成に使用され、`user-data`はインスタンス固有の構成に使用されることです。 +これは、プロファイルで`vendor-data`を指定し、インスタンス構成で`user-data`を指定する必要があることを意味します。 +LXDはこの方法を強制しませんが、プロファイルとインスタンス構成の両方で`vendor-data`と`user-data`を使用することができます。 - lxc profile edit test +インスタンスに対して`vendor-data`と`user-data`の両方が提供される場合、`cloud-init`は2つの構成をマージします。 +しかし、両方の設定で同じキーを使った場合、マージは不可能になるかもしれません。 +この場合、指定されたデータをどのようにマージするべきかを`clout-init`に指定してください。 +{ref}`cloud-init:merging_user_data`を参照して手順を確認してください。 -新しい LXD のインストールでは、設定ファイルは以下の例のような内容になっているはずです。 +## `cloud-init`の設定方法 -```yaml -config: {} -description: Default LXD profile -devices: - eth0: - name: eth0 - network: lxdbr0 - type: nic - root: - path: / - pool: default - type: disk -``` +インスタンスの`cloud-init`を設定するには、対応する設定オプションをインスタンスが使用する{ref}`プロファイル `または{ref}`インスタンス構成 `に直接追加します。 + +インスタンスに直接`cloud-init`を設定する場合、`cloud-init`はインスタンスの最初の起動時にのみ実行されることに注意してください。 +つまり、インスタンスを起動する前に`cloud-init`を設定する必要があります。 +これを行うには、`lxc launch`の代わりに`lxc init`でインスタンスを作成し、設定が完了した後に起動します。 -`cloud-init` 設定を記述し終わったら、 `lxc launch` を `--profile ` 付きで使用してプロファイルをインスタンスに適用します。 +### `cloud-init`設定のYAMLフォーマット -### 設定に cloud-init のキーを追加する +`cloud-init`のオプションでは、YAMLの[literalスタイルフォーマット](https://yaml.org/spec/1.2.2/#812-literal-style)が必要です。 +パイプ記号(`|`)を使用して、パイプの後にインデントされたテキスト全体を、改行とインデントを保持したまま`cloud-init`に単一の文字列として渡すことを示します。 -`cloud-init` キーは特殊な文法を必要とします。パイプ記号 (`|`) を使って、パイプの後のインデント付きのテキスト全体を `cloud-init` に単一の文字列として渡すことを指示します。この際改行とインデントは保持されます。これは YAML で使用される [リテラルスタイルフォーマット](https://yaml.org/spec/1.2.2/#812-literal-style) です。 +`vendor-data`および`user-data`のオプションは通常、`#cloud-config`で始まります。 + +例： ```yaml config: cloud-init.user-data: | + #cloud-config + package_upgrade: true + packages: + - package1 + - package2 ``` -```yaml -config: - cloud-init.vendor-data: | +```{tip} +構文が正しいかどうかを確認する方法については、{ref}`cloud-init:reference/faq:how can i debug my user data?`を参照してください。 ``` -```yaml -config: - cloud-init.network-config: | +## `cloud-init`のステータスを確認する方法 + +`cloud-init`はインスタンスの最初の起動時に自動的に実行されます。 +設定されたアクションによっては、完了するまでに時間がかかる場合があります。 + +`cloud-init`のステータスを確認するには、インスタンスにログインして以下のコマンドを入力します。 + + cloud-init status + +結果が`status: running`の場合、`cloud-init`はまだ実行中です。結果が`status: done`の場合、完了しています。 + +また、`--wait`フラグを使用して、`cloud-init`が完了したときにのみ通知を受け取ることができます： + +```{terminal} +:input: cloud-init status --wait +:user: root +:host: instance + +..................................... +status: done ``` -### カスタム user-data 設定 +## ユーザーデータやベンダーデータを指定する方法 -cloud-init は `user-data` (と `vendor-data`) セクションをパッケージのアップグレード、パッケージのインストールや任意のコマンド実行のようなことに使用します。 +`user-data`と`vendor-data`の設定は、例えば、パッケージのアップグレードやインストール、ユーザーの追加、コマンドの実行などに使用することができます。 -`cloud-init.user-data` キーは最初の行で [データフォーマット](https://cloudinit.readthedocs.io/en/latest/topics/format.html) のどのタイプを `cloud-init` に渡すのかを指示します。パッケージのアップグレードやユーザのセットアップには `#cloud-config` のデータフォーマットを使用します。 +提供される値は、最初の行で`cloud-init`に渡される{ref}`ユーザーデータ形式 `のタイプを示す必要があります。 +パッケージのアップグレードやユーザーの設定などのアクティビティには、`#cloud-config`が使用するデータ形式です。 -この結果インスタンスの rootfs には以下のファイルが作られます。 +構成データは、インスタンスのルートファイルシステム内の以下のファイルに保存されます： * `/var/lib/cloud/instance/cloud-config.txt` * `/var/lib/cloud/instance/user-data.txt` -#### インスタンス作成時にパッケージをアップグレードする +### 例 + +以下のセクションでは、さまざまな例のユースケースに対するユーザーデータ（またはベンダーデータ）の設定を参照してください。 + +より高度な{ref}`例 `は、`cloud-init`ドキュメントで見つけることができます。 + +#### パッケージのアップグレード -インスタンス用のレポジトリからパッケージのアップグレードをトリガーするには `package_upgrade` キーを使用します。 +インスタンスが作成された直後に、インスタンスのリポジトリからパッケージをアップグレードするためには、`package_upgrade`キーを使用します： ```yaml config: @@ -113,9 +145,9 @@ config: package_upgrade: true ``` -#### インスタンス作成時にパッケージをインストールする +#### パッケージのインストール -インスタンスをセットアップするときに特定のパッケージをインストールするには `packages` キーを使用しパッケージ名をリストで指定します。 +インスタンスのセットアップ時に特定のパッケージをインストールするには、`packages`キーを使用し、パッケージ名をリストとして指定します： ```yaml config: @@ -126,9 +158,9 @@ config: - openssh-server ``` -#### インスタンス作成時にタイムゾーンを設定する +#### タイムゾーンの設定 -インスタンスのタイムゾーンを設定するには `timezone` キーを使用します。 +インスタンス作成時にインスタンスのタイムゾーンを設定するには、`timezone`キーを使用します： ```yaml config: @@ -137,9 +169,9 @@ config: timezone: Europe/Rome ``` -#### コマンドを実行する +#### コマンドの実行 -(マーカーファイルを書き込むなど) コマンドを実行するには `runcmd` キーを使用しコマンドをリストで指定します。 +コマンド（マーカーファイルの書き込みなど）を実行するには、`runcmd`キーを使用し、コマンドをリストとして指定します： ```yaml config: @@ -149,9 +181,10 @@ config: - [touch, /run/cloud.init.ran] ``` -#### ユーザーアカウントを追加する +#### ユーザーアカウントの追加 -ユーザーアカウントを追加するには `user` キーを使用します。デフォルトユーザとどのキーがサポートされるかについての詳細は [ドキュメント](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups) を参照してください。 +ユーザーアカウントを追加するには、`user`キーを使用します。 +デフォルトユーザーやサポートされているキーに関する詳細は、`cloud-init`ドキュメント内の{ref}`cloud-init:reference/examples:including users and groups`の例を参照してください。 ```yaml config: @@ -161,22 +194,22 @@ config: - name: documentation_example ``` -### カスタムネットワーク設定 +## ネットワーク構成データを指定する方法 -`cloud-init` は、`network-config` データを使い、Ubuntu リリースに応じて -`ifupdown` もしくは `netplan` のどちらかを使って、システム上の関連する設定 -を行います。 +デフォルトでは、`cloud-init`はインスタンスの`eth0`インターフェイスにDHCPクライアントを設定します。 +デフォルトの構成を上書きするために、`network-config`オプションを使用して独自のネットワーク構成を定義することができます（これはテンプレートの構造によるものです）。 -デフォルトではインスタンスの `eth0` インタフェースで DHCP クライアントを使うように -なっています。 +その後、`cloud-init`はUbuntuリリースに応じて`ifupdown`か`netplan`を使用して、システム上の関連するネットワーク構成をレンダリングします。 -これを変更するためには設定ディクショナリ内の `cloud-init.network-config` キーを -使ってあなた自身のネットワーク設定を定義する必要があります。その設定が -デフォルトの設定をオーバーライドするでしょう（これはテンプレートがそのように -構成されているためです）。 +構成データは、インスタンスのルートファイルシステム内の以下のファイルに保存されます： -例えば、ある特定のネットワーク・インタフェースを静的 IPv4 アドレスを持ち、 -カスタムのネームサーバを使うようにするには、以下のようにします。 +* `/var/lib/cloud/seed/nocloud-net/network-config` +* `/etc/network/interfaces.d/50-cloud-init.cfg` (`ifupdown`を使用している場合) +* `/etc/netplan/50-cloud-init.yaml` (`netplan`を使用している場合) + +### 例 + +特定のネットワークインターフェースに静的なIPv4アドレスを設定し、カスタム名前サーバーを使用するための次の設定を使用します： ```yaml config: @@ -195,9 +228,3 @@ config: - type: nameserver address: 10.10.10.254 ``` - -この結果、インスタンスの rootfs には以下のファイルが作られます。 - - * `/var/lib/cloud/seed/nocloud-net/network-config` - * `/etc/network/interfaces.d/50-cloud-init.cfg` (`ifupdown` を使う場合) - * `/etc/netplan/50-cloud-init.yaml` (`netplan` を使う場合) diff --git a/doc/clustering.md b/doc/clustering.md index 01422c6..95e4b6f 100644 --- a/doc/clustering.md +++ b/doc/clustering.md @@ -1,5 +1,5 @@ --- -discourse: 9076 +discourse: 9076,15871 --- (clustering)= diff --git a/doc/config_options_cheat_sheet.md b/doc/config_options_cheat_sheet.md new file mode 100644 index 0000000..94bdc29 --- /dev/null +++ b/doc/config_options_cheat_sheet.md @@ -0,0 +1,135 @@ +--- +orphan: true +--- + +# 設定オプション + +いくつかのインスタンスオプション: + +```{config:option} agent.nic_config instance +:shortdesc: インスタンスデバイスと同じ名前とMTUを設定する +:default: "`false`" +:type: bool +:liveupdate: "`no`" +:condition: 仮想マシン + +デフォルトのネットワークインターフェイスの名前とMTUをインスタンスデバイスと同じに設定するかどうかを制御します（コンテナでは自動的に行われます） +``` + +```{config:option} migration.incremental.memory.iterations instance +:shortdesc: 最大転送操作回数 +:condition: コンテナ +:default: 10 +:type: integer +:liveupdate: "yes" + +インスタンスを停止する前に通過する転送操作の最大回数 +``` + +```{config:option} cluster.evacuate instance +:shortdesc: インスタンスの避難時の対処方法 +:default: "`auto`" +:type: string +:liveupdate: "no" + +インスタンスの避難時に行う操作を制御します（`auto`、`migrate`、`live-migrate`、または`stop`） +``` + +これらは、第二引数として `instance` スコープを指定する必要があります。 +デフォルトのスコープは `server` なので、この引数は必須ではありません。 + +いくつかのサーバーオプション: + +```{config:option} backups.compression_algorithm server +:shortdesc: イメージの圧縮アルゴリズム +:type: string +:scope: global +:default: "`gzip`" + +新しいイメージに使用する圧縮アルゴリズム（`bzip2`、`gzip`、`lzma`、`xz`、または`none`） +``` + +```{config:option} instances.nic.host_name +:shortdesc: ホスト名の生成方法 +:type: string +:scope: global +:default: "`random`" + +`random`に設定されている場合、ランダムなホストインターフェイス名をホスト名として使用します。`mac`に設定されている場合、`lxd`（最初の2桁を省略したMAC）の形式でホスト名を生成します。 +``` + +```{config:option} instances.placement.scriptlet +:shortdesc: カスタム自動インスタンス配置ロジック +:type: string +:scope: global + +カスタム自動インスタンス配置ロジック用の {ref}`clustering-instance-placement-scriptlet` を格納します +``` + +```{config:option} maas.api.key +:shortdesc: MAASを管理するためのAPIキー +:type: string +:scope: global + +MAASを管理するためのAPIキー +``` + +他のスコープも可能です。 +このスコープは、主に短い説明や説明で、利用可能なオプションでフォーマットを使用できることを示しています。 + +```{config:option} test1 something +:shortdesc: テスト + +テスト。 +``` + +```{config:option} test2 something +:shortdesc: こんにちは！ **太字** と `コード` + +これが実際のテキストです。 + +2つの段落で構成されています。 + +そしてリスト: + +- 項目 +- 項目 +- 項目 + +そして表: + +キー | タイプ | スコープ | デフォルト | 説明 +:-- | :--- | :---- | :------ | :---------- +`acme.agree_tos` | bool | global | `false` | ACME利用規約に同意する +`acme.ca_url` | string | global | `https://acme-v02.api.letsencrypt.org/directory` | ACMEサービスのディレクトリリソースへのURL +`acme.domain` | string | global | - | 証明書が発行されるドメイン +`acme.email` | string | global | - | アカウント登録に使用されるメールアドレス +``` + +```{config:option} test3 something +:shortdesc: テスト +:default: "`false`" +:type: タイプ +:liveupdate: Pythonはオプションを解析するため、"no"は"False"に変換されます - これを防ぐためにテキストの周りに引用符を付けてください（"no"または"`no`"） +:condition: "yes" +:readonly: "`maybe` - オプションがコードで始まる場合も引用符を追加してください" +:resource: リソース, +:managed: 管理された +:required: 必須 +:scope: （これは「global」や「local」のようなもので、オプションのスコープ（`server`、`instance`など）では**ありません） + +内容 +``` + +オプションを参照するには、{config:option}を使用してください。 +リンクテキストを上書きすることはできません。 +サーバーオプション（デフォルト）を除いて、スコープを指定する必要があります。 + +{config:option}instance:migration.incremental.memory.iterations + +{config:option}something:test1 + +{config:option}maas.api.key + +索引はこちらです： +{ref}config-options diff --git a/doc/debugging.md b/doc/debugging.md index a73465b..4f5c98e 100644 --- a/doc/debugging.md +++ b/doc/debugging.md @@ -1,5 +1,5 @@ # デバッグ -インスタンスの問題をデバッグする際の情報については、[FAQ](faq.md) を参照してください。 +インスタンスの問題をデバッグする際の情報については、{ref}`instances-troubleshoot`を参照してください。 ## `lxc` と `lxd` のデバッグ @@ -18,18 +18,6 @@ このコマンドはメッセージがリモートのサーバに現れるのをモニターします。 -### `lxd --debug` - -`lxd` サーバを停止して `--debug` フラグでフォアグラウンドで実行することで -たくさんの（願わくは）有用な情報が出力されます。 - -```bash -systemctl stop lxd lxd.socket -lxd --debug --group lxd -``` - -上記の `--group lxd` は非特権ユーザーにアクセス権限を与えるために必要です。 - ## ローカルソケット経由でのREST API サーバサイドでLXDとやりとりするのに最も簡単な方法はローカルソケットを @@ -51,18 +39,18 @@ curl --unix-socket /var/snap/lxd/common/lxd/unix.socket lxd/1.0 | jq . ## HTTPS経由でのREST API -[LXDへのHTTPS接続](security.md)には有効なクライアント証明書が -必要です。証明書は初回に `lxc remote add` を実行したときに -`~/.config/lxc/client.crt` に生成されます。この証明書は -認証と暗号化のために接続ツールに渡す必要があります。 +[LXDへのHTTPS接続](security.md)には、有効な +クライアント証明書が必要で、最初の`lxc remote add`で生成されます。この +証明書は、認証と暗号化のための接続ツールに渡す必要があります。 -証明書の中身に興味がある場合は以下のコマンドで確認できます。 +必要に応じて、`openssl`を使って証明書（`~/.config/lxc/client.crt` +またはSnapユーザーの場合 `~/snap/lxd/common/config/client.crt`）を調べることができます： ```bash -openssl x509 -in client.crt -purpose +openssl x509 -text -noout -in client.crt ``` -コマンドの出力の中に以下の情報を読み取ることが出来るはずです。 +表示される行の中に以下のようなものがあるはずです： Certificate purposes: SSL client : Yes @@ -71,7 +59,10 @@ openssl x509 -in client.crt -purpose ### コマンドラインツールを使う ```bash -wget --no-check-certificate https://127.0.0.1:8443/1.0 --certificate=$HOME/.config/lxc/client.crt --private-key=$HOME/.config/lxc/client.key -O - -q +wget --no-check-certificate --certificate=$HOME/.config/lxc/client.crt --private-key=$HOME/.config/lxc/client.key -qO - https://127.0.0.1:8443/1.0 + +# または snap ユーザーの場合 +wget --no-check-certificate --certificate=$HOME/snap/lxd/common/config/client.crt --private-key=$HOME/snap/lxd/common/config/client.key -qO - https://127.0.0.1:8443/1.0 ``` ### ブラウザを使う diff --git a/doc/doc-cheat-sheet.md b/doc/doc-cheat-sheet.md index d3140a1..1646ea1 100644 --- a/doc/doc-cheat-sheet.md +++ b/doc/doc-cheat-sheet.md @@ -208,7 +208,7 @@ URL をテキストとして表示し、リンクされないようにするに 以下のような規約を守ってください。 -- 中心となるセクションにはターゲットを追加し、「典型的な」リンク先であることから、頻繁にリンクされることが予想されます。単発的なリンクには、自動生成されたアンカーを使用する。 +- セクションの中心的な部分や、頻繁にリンクされることが予想される「典型的な」場所にターゲットを追加してください。一度きりのリンクには、自動生成されるアンカーを使用できます。 - 必要な場合のみリンクテキストを上書きする。セクションのタイトルをリンクテキストとして使用できる場合は、そうしてください。タイトルが変更された場合、テキストは自動的に更新されます。 - リンクテキストを、自動生成されるテキストと同じもので「上書き」してはいけません。 @@ -244,8 +244,8 @@ URL をテキストとして表示し、リンクされないようにするに ##### 自動生成アンカーの使用 -MyST構文を使用する場合、リンク先が同じファイル内のセクションを指している場合でも、必ずファイル名を指定する必要があります。 -Markdownの構文を使用している場合、同じファイル内でリンクするときはファイル名を省略することができます。 +自動生成されたアンカーを使用するには、Markdownの構文を使用する必要があります。 +同じファイル内でリンクする場合は、ファイル名を省略できます。 ``{list-table}. :header-rows: 1 @@ -254,10 +254,6 @@ Markdownの構文を使用している場合、同じファイル内でリンク - 出力 - GitHubでの出力 - 説明 -* - `` {ref}`doc-cheat-sheet.md#referencing-a-section` `` - - {ref}`doc-cheat-sheet.md#referencing-a-section` - - \{ref\}`doc-heat-sheet.md#referencing-a-section` - - 自動生成されたアンカーを参照します。 * - `[](#referencing-a-section)` - [](#referencing-a-section) - @@ -266,10 +262,6 @@ Markdownの構文を使用している場合、同じファイル内でリンク - [リンクテキスト](#referencing-a-section) - [リンクテキスト](#referencing-a-section) - リンクテキストをオーバーライドする場合に好ましい。 -* - `` {ref}`リンクテキスト ` `` - - {ref}`リンクテキスト ` - - \{ref\}`リンクテキスト ` - - リンクテキストを上書きする場合の代替手段です。 ``` ## ナビゲーション diff --git a/doc/explanation/clustering.md b/doc/explanation/clustering.md index 6272f45..8c9bf30 100644 --- a/doc/explanation/clustering.md +++ b/doc/explanation/clustering.md @@ -1,5 +1,5 @@ --- -discourse: 15871 +discourse: 15728 --- (exp-clustering)= @@ -12,7 +12,7 @@ discourse: 15871 このシナリオでは、クラスタメンバーとそのインスタンスの設定を保持する同じ分散データベースを任意の台数の LXD サーバで共有します。 LXD クラスタは `lxc` クライアントまたは REST API を使って管理できます。 -この機能は [`clustering`](api-extensions.md#clustering) API 拡張の一部として導入され、 LXD 3.0 以降で利用可能です。 +この機能は [`clustering`](../api-extensions.md#clustering) API 拡張の一部として導入され、 LXD 3.0 以降で利用可能です。 ```{tip} ベーシックなLXDクラスタを素早くセットアップしたい場合、[MicroCloud](https://discuss.linuxcontainers.org/t/introducing-microcloud/15871)をチェックしてみてください。 @@ -161,19 +161,19 @@ LXD のクラスタではクラスタグループにメンバーを追加でき ### インスタンス配置スクリプトレット LXDでは埋め込まれたスクリプト(スクリプトレット)を使って自動的なインスタンス配置を制御するカスタムロジックを使用できます。 -これにより組み込みのインスタンス配置機能に比べてより柔軟に制御できます。 +この方法は、組み込みのインスタンス配置機能よりも柔軟性が高いです。 インスタンス配置スクリプトレットは[Starlark言語](https://github.com/bazelbuild/starlark) (Pythonのサブセット)で記述する必要があります。 -スクリプトレットはLXDがインスタンスをどこに配置するか知る必要がある際に毎回実行されます。 -スクリプトレットには配置されるインスタンスについての情報がインスタンスをホスト可能なクラスタメンバ候補の情報とともに渡されます。 +スクリプトレットは、LXDがインスタンスをどこに配置するかを知る必要があるたびに呼び出されます。 +スクリプトレットは、配置されるインスタンスに関する情報と、インスタンスをホストできる候補のクラスターメンバーに関する情報を受け取ります。 スクリプトレットからクラスタメンバ候補の状態と利用可能なハードウェアリソースについての情報を要求することもできます。 インスタンス配置スクリプトレットは`instance_placement`関数を以下のシグネチャで実装する必要があります。 `instance_placement(request, candidate_members)`: -- `request`は[`scriptlet.InstancePlacement`](https://pkg.go.dev/github.com/lxc/lxd/shared/api/scriptlet/#InstancePlacement)の展開された表現を含むオブジェクトです。これは`project`と`reason`フィールドを含みます。`reason`は`new`, `evacuation`, `relocation`のいずれかです。 -- `candidate_members`は[`api.ClusterMember`](https://pkg.go.dev/github.com/lxc/lxd/shared/api#ClusterMember)エントリを表すクラスタメンバオブジェクトの`list`です。 +- `request`は、[`scriptlet.InstancePlacement`](https://pkg.go.dev/github.com/lxc/lxd/shared/api/scriptlet/#InstancePlacement) の展開された表現を含むオブジェクトです。このリクエストには、`project`および`reason`フィールドが含まれています。`reason`は、`new`、`evacuation`、または`relocation`のいずれかです。 +- `candidate_members`は、[`api.ClusterMember`](https://pkg.go.dev/github.com/lxc/lxd/shared/api#ClusterMember) エントリを表すクラスターメンバーオブジェクトの`list`です。 例: @@ -187,7 +187,7 @@ def instance_placement(request, candidate_members): # エラーログ出力の例。これはLXDのログに出力されます。 log_error("Invalid name supplied: ", request.name) - return "Invalid name" # インスタンス配置を拒否するエラーを返す。 + fail("Invalid name") # エラーで終了してインスタンス配置を拒否します。 # 提供された第1候補のサーバにインスタンスを配置する。 set_target(candidate_members[0].server_name) @@ -205,9 +205,9 @@ LXDに現在適用されているスクリプトレットを見るには`lxc con スクリプトレットでは(Starlarkで提供される関数に加えて)以下の関数が利用できます。 -- `log_info(*messages)`: infoレベルでLXDのログにログエントリを追加します。`messages`は1つ以上のメッセージの引数です。 -- `log_warn(*messages)`: warnレベルでLXDのログにログエントリを追加します。`messages`は1つ以上のメッセージの引数です。 -- `log_error(*messages)`: errorレベルでLXDのログにログエントリを追加します。`messages`は1つ以上のメッセージの引数です。 +- `log_info(*messages)`: `info`レベルでLXDのログにログエントリを追加します。`messages`は1つ以上のメッセージの引数です。 +- `log_warn(*messages)`: `warn`レベルでLXDのログにログエントリを追加します。`messages`は1つ以上のメッセージの引数です。 +- `log_error(*messages)`: `error`レベルでLXDのログにログエントリを追加します。`messages`は1つ以上のメッセージの引数です。 - `set_cluster_member_target(member_name)`: インスタンスが作成されるべきクラスタメンバを設定します。`member_name`はインスタンスが作成されるべきクラスタメンバーの名前です。この関数が呼ばれなければ、LXDは組み込みのインスタンス配置ロジックを使用します。 - `get_cluster_member_state(member_name)`: クラスタメンバーの状態を取得します。[`api.ClusterMemberState`](https://pkg.go.dev/github.com/lxc/lxd/shared/api#ClusterMemberState)の形式でクラスタメンバーの状態を含むオブジェクトを返します。`member_name`は状態を取得する対象のクラスタメンバーの名前です。 - `get_cluster_member_resources(member_name)`: クラスタメンバーのリソースについての情報を取得します。[`api.Resources`](https://pkg.go.dev/github.com/lxc/lxd/shared/api#Resources)の形式でリソースについての情報を含むオブジェクトを返します。`member_name`はリソース情報を取得する対象のクラスタメンバーの名前です。 diff --git a/doc/faq.md b/doc/faq.md index 3b82a26..3400404 100644 --- a/doc/faq.md +++ b/doc/faq.md @@ -18,7 +18,7 @@ lxc config show ```bash ip addr -lxc config set core.https_address 192.168.1.15 +lxc config set core.https_address 192.0.2.1 ``` {ref}`security_remote_access` も参照してください。 @@ -34,7 +34,7 @@ lxc config set core.trust_password SECRET これでリモートパスワードが設定されるので、 `lxc remote add` 実行時にこのパスワードを使用できます。 -あるいはクライアント証明書を `.config/lxc/client.crt` からサーバにコピーして以下のコマンドで追加すれば、パスワードを設定しなくてもサーバにアクセスできます。 +あるいはクライアント証明書を `.config/lxc/client.crt` (`~/.config/lxc/client.crt` またはSnapユーザーの場合は `~/snap/lxd/common/config/client.crt`) からサーバにコピーして以下のコマンドで追加すれば、パスワードを設定しなくてもサーバにアクセスできます。 ```bash lxc config trust add client.crt @@ -80,58 +80,16 @@ lxc config set linux.kernel_modules コンテナ内に `/.dockerenv` ファイルを作成するとネストした環境内で実行しているために発生するエラーを Docker が無視するようにできるという報告もあります。 -## コンテナの起動に関する問題 +### `lxc`はどこに設定を保存していますか？ -もしコンテナが起動しない場合や、期待通りの動きをしない場合に最初にすべきことは、コンテナが生成したコンソールログを見ることです。 -これには `lxc console --show-log CONTAINERNAME` コマンドを使います。 +`lxc`コマンドは、設定を`~/.config/lxc`に保存します。Snapユーザーの場合は、`~/snap/lxd/common/config`に保存されます。 -次の例では、`systemd` が起動しない RHEL 7 システムを調べています。 +そのディレクトリにはさまざまな設定ファイルが格納されており、その中には以下のものがあります： - # lxc console --show-log systemd - Console log: - - Failed to insert module 'autofs4' - Failed to insert module 'unix' - Failed to mount sysfs at /sys: Operation not permitted - Failed to mount proc at /proc: Operation not permitted - [!!!!!!] Failed to mount API filesystems, freezing. - -ここでのエラーは、`/sys` と `/proc` がマウントできないというエラーです。これは非特権コンテナでは正しい動きです。 -しかし、LXD は可能であれば自動的にこれらのファイルシステムをマウントします。 - -[コンテナの要件](container-environment.md) では、コンテナには`/sbin/init`が存在するだけでなく、空の`/dev`、`/proc`、`/sys`ディレクトリが存在していなければならないと定められています。 -もしこれらのディレクトリが存在しなければ、LXD はこれらをマウントできません。そして、`systemd`がこれらをマウントしようとします。 -非特権コンテナでは、`systemd`はこれを行う権限はなく、フリーズしてしまいます。 - -何かが変更される前に環境を見ることはできます。`raw.lxc` 設定パラメーターを使って、明示的にコンテナ内の init システムを変更できます。 -これは Linux カーネルコマンドラインに `init=/bin/bash` を設定するのと同じです。 - - lxc config set systemd raw.lxc 'lxc.init.cmd = /bin/bash' - -次のようになります: - - root@lxc-01:~# lxc config set systemd raw.lxc 'lxc.init.cmd = /bin/bash' - root@lxc-01:~# lxc start systemd - root@lxc-01:~# lxc console --show-log systemd - - Console log: - - [root@systemd /]# - root@lxc-01:~# - -コンテナが起動しましたので、期待通りにコンテナ内で動いていないことを確認できます。 - - root@lxc-01:~# lxc exec systemd bash - [root@systemd ~]# ls - [root@systemd ~]# mount - mount: failed to read mtab: No such file or directory - [root@systemd ~]# cd / - [root@systemd /]# ls /proc/ - sys - [root@systemd /]# exit - -LXD は自動修復を試みますので、起動時に作成されたディレクトリもあります。コンテナをシャットダウンして再起動すると問題は解決されます。 -しかし問題の根源は依然として存在しています。**テンプレートに必要なファイルが含まれていないという問題です**。 +- `client.crt`：クライアント証明書（オンデマンドで生成） +- `client.key`：クライアントキー（オンデマンドで生成） +- `config.yml`：設定ファイル（`remotes`、`aliases`などの情報） +- `servercerts/`：`remotes`に属するサーバー証明書が格納されているディレクトリ ## ネットワークの問題 diff --git a/doc/howto/benchmark_performance.md b/doc/howto/benchmark_performance.md index 0e0f30c..dfd47a3 100644 --- a/doc/howto/benchmark_performance.md +++ b/doc/howto/benchmark_performance.md @@ -96,7 +96,7 @@ snap をご利用の場合、ベンチマークツールは自動でインスト 作成したベンチマーク用のコンテナを削除するには、以下のコマンドを実行します。 - lxd.benchmark --delete + lxd.benchmark delete ```{note} 新しいベンチマークを実行する前には既存のベンチマーク用コンテナを全て削除する必要があります。 diff --git a/doc/howto/cluster_form.md b/doc/howto/cluster_form.md index 7b8aaca..8a955c8 100644 --- a/doc/howto/cluster_form.md +++ b/doc/howto/cluster_form.md @@ -44,7 +44,9 @@ LXD クラスタを形成するために初期化プロセス中に設定をイ
ブートストラップ上での lxd init の完全な例を見るには展開してください -``` +```{terminal} +:input: lxd init + Would you like to use LXD clustering? (yes/no) [default=no]: yes What IP address or DNS name should be used to reach this server? [default=192.0.2.101]: Are you joining an existing cluster? (yes/no) [default=no]: no @@ -140,7 +142,9 @@ Would you like a YAML "lxd init" preseed to be printed? (yes/no) [default=no]: ````{group-tab} 認証トークン (推奨) -``` +```{terminal} +:input: sudo lxd init + Would you like to use LXD clustering? (yes/no) [default=no]: yes What IP address or DNS name should be used to reach this server? [default=192.0.2.102]: Are you joining an existing cluster? (yes/no) [default=no]: yes @@ -156,7 +160,9 @@ Would you like a YAML "lxd init" preseed to be printed? (yes/no) [default=no]: ```` ````{group-tab} トラストパスワード -``` +```{terminal} +:input: sudo lxd init + Would you like to use LXD clustering? (yes/no) [default=no]: yes What IP address or DNS name should be used to reach this server? [default=192.0.2.102]: Are you joining an existing cluster? (yes/no) [default=no]: yes diff --git a/doc/howto/cluster_manage.md b/doc/howto/cluster_manage.md index e94e4a0..119ee75 100644 --- a/doc/howto/cluster_manage.md +++ b/doc/howto/cluster_manage.md @@ -7,7 +7,10 @@ discourse: 11330 クラスタを形成した後、メンバーの一覧と状態を見るには `lxc cluster list` を使用します。 -``` +```{terminal} +:input: lxc cluster list +:scroll: + +---------+----------------------------+------------------+--------------+----------------+-------------+--------+-------------------+ | NAME | URL | ROLES | ARCHITECTURE | FAILURE DOMAIN | DESCRIPTION | STATE | MESSAGE | +---------+----------------------------+------------------+--------------+----------------+-------------+--------+-------------------+ diff --git a/doc/howto/import_machines_to_instances.md b/doc/howto/import_machines_to_instances.md index 041f88a..25134ae 100644 --- a/doc/howto/import_machines_to_instances.md +++ b/doc/howto/import_machines_to_instances.md @@ -61,7 +61,9 @@ LXD は既存のディスクやイメージに基づく LXD インスタンス
展開して出力の例を見る - ``` + ```{terminal} + :input: ./bin.linux.lxd-migrate + Please provide LXD server URL: https://192.0.2.7:8443 Certificate fingerprint: xxxxxxxxxxxxxxxxx ok (y/n)? y diff --git a/doc/howto/initialize.md b/doc/howto/initialize.md index a958822..8994036 100644 --- a/doc/howto/initialize.md +++ b/doc/howto/initialize.md @@ -89,7 +89,7 @@ YAML `lxd init` プリシード ({ref}`initialize-preseed`参照) ```bash cat < --show-log + + コンソールログ + : コンソールログを表示するには、次のコマンドを入力します： + + lxc console --show-log + + 詳細なサーバ情報 + : LXDのsnapパッケージには、デバッグ用の関連サーバー情報を収集するツールが含まれています。 + それを実行するには、次のコマンドを入力します： + + sudo lxd.buginfo + +1. LXDサーバーを実行しているマシンを再起動します。 +1. インスタンスをもう一度起動してみてください。 + エラーが再発した場合は、ログを比較して同じエラーかどうか確認します。 + + 同じエラーであり、ログ情報からエラーの原因を特定できない場合は、[フォーラム](https://discuss.linuxcontainers.org)で質問を投稿してください。 + 収集したログファイルを含めるようにしてください。 + +## トラブルシューティングの例 + +この例では、systemdが起動できないRHEL 7システムを調査しましょう。 + +```{terminal} +:input: lxc console --show-log systemd + +Console log: + +Failed to insert module 'autofs4' +Failed to insert module 'unix' +Failed to mount sysfs at /sys: Operation not permitted +Failed to mount proc at /proc: Operation not permitted +[!!!!!!] Failed to mount API filesystems, freezing. +``` + +ここでのエラーは、 /sys と /proc がマウントできないと言っています - これは、非特権コンテナでは正しいです。 +しかし、LXDは可能であればこれらのファイルシステムを自動的にマウントします。 + +{doc}`コンテナの要件 <../container-environment>`では、すべてのコンテナには空の `/dev`、`/proc`、`/sys` ディレクトリが必要であり、`/sbin/init` が存在していなければなりません。 +これらのディレクトリが存在しない場合、LXDはそれらをマウントできず、`systemd`がその後それを試みます。 +これは非特権コンテナなので、`systemd`はこれを行う能力がなく、コンテナはフリーズします。 + +したがって、何も変更される前の環境を確認でき、`raw.lxc` 設定パラメータを使用してコンテナ内の`init`システムを明示的に変更できます。 +これは、Linuxカーネルのコマンドラインで `init=/bin/bash` を設定するのと同等です。 + + lxc config set systemd raw.lxc 'lxc.init.cmd = /bin/bash' + +これがどのように見えるかを示します： + +```{terminal} +:input: lxc config set systemd raw.lxc 'lxc.init.cmd = /bin/bash' + +:input: lxc start systemd +:input: lxc console --show-log systemd + +Console log: + +[root@systemd /]# +``` + +これでコンテナが起動したので、確認して期待通りにうまく動作していないことがわかります： + +```{terminal} +:input: lxc exec systemd bash + +[root@systemd ~]# ls +[root@systemd ~]# mount +mount: failed to read mtab: No such file or directory +[root@systemd ~]# cd / +[root@systemd /]# ls /proc/ +sys +[root@systemd /]# exit +``` + +LXDは自動的に回復しようとするため、起動時にいくつかのディレクトリが作成されました。 +コンテナをシャットダウンして再起動すると問題が解決しますが、元の原因はまだ残っています - テンプレートには必要なファイルが含まれていません。 diff --git a/doc/howto/migrate_from_lxc.md b/doc/howto/migrate_from_lxc.md index 2b2346b..0a25346 100644 --- a/doc/howto/migrate_from_lxc.md +++ b/doc/howto/migrate_from_lxc.md @@ -72,7 +72,9 @@ LXD にインスタンス名としてすでに存在する名前を持つコン このツールは LXC の設定と (1つまたは複数の) コンテナの設定を分析し、可能な限りの範囲で設定をマイグレートします。 以下のような実行結果が出力されます。 -```bash +```{terminal} +:input: sudo lxd.lxc-to-lxd --containers lxc1 + Parsing LXC configuration Checking for unsupported LXC configuration keys Checking for existing containers diff --git a/doc/howto/network_acls.md b/doc/howto/network_acls.md index 6bd16b2..472a96a 100644 --- a/doc/howto/network_acls.md +++ b/doc/howto/network_acls.md @@ -220,5 +220,5 @@ lxc config device set security.acls.default.ingres - OVN ACL とは違い、ブリッジ ACL はブリッジと LXD ホストの間の境界のみに適用されます。これは外部へと外部からのトラフィックにネットワークポリシーを適用するために使うことしかできないことを意味します。ブリッジ間のファイアウォール、つまり同じブリッジに接続されたインスタンス間のトラフィックを制御するファイアウォールには使えません。 - {ref}`ACL グループとネットワークセレクタ ` はサポートされません。 -- `iptables` ファイアウォールドライバを使う際は、 IP レンジサブジェクト（例：`192.168.1.1-192.168.1.10`）は使用できません。 +- `iptables` ファイアウォールドライバを使う際は、 IP レンジサブジェクト（例：`192.0.2.1-192.0.2.10`）は使用できません。 - ベースラインのネットワークサービスルールが（対応する INPUT/OUTPUT チェイン内の） ACL ルールの前に適用されます。これは一旦 ACL チェインに入ってしまうと INPUT/OUTPUT と FORWARD トラフィックを区別できないからです。このため ACL ルールはベースラインのサービスルールをブロックするのには使えません。 diff --git a/doc/howto/network_bridge_resolved.md b/doc/howto/network_bridge_resolved.md index 6aa212d..358938e 100644 --- a/doc/howto/network_bridge_resolved.md +++ b/doc/howto/network_bridge_resolved.md @@ -97,7 +97,9 @@ WantedBy=sys-subsystem-net-devices-.device 以下のような出力になるはずです。 -``` +```{terminal} +:input: sudo systemctl status lxd-dns-lxdbr0.service + ● lxd-dns-lxdbr0.service - LXD per-link DNS configuration for lxdbr0 Loaded: loaded (/etc/systemd/system/lxd-dns-lxdbr0.service; enabled; vendor preset: enabled) Active: inactive (dead) since Mon 2021-06-14 17:03:12 BST; 1min 2s ago @@ -108,7 +110,9 @@ WantedBy=sys-subsystem-net-devices-.device `resolved` に設定が反映されたか確認するには、 `resolvectl status ` を実行します。 -``` +```{terminal} +:input: resolvectl status lxdbr0 + Link 6 (lxdbr0) Current Scopes: DNS DefaultRoute setting: no diff --git a/doc/howto/network_create.md b/doc/howto/network_create.md index 8856391..951cbea 100644 --- a/doc/howto/network_create.md +++ b/doc/howto/network_create.md @@ -56,13 +56,20 @@ LXD クラスタを実行していてネットワークを作成したい場合 例えば、以下の一連のコマンドで 3 つのクラスタメンバ上に `UPLINK` という名前の物理ネットワークをセットアップします。 -```bash -lxc network create UPLINK --type=physical parent=br0 --target=vm01 -lxc network create UPLINK --type=physical parent=br0 --target=vm02 -lxc network create UPLINK --type=physical parent=br0 --target=vm03 -lxc network create UPLINK --type=physical +```{terminal} +:input: lxc network create UPLINK --type=physical parent=br0 --target=vm01 + +Network UPLINK pending on member vm01 +:input: lxc network create UPLINK --type=physical parent=br0 --target=vm02 +Network UPLINK pending on member vm02 +:input: lxc network create UPLINK --type=physical parent=br0 --target=vm03 +Network UPLINK pending on member vm03 +:input: lxc network create UPLINK --type=physical +Network UPLINK created ``` +{ref}`cluster-config-networks`も参照してください。 + (network-attach)= ## インスタンスにネットワークをアタッチする diff --git a/doc/howto/network_ovn_setup.md b/doc/howto/network_ovn_setup.md index c7994ed..9d53626 100644 --- a/doc/howto/network_ovn_setup.md +++ b/doc/howto/network_ovn_setup.md @@ -31,7 +31,10 @@ 1. `lxc list` を実行してインスタンスの情報を表示します。 - ``` + ```{terminal} + :input: lxc list + :scroll: + +------+---------+---------------------+----------------------------------------------+-----------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +------+---------+---------------------+----------------------------------------------+-----------+-----------+ diff --git a/doc/howto/network_zones.md b/doc/howto/network_zones.md index de18d51..7d19280 100644 --- a/doc/howto/network_zones.md +++ b/doc/howto/network_zones.md @@ -52,9 +52,11 @@ LXD は全てのインスタンス、ネットワークゲートウェイ、ダ - ゾーンに手動で追加されたレコード ゾーン設定に対して生成されたレコードは `dig` コマンドで確認できます。 -例えば、 `dig @ -p 1053 axfr lxd.example.net` と実行すると以下のように出力されます。 +これは`core.dns_address`が`:`に設定されていることを前提としています。 +例えば、`dig @ -p axfr lxd.example.net`と実行すると以下のような出力がでるかもしれません。 -```bash +```{terminal} +:input: dig @192.0.2.200 -p 1053 axfr lxd.example.net lxd.example.net. 3600 IN SOA lxd.example.net. ns1.lxd.example.net. 1669736788 120 60 86400 30 lxd.example.net. 300 IN NS ns1.lxd.example.net. lxdtest.gw.lxd.example.net. 300 IN A 192.0.2.1 @@ -71,9 +73,11 @@ lxd.example.net. 3600 IN SOA lxd.example.net. ns1.lxd.ex `192.0.2.0/24` を使用するネットワークに `2.0.192.in-addr.arpa` の IPv4 逆引き DNS レコードのゾーンを設定すると、正引きゾーンの1つを経由してネットワークを参照する全てのプロジェクトからのアドレスの逆引き `PTR` DNSレコードを生成します。 -例えば `dig @ -p 1053 axfr 2.0.192.in-addr.arpa`　を実行すると以下のような出力が得られるかもしれません。 +例えば `dig @ -p axfr 2.0.192.in-addr.arpa` を実行すると以下のような出力が得られるかもしれません。 + +```{terminal} +:input: dig @192.0.2.200 -p 1053 axfr 2.0.192.in-addr.arpa -```bash 2.0.192.in-addr.arpa. 3600 IN SOA 2.0.192.in-addr.arpa. ns1.2.0.192.in-addr.arpa. 1669736828 120 60 86400 30 2.0.192.in-addr.arpa. 300 IN NS ns1.2.0.192.in-addr.arpa. 1.2.0.192.in-addr.arpa. 300 IN PTR lxdtest.gw.lxd.example.net. @@ -87,7 +91,7 @@ lxd.example.net. 3600 IN SOA lxd.example.net. ns1.lxd.ex ネットワークゾーンを使用するには、組み込みの DNS サーバを有効にする必要があります。 そのためには、 LXD サーバのローカルアドレスに `core.dns_address` 設定オプション({ref}`server-options-core`参照)を設定してください。 - +既存のDNSとの衝突を避けるためポート53を使用しないことをお勧めします。 これは DNS サーバがリッスンするアドレスです。 LXD クラスタの場合、アドレスは各クラスタメンバーによって異なるかもしれないことに注意してください。 diff --git a/doc/howto/storage_pools.md b/doc/howto/storage_pools.md index 7cb7e10..2c00f6d 100644 --- a/doc/howto/storage_pools.md +++ b/doc/howto/storage_pools.md @@ -161,11 +161,19 @@ LXD クラスターを稼働していてストレージプールを追加した 例えば、以下の一連のコマンドは 3 つのクラスターメンバー上で異なるロケーションと異なるサイズで `my-pool` という名前のストレージプールをセットアップします。 - lxc storage create my-pool zfs source=/dev/sdX size=10GB --target=vm01 - lxc storage create my-pool zfs source=/dev/sdX size=15GB --target=vm02 - lxc storage create my-pool zfs source=/dev/sdY size=10GB --target=vm03 - lxc storage create my-pool zfs +```{terminal} +:input: lxc storage create my-pool zfs source=/dev/sdX size=10GB --target=vm01 + +Storage pool my-pool pending on member vm01 +:input: lxc storage create my-pool zfs source=/dev/sdX size=15GB --target=vm02 +Storage pool my-pool pending on member vm02 +:input: lxc storage create my-pool zfs source=/dev/sdY size=10GB --target=vm03 +Storage pool my-pool pending on member vm03 +:input: lxc storage create my-pool zfs +Storage pool my-pool created +``` +{ref}`cluster-config-storage`も参照してください。 ```{note} ほとんどのストレージドライバでは、ストレージプールは各クラスターメンバー上にローカルに存在します。 diff --git a/doc/installing.md b/doc/installing.md index dd32c06..1709ce2 100644 --- a/doc/installing.md +++ b/doc/installing.md @@ -1,5 +1,5 @@ --- -discourse: 8178 +discourse: 8178, 16551 relatedlinks: "[LXD のインストール](https://linuxcontainers.org/ja/lxd/getting-started-cli/)" --- @@ -69,15 +69,19 @@ cd lxd-4.18 ビルドには最低 2GB の RAM を搭載することを推奨します。 -```bash -make deps -# `make deps` が出力した export のコマンド列を使って環境変数を設定してください。 -# 例: +```{terminal} +:input: make deps + +... +make[1]: Leaving directory '/root/go/deps/dqlite' +# environment + +Please set the following in your environment (possibly ~/.bashrc) # export CGO_CFLAGS="${CGO_CFLAGS} -I$(go env GOPATH)/deps/dqlite/include/ -I$(go env GOPATH)/deps/raft/include/" # export CGO_LDFLAGS="${CGO_LDFLAGS} -L$(go env GOPATH)/deps/dqlite/.libs/ -L$(go env GOPATH)/deps/raft/.libs/" # export LD_LIBRARY_PATH="$(go env GOPATH)/deps/dqlite/.libs/:$(go env GOPATH)/deps/raft/.libs/:${LD_LIBRARY_PATH}" # export CGO_LDFLAGS_ALLOW="(-Wl,-wrap,pthread_create)|(-Wl,-z,now)" -make +:input: make ``` ### ソースからのビルド結果のインストール diff --git a/doc/instances.md b/doc/instances.md index 2515965..a8275e5 100644 --- a/doc/instances.md +++ b/doc/instances.md @@ -14,5 +14,6 @@ cloud-initの使用 コマンドの実行 コンソールへのアクセス ファイルへのアクセス +エラーのトラブルシューティング explanation/instance_config.md ``` diff --git a/doc/metrics.md b/doc/metrics.md index e70e4ad..c9da25d 100644 --- a/doc/metrics.md +++ b/doc/metrics.md @@ -91,8 +91,8 @@ scrape_configs: 上の例では `/etc/prometheus/tls/server.crt` は以下のような内容になっています。 -``` -$ openssl x509 -noout -text -in /etc/prometheus/tls/server.crt +```{terminal} +:input: openssl x509 -noout -text -in /etc/prometheus/tls/server.crt ... X509v3 Subject Alternative Name: DNS:foo, IP Address:127.0.0.1, IP Address:0:0:0:0:0:0:0:1 diff --git a/doc/projects.md b/doc/projects.md index 0a66241..dddbf65 100644 --- a/doc/projects.md +++ b/doc/projects.md @@ -1,5 +1,5 @@ --- -relatedlinks: https://www.youtube.com/watch?v=6O0q3rSWr8A +relatedlinks: https://www.youtube.com/watch?v=6O0q3rSWr8A, https://ubuntu.com/tutorials/introduction-to-lxd-projects --- (projects)= diff --git a/doc/reference/devices_disk.md b/doc/reference/devices_disk.md index 613c14e..eb9ef8d 100644 --- a/doc/reference/devices_disk.md +++ b/doc/reference/devices_disk.md @@ -1,37 +1,70 @@ (devices-disk)= # タイプ: `disk` +```{youtube} https://www.youtube.com/watch?v=JhRw2OYTgtg +``` + ```{note} `disk` デバイスタイプはコンテナとVMの両方でサポートされます。 コンテナとVMの両方でホットプラグをサポートします。 ``` ディスクデバイスはインスタンスに追加のストレージを提供します。 + コンテナにとっては、それらはインスタンス内の実質的なマウントポイントです (ホスト上の既存のファイルまたはディレクトリのバインドマウントとしてか、あるいは、ソースがブロックデバイスの場合は通常のマウントのマウントポイント)。 仮想マシンは `9p` または `virtiofs` (使用可能な場合) を通してホスト側のマウントまたはディレクトリを共有するか、あるいはブロックベースのディスクに対する VirtIO ディスクとして共有します。 -ディスクデバイスは {ref}`ストレージボリュームをインスタンスにアタッチする ` ことでも作成できます。 -LXD では以下の追加のソースタイプをサポートします。 +(devices-disk-types)= +## ディスクデバイスの種類 + +さまざまなソースからディスクデバイスを作成できます。 +`source` オプションに指定する値によって、追加されるディスクデバイスのタイプが決まります: + +ストレージボリューム +: 最も一般的なタイプのディスクデバイスはストレージボリュームです。 + ストレージボリュームを追加するには、デバイスの`source`としてその名前を指定します： + + lxc config device add disk pool= source= [path=] + + pathはファイルシステムボリュームには必要ですが、ブロックボリュームには必要ありません。 + + また、`lxc storage volume attach`コマンドを使用して{ref}`storage-attach-volume`することもできます。 + どちらのコマンドも、ストレージボリュームをディスクデバイスとして追加するための同じメカニズムを使用します。 + +ホスト上のパス +: ホストのパス（ファイルシステムまたはブロックデバイスのいずれか）をインスタンスと共有するには、ディスクデバイスとして追加し、`source`としてホストパスを指定します： + + lxc config device add disk source= [path=] + + pathはファイルシステムボリュームには必要ですが、ブロックデバイスには必要ありません。 Ceph RBD -: 外部で管理されている既存の Ceph RBD デバイスをマウントします。 +: LXDは、インスタンスの内部ファイルシステムを管理するためにCephを使用できますが、既存の外部管理Ceph RBDをインスタンスに使用したい場合は、次のコマンドで追加できます： - LXD は Ceph をインスタンスの内部のファイルシステムを管理するのに使用できますが、ユーザーが既存の Ceph RBD を持っておりそれをインスタンスに使いたい場合は以下のコマンドを使用できます。 + lxc config device add disk source=ceph:/ ceph.user_name= ceph.cluster_name= [path=] - lxc config device add disk source=ceph:/ ceph.user_name= ceph.cluster_name= path= + pathはファイルシステムボリュームには必要ですが、ブロックデバイスには必要ありません。 CephFS -: 外部で管理されている既存の Ceph FS をマウントします。 - - LXD は Ceph をインスタンスの内部のファイルシステムを管理するのに使用できますが、ユーザーが既存の Ceph ファイルシステムを持っておりそれをインスタンスに使いたい場合は以下のコマンドを使用できます。 +: LXDはインスタンスで内部のファイルシステムの管理にCephを使えますが、既存の外部で管理されているCephファイルシステムをインスタンスで使用したい場合は、以下のコマンドで追加できます。 lxc config device add disk source=cephfs:/ ceph.user_name= ceph.cluster_name= path= +ISO file +: 仮想マシンにはISOファイルをディスクデバイスとして追加できます。 + ISOファイルはVM内部のROMデバイスとして追加されます。 + + このソースタイプはVMでのみ利用可能です。 + + ISOファイルを追加するには、そのファイルパスを`source`として指定します。 + + lxc config device add disk source= + VM cloud-init -: `cloud-init.vendor-data`、`cloud-init.user-data`、`user.meta-data`設定キー({ref}`instance-options`参照)から`cloud-init`設定の ISO イメージを生成し、起動時にVMがドライブを検出し設定を適用します。 +: `cloud-init.vendor-data`、`cloud-init.user-data`設定キー({ref}`instance-options`参照)から`cloud-init`設定のISO イメージを生成し、仮想マシンにアタッチできます。 - このソースタイプは仮想マシンのインスタンスでのみ利用可能です。 + このソースタイプはVMでのみ利用可能です。 そのようなデバイスを追加するには、以下のコマンドを使用します。 @@ -46,6 +79,7 @@ VM cloud-init `boot.priority` | integer | - | no | VM のブート優先度 (高いほうが先にブート) `ceph.cluster_name` | string | `ceph` | no | Ceph クラスタのクラスタ名 (Ceph か CephFS のソースには必須) `ceph.user_name` | string | `admin` | no | Ceph クラスタのユーザ名 (Ceph か CephFS のソースには必須) +`io.cache` | string | `none` | no | VMのみ: デバイスのキャッシュモードを上書きする (`none`, `writeback`または`unsafe`) `limits.max` | string | - | no | 読み取りと書き込み両方のbyte/sかIOPSによるI/O制限 (`limits.read`と`limits.write`の両方を設定するのと同じ) `limits.read` | string | - | no | byte/s(さまざまな単位が使用可能、{ref}`instances-limit-units`参照)もしくはIOPS(あとに`iops`と付けなければなりません)で指定する読み込みのI/O制限値 - {ref}`storage-configure-IO` も参照 `limits.write` | string | - | no | byte/s(さまざまな単位が使用可能、{ref}`instances-limit-units`参照)もしくはIOPS(あとに`iops`と付けなければなりません)で指定する書き込みのI/O制限値 - {ref}`storage-configure-IO` も参照 @@ -59,4 +93,4 @@ VM cloud-init `shift` | bool | `false` | no | ソースの UID/GID をインスタンスにマッチするように変換させるためにオーバーレイの shift を設定するか(コンテナのみ) `size` | string | - | no | byte(さまざまな単位が使用可能、 {ref}`instances-limit-units` 参照)で指定するディスクサイズ。`rootfs` (`/`) でのみサポートされます `size.state` | string | - | no | 上の `size` と同じですが、仮想マシン内のランタイム状態を保存するために使われるファイルシステムボリュームに適用されます -`source` | string | - | yes | ファイル・ディレクトリ、もしくはブロックデバイスのホスト上のパス +`source` | string | - | yes | ファイルシステムまたはブロックデバイスのソース(詳細は{ref}`devices-disk-types`参照) diff --git a/doc/reference/devices_nic.md b/doc/reference/devices_nic.md index a765daa..d27e8be 100644 --- a/doc/reference/devices_nic.md +++ b/doc/reference/devices_nic.md @@ -43,6 +43,8 @@ LXDはさまざまな異なるタイプのネットワークデバイス(*NICタ - [`bridged`](nic-bridged): ホスト上に存在する既存のブリッジを使い、ホストのブリッジをインスタンスに接続する仮想デバイスペアを作成します。 - [`macvlan`](nic-macvlan): 既存のネットワークデバイスをベースにMACアドレスが異なる新しいネットワークデバイスを作成します。 - [`sriov`](nic-sriov): SR-IOVが有効な物理ネットワークデバイスの仮想ファンクション(virtual function)をインスタンスにパススルーします。 +- [`physical`](nic-physical): ホストの物理デバイスをインスタンスにパススルーします。 + 対象のデバイスはホスト上では見えなくなり、インスタンス内に出現します。 次のNICは`network`オプションでのみ追加できます。 @@ -50,8 +52,6 @@ LXDはさまざまな異なるタイプのネットワークデバイス(*NICタ 次のNICは`nictype`オプションでのみ追加できます。 -- [`physical`](nic-physical): ホストの物理デバイスをインスタンスにパススルーします。 - 対象のデバイスはホスト上では見えなくなり、インスタンス内に出現します。 - [`ipvlan`](nic-ipvlan): 既存のネットワークデバイスをベースにMACアドレスは同じですがIPアドレスが異なる新しいネットワークデバイスを作成します。 - [`p2p`](nic-p2p): 仮想デバイスペアを作成し、片方をインスタンス内に置き、残りの片方をホスト上に残します。 - [`routed`](nic-routed): 仮想デバイスペアを作成し、ホストからインスタンスに繋いで静的ルートとプロキシARP/NDPエントリーを作成します。これにより指定された親インタフェースのネットワークにインスタンスが参加できるようになります。 @@ -238,8 +238,7 @@ SR-IOVハードウェアアクセラレーション ### `nictype`: `physical` ```{note} -- このNICタイプは`nictype`オプションでのみ選択できます。 -([`physical`ネットワークタイプ](network-physical)は{ref}`network-ovn`のアップリンクネットワークを提供するためにのみ使用できます。) +- このNICタイプは`nictype`オプションまたは`network`オプションで選択できます。 - それぞれの親デバイスに対して`physical` NIC は1つだけ持つことができます。 ``` diff --git a/doc/reference/devices_tpm.md b/doc/reference/devices_tpm.md index 1ae1610..6d89e41 100644 --- a/doc/reference/devices_tpm.md +++ b/doc/reference/devices_tpm.md @@ -1,12 +1,22 @@ (devices-tpm)= # タイプ: `tpm` +```{youtube} https://www.youtube.com/watch?v=iE1TN7YIqP0 +:title: LXD TPM devices +``` + ```{note} -`tpm`デバイスタイプはコンテナとVMの両方でサポートされます。 -ホットプラグはコンテナでのみサポートされ、VMではサポートされません。 +`tpm`デバイスタイプは、コンテナとVMの両方でサポートされています。 +ただし、コンテナではホットプラグがサポートされていますが、VMではサポートされていません。 ``` -TPMデバイスはTPMエミュレータへのアクセスを可能にします。 +TPMデバイスは、{abbr}`TPM（Trusted Platform Module）`エミュレータへのアクセスを有効にします。 + +TPMデバイスは、ブートプロセスを検証し、ブートチェーンのステップが改ざんされていないことを確認するために使用できます。また、暗号化キーを安全に生成および保存することもできます。 + +LXDは、TPM 2.0をサポートするソフトウェアTPMを使用します。 +コンテナの主な使用例は、証明書のシールで、これによりキーがコンテナの外部に保存され、攻撃者がそれらを取得することがほぼ不可能になります。 +仮想マシンでは、TPMを証明書のシールに使用するだけでなく、ブートプロセスの検証にも使用できます。これにより、例えば、Windows BitLockerと互換性のあるフルディスク暗号化が可能になります。 ## デバイスオプション diff --git a/doc/reference/devices_unix_block.md b/doc/reference/devices_unix_block.md index 1083cc5..a3e2572 100644 --- a/doc/reference/devices_unix_block.md +++ b/doc/reference/devices_unix_block.md @@ -1,6 +1,10 @@ (devices-unix-block)= # タイプ: `unix-block` +```{youtube} https://www.youtube.com/watch?v=C2e3LD5wLI8 +:title: LXD Unix devices - YouTube +``` + ```{note} `unix-block`デバイスタイプはコンテナでサポートされます。 ホットプラグをサポートします。 diff --git a/doc/reference/devices_unix_char.md b/doc/reference/devices_unix_char.md index 3044f22..10e61f7 100644 --- a/doc/reference/devices_unix_char.md +++ b/doc/reference/devices_unix_char.md @@ -1,6 +1,10 @@ (devices-unix-char)= # タイプ: `unix-char` +```{youtube} https://www.youtube.com/watch?v=C2e3LD5wLI8 +:title: LXD Unix devices - YouTube +``` + ```{note} `unix-char`デバイスタイプはコンテナでサポートされます。 ホットプラグをサポートします。 diff --git a/doc/reference/devices_unix_hotplug.md b/doc/reference/devices_unix_hotplug.md index 0171707..6fdff87 100644 --- a/doc/reference/devices_unix_hotplug.md +++ b/doc/reference/devices_unix_hotplug.md @@ -1,6 +1,10 @@ (devices-unix-hotplug)= # タイプ: `unix-hotplug` +```{youtube} https://www.youtube.com/watch?v=C2e3LD5wLI8 +:title: LXD Unix devices - YouTube +``` + ```{note} `unix-hotplug`デバイスタイプはコンテナでサポートされます。 ホットプラグをサポートします。 diff --git a/doc/reference/devices_usb.md b/doc/reference/devices_usb.md index cd31e00..0a14ab2 100644 --- a/doc/reference/devices_usb.md +++ b/doc/reference/devices_usb.md @@ -1,12 +1,24 @@ (devices-usb)= # タイプ: `usb` +```{youtube} https://www.youtube.com/watch?v=SAord28VS4g +:title: LXD USB devices +``` + ```{note} `usb`デバイスタイプはコンテナとVMの両方でサポートされます。 コンテナとVMの両方でホットプラグをサポートします。 ``` USBデバイスは、指定されたUSBデバイスをインスタンスに出現させます。 +パフォーマンスの問題のため、高スループットまたは低レイテンシを要求するデバイスの使用は避けてください。 + +コンテナでは、(`/dev/bus/usb`にある)`libusb`デバイスのみがインスタンスに渡されます。 +この方法はユーザスペースのドライバを持つデバイスで機能します。 +専用のカーネルドライバを必要とするデバイスは、代わりに[`unix-char`デバイス](devices-unix-char)か[`unix-hotplug`デバイス](devices-unix-hotplug)を使用してください。 + +仮想マシンでは、USBデバイス全体がパススルーされますので、あらゆるUSBデバイスがサポートされます。 +デバイスがインスタンスに渡されると、ホストからは消失します。 ## デバイスオプション @@ -14,9 +26,9 @@ USBデバイスは、指定されたUSBデバイスをインスタンスに出 キー | 型 | デフォルト値 | 説明 :-- | :-- | :-- | :-- -`gid` | int | `0` | インスタンス内のデバイス所有者のGID -`mode` | int | `0660` | インスタンス内のデバイスのモード +`gid` | int | `0` | コンテナのみ: インスタンス内のデバイス所有者のGID +`mode` | int | `0660` | コンテナのみ: インスタンス内のデバイスのモード `productid` | string | - | USBデバイスのプロダクトID `required` | bool | `false` | このデバイスがインスタンスの起動に必要かどうか(デフォルトは`false`で、すべてのデバイスがホットプラグ可能です) -`uid` | int | `0` | インスタンス内のデバイス所有者のUID +`uid` | int | `0` | コンテナのみ: インスタンス内のデバイス所有者のUID `vendorid` | string | - | USBデバイスのベンダーID diff --git a/doc/reference/instance_options.md b/doc/reference/instance_options.md index f228978..fd4d5fd 100644 --- a/doc/reference/instance_options.md +++ b/doc/reference/instance_options.md @@ -67,7 +67,6 @@ key/value 形式の設定は、名前空間で分けられています。 `cloud-init.network-config` | string | `DHCP on eth0` | no | イメージでサポートされている場合 | `cloud-init`のネットワーク設定(設定はシード値として使用) `cloud-init.user-data` | string | `#cloud-config` | no | イメージでサポートされている場合 | `cloud-init`のユーザデータ(設定はシード値として使用) `cloud-init.vendor-data` | string | `#cloud-config` | no | イメージでサポートされている場合 | `cloud-init`のベンダーデータ(設定はシード値として使用) -`user.meta-data` | string | - | no | イメージでサポートされている場合 | `cloud-init`のレガシーなメタデータ(設定はシード値に追加されます) `user.network-config` | string | `DHCP on eth0` | no | イメージでサポートされている場合 | `cloud-init.network-config`のレガシーバージョン `user.user-data` | string | `#cloud-config` | no | イメージでサポートされている場合 | `cloud-init.user-data`のレガシーバージョン `user.vendor-data` | string | `#cloud-config` | no | イメージでサポートされている場合 | `cloud-init.vendor-data`のレガシーバージョン @@ -421,6 +420,7 @@ value = "0" `volatile.last_state.power` | string | 最後にホストがシャットダウンした時点のインスタンスの状態 `volatile.vsock_id` | string | 最後の起動時に使用されたインスタンスの`vsock` ID `volatile.uuid` | string | インスタンスのUUID(全サーバとプロジェクト内でグローバルにユニーク) +`volatile.uuid.generation` | string | インスタンスの時間の位置が後退するたびに変わるインスタンス世代UUID(全サーバとプロジェクト内でグローバルにユニーク) `volatile..apply_quota` | string | 次回のインスタンス起動時に適用されるディスククォータ `volatile..ceph_rbd` | string | CephのディスクデバイスのRBDデバイスパス `volatile..host_name` | string | ホスト上のネットワークデバイス名 diff --git a/doc/reference/remote_image_servers.md b/doc/reference/remote_image_servers.md index 7e086aa..828b879 100644 --- a/doc/reference/remote_image_servers.md +++ b/doc/reference/remote_image_servers.md @@ -1,3 +1,7 @@ +--- +discourse: 16647 +--- + (remote-image-servers)= # リモートイメージサーバ diff --git a/doc/reference/storage_zfs.md b/doc/reference/storage_zfs.md index 5eee48b..baee5f7 100644 --- a/doc/reference/storage_zfs.md +++ b/doc/reference/storage_zfs.md @@ -1,3 +1,7 @@ +--- +discourse: 15872 +--- + (storage-zfs)= # ZFS - `zfs` @@ -117,6 +121,7 @@ ZFS は `quota` と `refquota` という 2 種類の異なるクォータのプ `snapshots.pattern` | string | カスタムボリューム | `volume.snapshots.pattern` と同じか `snap%d` | {{snapshot_pattern_format}} [^*] `snapshots.schedule` | string | カスタムボリューム | `snapshots.schedule` と同じ | {{snapshot_schedule_format}} `zfs.blocksize` | string | ZFSドライバ | `volume.zfs.blocksize` と同じ | ZFSブロックのサイズを512～16MiBの範囲で指定します（2の累乗でなければなりません）。ブロックボリュームでは、より大きな値が設定されていても、最大値の128KiBが使用されます。 +`zfs.block_mode` | bool | ZFS driver | `volume.zfs.block_mode` と同じ | `dataset` よりもフォーマットした `zvol` を使うかどうか `zfs.remove_snapshots` | bool | ZFSドライバ | `volume.zfs.remove_snapshots` と同じか `false` | 必要に応じてスナップショットを削除するかどうか `zfs.use_refquota` | bool | ZFSドライバ | `volume.zfs.use_refquota` と同じか `false` | 領域の `quota` の代わりに `refquota` を使うかどうか `zfs.reserve_space` | bool | ZFS driver | `volume.zfs.reserve_space` と同じか `false` | `qouta`/`refquota` に加えて `reservation`/`refreservation` も使用するかどうか