インスタンスオプション#

インスタンスオプションはインスタンスに直接関係する設定オプションです。

インスタンスオプションをどのように設定するかの手順はインスタンスオプションを設定するを参照してください。

key/value 形式の設定は、名前空間で分けられています。 以下のオプションが利用できます。

各オプションに型が定義されていますが、全ての値は文字列として保管され、REST APIで文字列としてエクスポートされる(こうすることで後方互換性を壊すことなく任意の追加の値をサポートできます)ことに注意してください。

その他のオプション#

以下のセクションに一覧表示される設定オプションに加えて、以下のインスタンスオプションがサポートされます。

キー

型

デフォルト値

ライブアップデート

条件

説明

agent.nic_config

bool

false

no

仮想マシン

デフォルトのネットワークインタフェースの名前とMTUをインスタンスデバイスと同じにするかどうかを制御(これはコンテナでは自動でそうなります)

cluster.evacuate

string

auto

no

-

インスタンス待避時に何をするか(auto, migrate, live-migrate, stop)

environment.*

string

-

yes (exec)

-

インスタンス実行時に設定されるkey/value形式の環境変数

linux.kernel_modules

string

-

yes

コンテナ

インスタンスを起動する前にロードするカーネルモジュールのカンマ区切りのリスト

linux.sysctl.*

string

-

no

コンテナ

コンテナ内の対応するsysctl設定を上書きする値

user.*

string

-

no

-

自由形式のユーザー定義のkey/valueの設定の組(検索に使えます)

ブート関連のオプション#

以下のインスタンスオプションはインスタンスのブート関連の挙動を制御します。

キー

型

デフォルト値

ライブアップデート

条件

説明

boot.autostart

bool

-

n/a

-

LXD起動時に常にインスタンスを起動するかどうかを制御(設定しない場合、最後の状態がリストアされます)

boot.autostart.delay

integer

0

n/a

-

インスタンスが起動した後に次のインスタンスが起動するまで待つ秒数

boot.autostart.priority

integer

0

n/a

-

インスタンスを起動させる順番(高いほど早く起動します)

boot.host_shutdown_timeout

integer

30

yes

-

強制停止前にインスタンスが停止するのを待つ秒数

boot.stop.priority

integer

0

n/a

-

インスタンスの停止順(高いほど早く停止します)

cloud-init 設定#

以下のインスタンスオプションはインスタンスのcloud-init設定を制御します。

キー

型

デフォルト値

ライブアップデート

条件

説明

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.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のレガシーバージョン

これらのオプションのサポートは使用するイメージに依存し、保証はされません。

cloud-init.user-dataとcloud-init.vendor-dataの両方を指定すると、両方のオプションの設定がマージされます。 このため、これらのオプションに設定するcloud-init設定が同じキーを含まないようにしてください。

リソース制限#

以下のインスタンスオプションはインスタンスのリソース制限を指定します。

キー

型

デフォルト値

ライブアップデート

条件

説明

limits.cpu

string

仮想マシンでは 1 CPU

yes

-

インスタンスに割り当てるCPU番号、もしくは番号の範囲。CPUピンニング参照

limits.cpu.allowance

string

100%

yes

コンテナ

どれくらいCPUを使えるかを制御。ソフトリミットとしてパーセント指定(50%)か固定値として単位時間内に使える時間(25ms/100ms)を指定できます。割り当てと優先度 (コンテナのみ)参照

limits.cpu.priority

integer

10 (最大値)

yes

コンテナ

リソースをオーバーコミットする際に同じCPUをシェアする他のインスタンスと比較したCPUスケジューリングの優先度(0〜10の整数)。割り当てと優先度 (コンテナのみ) 参照

limits.disk.priority

integer

5 (中央値)

yes

-

高負荷時に、インスタンスのI/Oリクエストに割り当てる優先度を制御(0〜10の整数)

limits.hugepages.64KB

string

-

yes

コンテナ

64 KB huge pagesの数を制限するためのバイト数(さまざまな単位が指定可能、ストレージとネットワーク制限の単位参照)の固定値。huge page の制限 参照

limits.hugepages.1MB

string

-

yes

コンテナ

1 MB huge pagesの数を制限するためのバイト数(さまざまな単位が指定可能、ストレージとネットワーク制限の単位参照)の固定値。huge page の制限 参照

limits.hugepages.2MB

string

-

yes

コンテナ

2 MB huge pagesの数を制限するためのバイト数(さまざまな単位が指定可能、ストレージとネットワーク制限の単位参照)の固定値。huge page の制限 参照

limits.hugepages.1GB

string

-

yes

コンテナ

1 GB huge pagesの数を制限するためのバイト数(さまざまな単位が指定可能、ストレージとネットワーク制限の単位参照)の固定値。huge page の制限 参照

limits.kernel.*

string

-

no

コンテナ

インスタンスごとのカーネルリソースの制限(例、オープンできるファイルの数)。カーネルリソース制限参照

limits.memory

string

仮想マシンでは 1GiB

yes

-

ホストメモリに対する割合(パーセント)もしくはバイト数(さまざまな単位が指定可能、ストレージとネットワーク制限の単位参照)の固定値

limits.memory.enforce

string

hard

yes

コンテナ

hardに設定すると、インスタンスはメモリー制限値を超過できません。softに設定すると、ホストでメモリに余裕がある場合は超過できます

limits.memory.hugepages

bool

false

no

仮想マシン

インスタンスを動かすために通常のシステムメモリではなくhuge pageを使用するかどうかを制御

limits.memory.swap

bool

true

yes

コンテナ

このインスタンスのあまり使われないページのスワップを推奨／非推奨にするかを制御

limits.memory.swap.priority

integer

10 (最大値)

yes

コンテナ

インスタンスがディスクにスワップされるのを防ぐ(0〜10の整数。高い値を設定するほど、インスタンスがディスクにスワップされにくくなります)

limits.network.priority

integer

0 (最小値)

yes

-

高負荷時に、インスタンスのネットワークリクエストに割り当てる優先度(0〜10の整数)を制御

limits.processes

integer

- (最大値)

yes

コンテナ

インスタンス内で実行できるプロセスの最大数

CPU制限#

CPU制限はcgroupコントローラのcpusetとcpuを組み合わせて実装しています。

CPUピンニング#

limits.cpuはcpusetコントローラを使って、CPUを固定(ピンニング)します。 どのCPUを使うか、またはどれぐらいの数のCPUを使うかを指定できます。

  • どのCPUを使うかを指定するには、limits.cpuをCPUの組み合わせ(例:1,2,3)あるいはCPUの範囲(例:0-3)で指定できます。

    単一のCPUにピンニングするためには、CPUの個数との区別をつけるために、範囲を指定する文法(例:1-1)を使う必要があります。

  • CPUの個数を指定した場合(例:4)、LXDは特定のCPUにピンニングされていない全てのインスタンスをダイナミックに負荷分散し、マシン上の負荷を分散しようとします。 インスタンスが起動したり停止するたびに、またシステムにCPUが追加されるたびに、インスタンスはリバランスされます。

注釈

LXDの仮想マシンはデフォルトでは1つのvCPUだけを割り当てられ、ホストのCPUのベンダーとタイプとマッチしたCPUとして現れますが、シングルコアでスレッドなしになります。

limits.cpuを単一の整数に設定する場合、LXDは複数のvCPUを割り当ててゲストにはフルなコアとして公開します。 これらのvCPUはホスト上の特定の物理コアにはピンニングされません。 vCPUの個数はVMの稼働中に変更できます。

limits.cpuをCPU ID(lxc info --resources で表示されます)の範囲またはカンマ区切りリストの組に設定する場合、vCPUは物理コアにピンニングされます。 このシナリオでは、LXDはCPU設定が現実のハードウェアトポロジーとぴったり合うかチェックし、合う場合はそのトポロジーをゲスト内に複製します。 CPUピンニングを行う場合、VMの稼働中に設定を変更することはできません。

例えば、ピンニング設定が8個のスレッド、同じコアのスレッドの各ペアと2個のCPUに散在する偶数のコアを持つ場合、ゲストは2個のCPU、各CPUに2個のコア、各コアに2個のスレッドを持ちます。 NUMAレイアウトは同様に複製され、このシナリオでは、ゲストではほとんどの場合、2個のNUMAノード、各CPUソケットに1個のノードを持つことになるでしょう。

複数のNUMAノードを持つような環境では、メモリは同様にNUMAノードで分割され、ホスト上で適切にピンニングされ、その後ゲストに公開されます。

これら全てにより、ゲストスケジューラはソケット、コア、スレッドを適切に判断し、メモリを共有したりNUMAノード間でプロセスを移動する際にNUMAトポロジーを考慮できるので、ゲスト内で非常に高パフォーマンスな操作を可能にします。

割り当てと優先度 (コンテナのみ)#

limits.cpu.allowanceは、時間の制限を与えたときはCFSスケジューラのクォータを、パーセント指定をした場合は全体的なCPUシェアの仕組みを使います。

  • 時間制限(例:20ms/50ms)はひとつのCPU相当の時間に関連するので、ふたつのCPUの時間を制限するには、100ms/50msのような指定を使うようにします。

  • パーセント指定を使う場合は、制限は負荷状態にある場合のみに適用されます。 設定は、同じCPU(もしくはCPUの組)を使う他のインスタンスとの比較で、インスタンスに対するスケジューラの優先度を計算するのに使われます。

limits.cpu.priority は、CPUの組を共有する複数のインスタンスに割り当てられたCPUの割合が同じ場合に、スケジューラの優先度スコアを計算するために使われる別の因子です。

huge page の制限#

LXD では limits.hugepage.[size] キーを使ってコンテナが利用できるhuge pageの数を制限できます。

アーキテクチャはしばしばhuge pageのサイズを公開しています。 利用可能なhuge pageサイズはアーキテクチャによって異なります。

huge pageの制限は非特権コンテナ内でhugetlbfsファイルシステムのmountシステムコールをインターセプトするようにLXDを設定しているときには特に有用です。 LXDがhugetlbfs mountシステムコールをインターセプトするとLXDは正しいuidとgidの値をmountオプションに指定してhugetblfsファイルシステムをコンテナにマウントします。 これにより非特権コンテナからもhuge pageが利用可能となります。 しかし、ホストで利用可能なhuge pageをコンテナが使い切ってしまうのを防ぐため、limits.hugepages.[size]を使ってコンテナが利用可能なhuge pageの数を制限することを推奨します。

huge pageの制限はhugetlb cgroupコントローラによって実行されます。これはこれらの制限を適用するために、ホストシステムがhugetlbコントローラをレガシーあるいはcgroupの単一階層構造(訳注:cgroup v2)に公開する必要があることを意味します。

カーネルリソース制限#

LXDは、インスタンスのリソース制限を設定するのに使用できる一般の名前空間キーlimits.kernel.*を公開しています。

limits.kernel.*接頭辞に続いて指定されるリソースについてLXDが全く検証を行わないという意味でこれは汎用です。 LXDは対象のカーネルがサポートする全ての利用可能なリソースについて知ることはできません。 代わりに、LXDはlimits.kernel.*接頭辞の後の対応するリソースキーとその値をカーネルに単に渡します。 カーネルが適切な検証を行います。 これによりユーザーはシステム上でサポートされる任意の制限を指定できます。

よくある制限のいくつかは以下のとおりです。

キー

リソース

説明

limits.kernel.as

RLIMIT_AS

プロセスの仮想メモリーの最大サイズ

limits.kernel.core

RLIMIT_CORE

プロセスのコアダンプファイルの最大サイズ

limits.kernel.cpu

RLIMIT_CPU

プロセスが使えるCPU時間の秒単位の制限

limits.kernel.data

RLIMIT_DATA

プロセスのデータセグメントの最大サイズ

limits.kernel.fsize

RLIMIT_FSIZE

プロセスが作成できるファイルの最大サイズ

limits.kernel.locks

RLIMIT_LOCKS

プロセスが確立できるファイルロック数の制限

limits.kernel.memlock

RLIMIT_MEMLOCK

プロセスがRAM上でロックできるメモリのバイト数の制限

limits.kernel.nice

RLIMIT_NICE

引き上げることができるプロセスのnice値の最大値

limits.kernel.nofile

RLIMIT_NOFILE

プロセスがオープンできるファイルの最大値

limits.kernel.nproc

RLIMIT_NPROC

呼び出し元プロセスのユーザーが作れるプロセスの最大数

limits.kernel.rtprio

RLIMIT_RTPRIO

プロセスに対して設定できるリアルタイム優先度の最大値

limits.kernel.sigpending

RLIMIT_SIGPENDING

呼び出し元プロセスのユーザーがキューに入れられるシグナルの最大数

指定できる制限の完全なリストは getrlimit(2)/setrlimit(2)システムコールの man ページで確認できます。

limits.kernel.*名前空間内で制限を指定するには、RLIMIT_を付けずに、リソース名を小文字で指定します。 例えば、RLIMIT_NOFILEはnofileと指定します。

制限は、コロン区切りのふたつの数字もしくはunlimitedという文字列で指定します(例:limits.kernel.nofile=1000:2000)。 単一の値を使って、ソフトリミットとハードリミットを同じ値に設定できます(例:limits.kernel.nofile=3000)。

明示的に設定されないリソースは、インスタンスを起動したプロセスから継承されます。 この継承はLXDでなく、カーネルによって強制されることに注意してください。

マイグレーションオプション#

以下のインスタンスオプションはインスタンスがあるLXDサーバから別のサーバに移動される場合の挙動を制御します。

キー

型

デフォルト値

ライブアップデート

条件

説明

migration.incremental.memory

bool

false

yes

コンテナ

インスタンスのダウンタイムを短くするためにインスタンスのメモリを増分転送するかどうかを制御

migration.incremental.memory.goal

integer

70

yes

コンテナ

インスタンスを停止させる前に同期するメモリの割合(%)

migration.incremental.memory.iterations

integer

10

yes

コンテナ

インスタンスを停止させる前に完了させるメモリ転送処理の最大数

migration.stateful

bool

false

no

仮想マシン

ステートフルな停止/開始とスナップショットを許可するかどうかを制御(有効にするとこれと非互換ないくつかの機能は使えなくなります)

NVIDIAとCUDAの設定#

以下のインスタンスオプションはインスタンスのNVIDIAとCUDAの設定を指定します。

キー

型

デフォルト値

ライブアップデート

条件

説明

nvidia.driver.capabilities

string

compute,utility

no

コンテナ

インスタンスに必要なドライバケーパビリティ(libnvidia-container に環境変数NVIDIA_DRIVER_CAPABILITIESを設定)

nvidia.runtime

bool

false

no

コンテナ

ホストのNVIDIAとCUDAラインタイムライブラリをインスタンス内でも使えるようにする

nvidia.require.cuda

string

-

no

コンテナ

必要となるCUDAバージョンのバージョン表記(libnvidia-container に環境変数NVIDIA_REQUIRE_CUDAを設定)

nvidia.require.driver

string

-

no

コンテナ

必要となるドライババージョンのバージョン表記(libnvidia-containerに環境変数NVIDIA_REQUIRE_DRIVERを設定)

rawインスタンス設定のオーバーライド#

以下のインスタンスオプションはLXD自身が使用するバックエンド機能に直接制御できるようにします。

キー

型

デフォルト値

ライブアップデート

条件

説明

raw.apparmor

blob

-

yes

-

生成されたプロファイルに追加するAppArmorプロファイルエントリ

raw.idmap

blob

-

no

非特権コンテナ

生(raw)のidmap設定(例:both 1000 1000)

raw.lxc

blob

-

no

コンテナ

生成された設定に追加する生(raw)のLXC設定

raw.qemu

blob

-

no

仮想マシン

生成されたコマンドラインに追加される生(raw)のQEMU設定

raw.qemu.conf

blob

-

no

仮想マシン

生成されたqemu.confに追加/オーバーライドする(QEMU設定のオーバーライド参照)

raw.seccomp

blob

-

no

コンテナ

生(raw)のSeccomp設定

重要

これらのraw.*キーを設定するとLXDを予期せぬ形で壊してしまうかもしれません。 このため、これらのキーを設定するのは避けるほうが良いです。

QEMU設定のオーバーライド#

VMインスタンスに対しては、LXDは-readconfigコマンドラインオプションでQEMUに渡す設定ファイルを使ってQEMUを設定します。 この設定ファイルは各インスタンスの起動前に生成されます。 設定ファイルは/var/log/lxd/<instance_name>/qemu.confに作られます。

デフォルトの設定はほとんどの典型的な利用ケース、VirtIOデバイスを持つモダンなUEFIゲスト、では正常に動作します。 しかし、いくつかの状況では、生成された設定をオーバーライドする必要があります。 例えば以下のような場合です。

  • UEFIをサポートしない古いゲストOSを実行する。

  • VirtIOがゲストOSでサポートされない場合にカスタムな仮想デバイスを指定する。

  • マシンの起動前にLXDでサポートされないデバイスを追加する。

  • ゲストOSと衝突するデバイスを削除する。

設定をオーバーライドするには、raw.qemu.confオプションを設定します。 これはqemu.confと似たような形式ですが、いくつか拡張した形式をサポートします。 これは複数行の設定オプションですので、複数のセクションやキーを変更するのに使えます。

  • 生成された設定ファイルのセクションやキーを置き換えるには、別の値を持つセクションを追加します。

    例えば、デフォルトのvirtio-gpu-pci GPUドライバをオーバーライドするには以下のセクションを使います。

    raw.qemu.conf: |-
    [device "qemu_gpu"]
    driver = "qxl-vga"

  • セクションを削除するには、キー無しのセクションを指定します。 例えば以下のようにします。

    raw.qemu.conf: |-
    [device "qemu_gpu"]

  • キーを削除するには、空の文字列を値として指定します。 例えば以下のようにします。

    raw.qemu.conf: |-
    [device "qemu_gpu"]
    driver = ""

  • 新規のセクションを追加するには、設定ファイル内に存在しないセクション名を指定します。

QEMUで使用される設定ファイル形式は同じ名前の複数のセクションを許可します。 以下はLXDで生成される設定の抜粋です。

[global]
driver = "ICH9-LPC"
property = "disable_s3"
value = "1"

[global]
driver = "ICH9-LPC"
property = "disable_s4"
value = "1"

オーバーライドするセクションを指定するには、インデクスを指定します。 例えば以下のようにします。

raw.qemu.conf: |-
    [global][1]
    value = "0"

セクションのインデクスは0(指定しない場合のデフォルト値)から始まりますので、上の例は以下の設定を生成します。

[global]
driver = "ICH9-LPC"
property = "disable_s3"
value = "1"

[global]
driver = "ICH9-LPC"
property = "disable_s4"
value = "0"

セキュリティポリシー#

以下のインスタンスオプションはインスタンスのセキュリティポリシーを制御します。

キー

型

デフォルト値

ライブアップデート

条件

説明

security.devlxd

bool

true

no

-

インスタンス内の/dev/lxdの存在を制御

security.devlxd.images

bool

false

no

コンテナ

devlxd経由の/1.0/imagesの利用可否を制御

security.idmap.base

integer

-

no

非特権コンテナ

割り当てに使うホストIDの開始値(自動検出を上書きします)

security.idmap.isolated

bool

false

no

非特権コンテナ

インスタンス間で独立したidmapのセットを使用するかどうかを制御

security.idmap.size

integer

-

no

非特権コンテナ

使用するidmapのサイズ

security.nesting

bool

false

yes

コンテナ

インスタンス内でネストしたLXDの実行を許可するかどうかを制御

security.privileged

bool

false

no

コンテナ

特権モードでインスタンスを実行するかどうかを制御

security.protection.delete

bool

false

yes

-

インスタンスを削除から保護する

security.protection.shift

bool

false

yes

コンテナ

インスタンスのファイルシステムが起動時に UID/GID がシフト(再マッピング)されるのを防ぐ

security.agent.metrics

bool

true

no

仮想マシン

状態の情報とメトリクスをlxd-agentに問い合わせるかどうかを制御

security.secureboot

bool

true

no

仮想マシン

UEFIセキュアブートがデフォルトのMicrosoftのキーで有効になるかを制御

security.sev

bool

false

no

仮想マシン

AMD SEV (Secure Encrypted Virtualization)をこのVMで有効にするかを制御

security.sev.policy.es

bool

false

no

仮想マシン

AMD SEV-ES (SEV Encrypted State)をこのVMで有効にするかを制御

security.sev.session.dh

string

true

no

仮想マシン

ゲストオーナーのbase64エンコードされたDiffie-Hellmanキー

security.sev.session.data

string

true

no

仮想マシン

ゲストオーナーのbase64エンコードされたsession blob

security.syscalls.allow

string

-

no

コンテナ

\n区切りのシステムコールの許可リスト(security.syscalls.deny*を使う場合は使用不可)

security.syscalls.deny

string

-

no

コンテナ

\n区切りのシステムコールの拒否リスト

security.syscalls.deny_compat

bool

false

no

コンテナ

x86_64では、compat_*システムコールのブロックを有効にするかどうかを制御(他のアーキテクチャでは何もしません)

security.syscalls.deny_default

bool

true

no

コンテナ

デフォルトのシステムコールの拒否を有効にするかどうかを制御

security.syscalls.intercept.bpf

bool

false

no

コンテナ

bpfシステムコールを処理するかどうかを制御

security.syscalls.intercept.bpf.devices

bool

false

no

コンテナ

cgroupの単一階層構造(訳注:cgroup v2)内のdevice cgroup用のbpfプログラムのロードを許可するかどうかを制御

security.syscalls.intercept.mknod

bool

false

no

コンテナ

mknodとmknodatシステムコールを処理するかどうかを制御(限定されたサブセットのキャラクタ／ブロックデバイスの作成を許可する)

security.syscalls.intercept.mount

bool

false

no

コンテナ

mountシステムコールを処理するかどうかを制御

security.syscalls.intercept.mount.allowed

string

-

yes

コンテナ

インスタンス内のプロセスが安全にマウントできるファイルシステムのカンマ区切りリスト

security.syscalls.intercept.mount.fuse

string

-

yes

コンテナ

FUSE実装にリダイレクトするべき指定されたファイルシステムのマウント(例:ext4-fuse2fs)

security.syscalls.intercept.mount.shift

bool

false

yes

コンテナ

mountシステムコールをインターセプトして処理対象のファイルシステムの上にshiftfsをマウントするかどうかを制御

security.syscalls.intercept.sched_setscheduler

bool

false

no

コンテナ

sched_setschedulerシステムコールを処理するかどうかを制御(プロセスの優先度を上げられるようにする)

security.syscalls.intercept.setxattr

bool

false

no

コンテナ

setxattrシステムコールを処理するかどうかを制御(限定されたサブセットの制限された拡張属性の設定を許可する)

security.syscalls.intercept.sysinfo

bool

false

no

コンテナ

sysinfoシステムコールを(cgroupベースのリソース使用情報を取得するために)処理するかどうかを制御

スナップショットのスケジュールと設定#

以下のインスタンスオプションはinstance snapshotsの作成と削除を制御します。

キー

型

デフォルト値

ライブアップデート

条件

説明

snapshots.schedule

string

-

no

-

Cron 表記 (<minute> <hour> <dom> <month> <dow>)、またはスケジュールエイリアスのカンマ区切りリスト(@hourly, @daily, @midnight, @weekly, @monthly, @annually, @yearly)、または自動スナップショットを無効にする場合は空文字(デフォルト)

snapshots.schedule.stopped

bool

false

no

-

停止したインスタンスのスナップショットを自動的に作成するかどうかを制御

snapshots.pattern

string

snap%d

no

-

スナップショットの名前を表す Pongo2 テンプレート文字列 (スケジュールされたスナップショットと名前無しのスナップショットで使用)。スナップショットの自動命名参照

snapshots.expiry

string

-

no

-

スナップショットをいつ削除するかを制御 (1M 2H 3d 4w 5m 6y のような式を期待)

スナップショットの自動命名#

snapshots.pattern オプションはスナップショット名をフォーマットする Pongo2 テンプレート文字列です。

スナップショット名にタイムスタンプを追加するには、Pongo2 コンテキスト変数 creation_date を使用します。 スナップショット名に使用できない文字を含まないようにテンプレート文字列をフォーマットするようにしてください。 例えば、 snapshots.pattern を {{ creation_date|date:'2006-01-02_15-04-05' }} に設定し、作成日時を秒の制度まで落として、スナップショットを命名するようにします。

名前の衝突を防ぐ別の方法はパターン内に %d プレースホルダを使うことです。 最初のスナップショットでは、プレースホルダは 0 に置換されます。 後続のスナップショットでは、既存のスナップショットが考慮され、プレースホルダの位置の最大の数を見つけます。 この数が 1 増加されて新しい名前に使用されます。

揮発性の内部データ#

以下の揮発性のキーはインスタンスに固有な内部データを保管するためLXDで現在内部的に使用されています。

キー

型

説明

volatile.apply_template

string

次の起動時にトリガーされるテンプレートフックの名前

volatile.apply_nvram

string

次の起動時に仮想マシンのNVRAMを再生成するかどうか

volatile.base_image

string

インスタンスを作成したイメージのハッシュ(存在する場合)

volatile.cloud-init.instance-id

string

cloud-initに公開するinstance-id(UUID)

volatile.evacuate.origin

string

待避したインスタンスのオリジン(クラスタメンバー)

volatile.idmap.base

integer

インスタンスの主idmapの範囲の最初のID

volatile.idmap.current

string

インスタンスで現在使用中のidmap

volatile.idmap.next

string

次にインスタンスが起動する際に使うidmap

volatile.last_state.idmap

string

シリアライズ化したインスタンスのUID/GIDマップ

volatile.last_state.power

string

最後にホストがシャットダウンした時点のインスタンスの状態

volatile.vsock_id

string

最後の起動時に使用されたインスタンスのvsock ID

volatile.uuid

string

インスタンスのUUID(全サーバとプロジェクト内でグローバルにユニーク)

volatile.uuid.generation

string

インスタンスの時間の位置が後退するたびに変わるインスタンス generation UUID (全サーバとプロジェクト内でグローバルにユニーク)

volatile.<name>.apply_quota

string

次回のインスタンス起動時に適用されるディスククォータ

volatile.<name>.ceph_rbd

string

CephのディスクデバイスのRBDデバイスパス

volatile.<name>.host_name

string

ホスト上のネットワークデバイス名

volatile.<name>.hwaddr

string

ネットワークデバイスのMACアドレス(hwaddrプロパティがデバイスに設定されていない場合)

volatile.<name>.last_state.created

string

物理デバイスのネットワークデバイスが作られたかどうか(trueまたはfalse)

volatile.<name>.last_state.mtu

string

物理デバイスをインスタンスに移動したときに使われていたネットワークデバイスの元のMTU

volatile.<name>.last_state.hwaddr

string

物理デバイスをインスタンスに移動したときに使われていたネットワークデバイスの元のMAC

volatile.<name>.last_state.vdpa.name

string

VDPAデバイスファイルディスクリプタをインスタンスに移動させる際に使用されるVDPAデバイス名

volatile.<name>.last_state.vf.id

string

SR-IOVの仮想ファンクション(VF)をインスタンスに移動したときに使われていたVFのID

volatile.<name>.last_state.vf.hwaddr

string

SR-IOVの仮想ファンクション(VF)をインスタンスに移動したときに使われていたVFのMAC

volatile.<name>.last_state.vf.vlan

string

SR-IOVの仮想ファンクション(VF)をインスタンスに移動したときに使われていたVFの元のVLAN

volatile.<name>.last_state.vf.spoofcheck

string

SR-IOVの仮想ファンクション(VF)をインスタンスに移動したときに使われていたVFの元のspoofチェックの設定

注釈

揮発性のキーはユーザは設定できません。