Provided by: lxc_6.0.4-4ubuntu1_amd64 
NAME
lxc.container.conf - LXC コンテナ設定ファイル
説明
LXC は良く知られた、多くのテストが行われた Linux コンテナのランタイムです。LXC は、2008 年以来アクティブ
に開発されており、世界中の重要な本番環境で実証されています。開発への貢献者の中には、Linux カーネル内の良
く知られた様々なコンテナ機能の実装に貢献した人と同じ人もいます。
LXC は主にシステムコンテナにフォーカスを当てています。つまり、VM で得られる環境と可能な限り近い環境を提供
を提供するにも関わらず、別々のカーネルを実行したり、ハードウェアをすべてシミュレートしたりすることによる
オーバーヘッドがないコンテナのことです。
このような環境は、名前空間 (namespace)、強制アクセスコントロール、cgroup といったカーネルのセキュリティ機
能の組み合わせで実現しています。
LXC は非特権コンテナをサポートしています。非特権コンテナは、いかなる特権も持たずに実行するコンテナで
す。非特権コンテナの実行には、コンテナを実行しているカーネルにユーザ名前空間 (user namespace) のサポート
が必要です。LXC は、ユーザ名前空間がメインラインカーネルにマージされてから、初めて非特権コンテナをサポー
トしたランタイムです。
本質的には、ユーザ名前空間は与えられた UID、GID の組を隔離します。ユーザ名前空間は、ホスト上の UID、GID
のある範囲を、それとは異なるコンテナ上の UID、GID の範囲へマッピングすることで実現します。カーネルは、ホ
スト上では実際には UID、GID は特権を持たないにも関わらず、コンテナ内ではすべての UID、GID が期待されるよ
うに見えるように変換を行います。 例えば、コンテナ内では UID、GID が 0 として実行中のプロセスは、ホスト上
では UID、GID が 100000 として見えるでしょう。実装と動作の詳細は、ユーザ名前空間の man ページから得られま
す。UID と GID のマッピングは lxc.idmap を使って定義できます。
Linux コンテナは、簡単な設定ファイルで定義します。設定ファイル中のオプションは key = value の形で一行で表
します。'#' は、その行はコメントであることを示します。ケーパビリティや cgroup のオプションのような、リス
ト形式で指定するオプションでは、value がない形式で指定でき、そのように使うと、それ以前に定義した値をすべ
てクリアします。
LXC は、シングルドットを使って設定キーの名前空間を表します。lxc.net.0 のような複雑な設定キー
は、lxc.net.0.type、lxc.net.0.link、lxc.net.0.ipv6.address や、さらに細分化された設定向けの色々なサブキー
を持つことを意味します。
設定
複数の関係するコンテナの管理を容易にするために、コンテナの設定ファイルに別のファイルをロードすることが可
能です。 例えば、ネットワークの設定を、複数のコンテナから include させるように 1 つのファ�\xA4ルに定義す
ることが可能です。 その場合、コンテナが他のホストに移動すると、そのファイルだけを更新する必要があるかもし
れません。
lxc.include
include させたいファイルを指定します。 include するファイルは、lxc 設定ファイルのフォーマットとし
て有効でなければいけません。
アーキテクチャ
コンテナに対してアーキテクチャを設定することが可能です。 例えば、64 ビットのホスト上で 32 ビットのバイナ
リを動かすために 32 ビットアーキテクチャを設定することが可能です。 この設定を行うことにより、パッケージの
ダウンロードを行うなどの作業のうち、アーキテクチャ名に依存するような作業を行うコンテナスクリプトの修正を
行います。
lxc.arch
コンテナに設定するアーキテクチャを指定します。
有効なオプションには以下のようなものがあります。 x86, i686, x86_64, amd64
ホスト名
utsname セクションは、コンテナに設定されるホスト名を定義します。 コンテナは、システムのホスト名を変えるこ
となく、自身のホスト名を持つ事が可能です。 このことにより、ホスト名はコンテナ専用となります。
lxc.uts.name
コンテナのホスト名を指定します。
クリーンなシャットダウン時のシグナル
コンテナをクリーンにシャットダウンするためにコンテナの init プロセスに送るシグナル名か番号を指定できま
す。init システムによって、クリーンなシャットダウンを行うために使うシグナルは異なります。このオプションで
はシグナルとして kill(1) で使う形式を指定できます。 例えば SIGKILL, SIGRTMIN+14, SIGRTMAX-10 のような形
式、もしくは数字を指定します。デフォルトのシグナルは SIGPWR です。
lxc.signal.halt
コンテナをシャットダウンするために使うシグナルを指定します。
リブート時のシグナル
コンテナをリブートするために送るシグナル名か番号を指定できます。このオプションではシグナルとして kill(1)
で使う形式を指定できます。 例えば SIGKILL, SIGRTMIN+14, SIGRTMAX-10 のような形式、もしくは数字を指定しま
す。デフォルトのシグナルは SIGINT です。
lxc.signal.reboot
コンテナをリブートするために使うシグナルを指定します。
強制停止時のシグナル
コンテナを強制的にシャットダウンするために送るシグナル名か番号を指定できます。このオプションではシグナル
として kill(1) で使う形式を指定できます。 例えば SIGKILL, SIGRTMIN+14, SIGRTMAX-10 のような形式、もしくは
数字を指定します。デフォルトのシグナルは SIGKILL です。
lxc.signal.stop
コンテナを停止するのに使用するシグナルを指定します。
INIT コマンド
コンテナの init として使うコマンドを設定します。
lxc.execute.cmd
デフォルトで実行するバイナリのコンテナの root からの絶対パスを指定します。これは lxc-execute のた
めの設定です。
lxc.init.cmd
init として使うバイナリの、コンテナの root からの絶対パスを指定します。これは lxc-start のための設
定です。デフォルトは /sbin/init です。
INIT のワーキングディレクトリ
コンテナのワーキングディレクトリとして、コンテナ内の絶対パスを設定します。LXC は init を実行する前に、こ
のディレクトリに移動します。
lxc.init.cwd
ワーキングディレクトリとして使うコンテナ内の絶対パス
INIT が使う ID
init と後続のコマンドが使う UID/GID を設定します。システムコンテナを起動するのに非 root な UID を使う
と、特権がないために動作しないでしょう。UID/GID の指定は、通常はアプリケーションコンテナの動作の際に役に
立ちます。 デフォルト値: UID(0)、GID(0)
lxc.init.uid
init が使う UID です。
lxc.init.gid
init が使う GID です。
コアスケジューリング
コアスケジューリングは、コンテナのペイロードが同じコアでスケジュール可能であるとマークするかどうかを指定
します。 これによりカーネルスケジューラーは、同じグループに属さないタスクが同一コア上で同時に実行されない
ようにします。 これは、コンテナペイロードがクロスハイパースレッド攻撃を受けることを防ぐための、追加のセ
キュリティ対策として機能させることができます。
lxc.sched.core
0 または 1 のみ指定できます。1 を設定すると、コンテナに対するコアスケジューリングドメインを作成
し、0 を設定すると作成しません。 明示的に指定していない場合は、コンテナに対するコアスケジューリン
グドメインは作成されません。
PROC
コンテナ内の proc ファイルシステムで設定できるパラメータを設定します。
lxc.proc.[proc file name]
設定したい proc ファイルシステムのファイル名を指定します。指定できるファイル名は /proc/PID/ 以下に
存在するものです。 例:
lxc.proc.oom_score_adj = 10
一時的なコンテナ
シャットダウン後にコンテナを削除するかどうかを指定できます。
lxc.ephemeral
指定できる値は 0 または 1 のみです。この値を 1 に設定すると、シャットダウン後にコンテナを削除しま
す。
ネットワーク
ネットワークセクションは、コンテナ内でどのようにネットワークを仮想化するかを定義します。 ネットワークの仮
想化はレイヤー 2 で作動します。 ネットワークの仮想化を使用するためには、コンテナのネットワークインター
フェースを定義しなければなりません。 いくつかの仮想インターフェースをアサインすることができます。 そし
て、仮に物理ネットワークインターフェースが一つしかなくても、コンテナ内でいくつもの仮想インターフェースを
使うことができます。
lxc.net
値を指定せずに使い、それ以前に定義されたすべてのネットワークオプションをクリアできます。
lxc.net.[i].type
コンテナがどの種類のネットワーク仮想化を使うかを指定します。ネットワークデバイスの他のオプションを
設定する前に指定しなければいけません。 すべての lxc.net.* キーに、追加のインデックス i を使う
と、複数のネットワークを指定できます。例えば、lxc.net.0.type = veth と lxc.net.1.type = veth
は、同じタイプの異なるネットワークを 2 つ指定します。 同じインデックスを指定したキーはすべて同じ
ネットワークの指定になります。例えば、lxc.net.0.link = br0 は lxc.net.0.type と同じネットワークの
設定になります。 現時点では、以下のネットワーク仮想化のタイプが使えます:
empty: ループバックインターフェースだけを作成します。
veth: 一方がコンテナに、もう一方がホストに接続されるペアの仮想イーサネットデバイスを作成します。
lxc.net.[i].veth.mode は、veth の親（ホスト側）がホスト上で使うモードを指定します。 指定できるモー
ドは bridge と router です。 指定しない場合のデフォルトのモードは bridge です。 bridge モードで
は、ホスト側は、lxc.net.[i].link オプションで指定したブリッジに接続されます。 もし、ブリッジが指定
されていない場合、veth ペアデバイスは作成されますが、ブリッジには接続されません。 ブリッジはコンテ
ナが開始する前にシステムで事前に設定しておく必要があります。 lxc はコンテナ外の設定を扱うことはあ
りません。 router モードでは、ホスト側の veth インターフェースを指すコンテナの IP アドレスに対し
て、ホスト上でスタティックルートが作成されます。 加えて、コンテナがホストに到達できるために、コン
テナ内で定義されたゲートウェイの IP アドレスに対して、Proxy ARP と Proxy NDP エントリがホスト側の
veth インターフェースに追加されます。 デフォルトでは、lxc がコンテナの外部に属するネットワークデバ
イスに対する名前を決定します。 しかし、もしこの名前を自分で指定したい場合、lxc.net.[i].veth.pair
オプションを使って名前を設定し、lxc に対して指定をすることができます (非特権コンテナの場合をのぞき
ます。セキュリティ上の理由からこのオプションは無視されます)。
lxc.net.[i].veth.ipv4.route、lxc.net.[i].veth.ipv6.route オプションを使って、静的ルーティングをコ
ンテナを指し示すホスト上に追加できます。 複数のルートがある場合は複数の設定を指定します。 ルートは
x.y.z.t/m の形式です。例: 192.168.1.0/24 bridge モードでは、タグなし VLAN は
lxc.net.[i].veth.vlan.id で設定できます。このオプションでは、コンテナポートをブリッジのデフォルト
のタグなし VLAN から削除するための特別な値 'none' が指定できます。コンテナのブリッジポートを複数の
タグ付き VLAN に所属させるために、lxc.net.[i].veth.vlan.tagged.id を複数回指定できます。
vlan: vlan インターフェースは lxc.net.[i].link で指定されたインターフェースとリンクし、コンテナに
割り当てられます。 vlan の指定は lxc.net.[i].vlan.id オプションで指定します。
macvlan: macvlan インターフェースは lxc.net.[i].link により指定されるインターフェースとリンク
し、コンテナに割り当てられます。 lxc.net.[i].macvlan.mode でモードを指定すると、その macvlan の指
定を、同じ上位デバイスで異なる macvlan 間の通信をする時に使います。 指定できるモードは
private、vepa、bridge、passthru のいずれかです。 private モードの場合、デバイスは同じ上位デバイス
の他のデバイスとの通信を行いません (デフォルト)。 新しい仮想イーサネットポート集約モード (Virtual
Ethernet Port Aggregator (VEPA)) である vepa モードの場合、隣接したポートが、ソースとデスティネー
ションの両方が macvlan ポートに対してローカルであるフレームを全て返すと仮定します。 すなわち、ブ
リッジが reflective relay として設定されているということです。 上位デバイスから入ってくるブロード
キャストフレームは、VEPA モードである全ての macvlan インターフェースに送りつけられます。 ローカル
のフレームはローカルには配送されません。 bridge モードの場合、同じポートの異なる macvlan インター
フェースの間のシンプルなブリッジとして動作します。 あるインターフェースから他のインターフェースへ
のフレームは、直接配送され、外部には送出されません。 ブロードキャストフレームは、全ての他のブリッ
ジと外部のインターフェースに対して送られます。 しかし、reflective relay からフレームが返ってきたと
きは、再度それを配送することはしません。 全ての MAC アドレスを知っているので、ブリッジモジュールの
ように、macvlan ブリッジモードは学習や STP の必要はありません。 passthru モードの場合、物理イン
ターフェースで受け取った全てのフレームは macvlan インターフェースに転送されます。passthru モードの
場合、ひとつの macvlan インターフェースだけが、ひとつの物理インターフェースに対して設定できます。
ipvlan: ipvlan インターフェースは lxc.net.[i].link により指定されるインターフェースとリンクし、コ
ンテナに割り当てられます。 lxc.net.[i].ipvlan.mode でモードを指定すると、その ipvlan の指定を、同
じ上位デバイスで異なる ipvlan 間の通信をする時に使います。 指定できるモードは l3、l3s、l2 で、デ
フォルトは l3 モードです。 l3 モードでは、L3 までの TX (送信) 処理はスレーブデバイスにアタッチされ
たスタックインスタンス上で行われます。 そしてパケットは、L2 処理のためにマスターデバイスのスタック
インスタンスにスイッチされます。このインスタンスからのルーティングは、発信デバイス上でキューに入る
前に使われます。 このモードでは、スレーブはマルチキャスト・ブロードキャストのトラフィックを受信し
ませんし、送信もできません。 l3s モードは、TX (送信) 処理は L3 モードと非常に似ています
が、iptables (conn-tracking) がこのモードで動作します。 それゆえに L3対称 (symmetric) (L3s) で
す。このモードは若干パフォーマンスが低下しますが、conn-tracking (接続追跡) が動作するように、普通
の L3 モードの代わりにこのモードを選んでいるので問題にはならないはずです。 l2 モードでは、TX (送
信) 処理はスレーブデバイスにアタッチされたスタックインスンタンス上で行われます。 パケットは送信の
ため、マスターデバイスにスイッチされ、マスターデバイス上でキューに入ります。このモードでは、スレー
ブはマルチキャストも（該当する場合）ブロードキャストも RX/TX (送受信) 処理します。
lxc.net.[i].ipvlan.isolation は隔離モードを指定します。隔離モードには bridge、private、vepa が指定
できます。デフォルトは bridge モードです。 bridge 隔離モードでは、スレーブはマスターデバイス経由の
通信とは別に、スレーブ同士で通信できます。 private 隔離モードでは、ポートはプライベートに設定され
ます。つまり、スレーブ間の通信はできません。 vepa 隔離モードでは、ポートは VEPA モードに設定されま
す。つまり、802.1Qbg で説明されているように、ポートはスイッチング機能を外部エンティティにオフロー
ドします。
phys: lxc.net.[i].link で指定された、すでに存在しているインターフェースがコンテナに割り当てられま
す。
lxc.net.[i].flags
ネットワークに対して行うアクションを指定します。
up: インターフェースを起動させます。
lxc.net.[i].link
実際のネットワークトラフィックに使うインターフェースを指定します。
lxc.net.[i].l2proxy
レイヤ 2 IP 近隣プロキシエントリを、コンテナの IP アドレスに対応する lxc.net.[i].link インター
フェースに追加するかどうかを制御します。0 か 1 が設定でき、デフォルトは 0 です。 IPv4 アドレスで使
う場合は、次の sysctl 設定が必要です: net.ipv4.conf.[link].forwarding=1 IPv6 アドレスで使う場合
は、次の sysctl 設定が必要です: net.ipv6.conf.[link].proxy_ndp=1 net.ipv6.conf.[link].forwarding=1
lxc.net.[i].mtu
インターフェースに対する MTU を指定します。
lxc.net.[i].name
インターフェース名は動的に割り当てられます。しかし、もしコンテナが使用する設定ファイルが一般的な名
前を使用するために、他の特定の名前が必要であれば (例えば eth0 など)、コンテナ内のインターフェース
は、このオプションで指定した名前にリネームされます。
lxc.net.[i].hwaddr
仮想インターフェースの MAC アドレスは、デフォルトでは動的に割り当てられます。しかし、MAC アドレス
の衝突や、リンクローカルIPv6 アドレスを常に同じにした場合などは、このオプションが必要です。アドレ
ス中の "x" という文字は、ランダムな値に置き換えられます。これによりテンプレートに hwaddr を設定す
ることが可能になります。
lxc.net.[i].ipv4.address
仮想インターフェースに割り当てる ipv4 アドレスを指定します。複数行により複数の ipv4 アドレスを指定
します。このアドレスは x.y.z.t/m というフォーマットで指定します。例) 192.168.1.123/24 IP アドレス
のあとにオプションでブロードキャストアドレスを指定できます。例）192.168.1.123/24 255.255.255.255
指定しなければ IP アドレスから自動的に計算されます。
lxc.net.[i].ipv4.gateway
コンテナでゲートウェイとして使う IPv4 アドレスを指定します。アドレスは x.y.z.t というフォーマット
です。例) 192.168.1.123 auto という特別な値を指定できます。これは (lxc.net.[i].link で指定した) ブ
リッジインターフェースの最初のアドレスを使用し、それをゲートウェイに使うという意味になります。auto
はネットワークタイプとして veth、macvlan、ipvlan を指定している時だけ有効となります。 特別な値であ
る dev も設定できます。これはデバイスのルートとしてデフォルトゲートウェイを設定するという意味で
す。これは主に、IPVLAN のようなレイヤ 3 のネットワークモードで使用します。
lxc.net.[i].ipv6.address
仮想インターフェースに割り当てる ipv6 アドレスを指定します。複数行により複数の ipv6 アドレスを指定
します。このアドレスは x::y/m というフォーマットで指定します。例)
2003:db8:1:0:214:1234:fe0b:3596/64
lxc.net.[i].ipv6.gateway
コンテナでゲートウェイとして使う IPv6 アドレスを指定します。アドレスは x::y というフォーマットで
す。例) 2003:db8:1:0::1 auto という特別な値を記述する事も可能です。これは (lxc.net.[i].link で指定
した) ブリッジインターフェースの最初のアドレスを使用し、それをゲートウェイに使うという意味になりま
す。auto はネットワークタイプとして veth、macvlan、ipvlan を指定している時だけ有効となります。 特
別な値である dev も設定できます。これはデバイスのルートとしてデフォルトゲートウェイを設定するとい
う意味です。これは主に、IPVLAN のようなレイヤ 3 のネットワークモードで使用します。
lxc.net.[i].script.up
ホスト側から使われる、ネットワークの作成と設定が済んだ後に実行するスクリプトを指定します。
すべてのフックで追加の情報が使えます。以下の情報がスクリプトに提供されます:
• LXC_HOOK_TYPE: フックタイプ。'up' か 'down' のいずれかです
• LXC_HOOK_SECTION: セクションタイプとして 'net' が設定されます
• LXC_NET_TYPE: ネットワークタイプ。有効なネットワークタイプのうちのひとつです (例: 'vlan',
'macvlan', 'ipvlan', 'veth')
• LXC_NET_PARENT: ホスト上の親デバイス名。これはネットワークタイプが 'macvlan'、'veth'、'phys' の
どれかのときだけ設定されます
• LXC_NET_PEER: ホスト上のピアデバイス名。これはネットワークタイプが 'veth' の場合のみ設定されま
す。この情報は lxc.hook.version が 1 に設定されている場合のみ設定されます
この情報が環境変数の形で提供されるか、スクリプトへの引数の形で提供されるかは lxc.hook.version の値によっ
て決まります。もし lxc.hook.version が 1 に設定されている場合は、環境変数の形で提供されます。もし 0 が設
定されている場合は、スクリプトへの引数として提供されます。
スクリプトからの標準出力は debug レベルでロギングされます。標準エラー出力はロギングされません。しか
し、フックの標準エラー出力を標準出力にリダイレクトすることにより保存することは可能です。
lxc.net.[i].script.down
ホスト側から使われる、ネットワークを破壊する前に実行するスクリプトを指定します。
すべてのフックで追加の情報が使えます。以下の情報がスクリプトに提供されます:
• LXC_HOOK_TYPE: フックタイプ。'up' か 'down' のいずれかです
• LXC_HOOK_SECTION: セクションタイプとして 'net' が設定されます
• LXC_NET_TYPE: ネットワークタイプ。有効なネットワークタイプのうちのひとつです (例: 'vlan',
'macvlan', 'ipvlan', 'veth')
• LXC_NET_PARENT: ホスト上の親デバイス名。これはネットワークタイプが 'macvlan'、'veth'、'phys' の
どれかのときだけ設定されます
• LXC_NET_PEER: ホスト上のピアデバイス名。これはネットワークタイプが 'veth' の場合のみ設定されま
す。この情報は lxc.hook.version が 1 に設定されている場合のみ設定されます
この情報が環境変数の形で提供されるか、スクリプトへの引数の形で提供されるかは lxc.hook.version の値によっ
て決まります。もし lxc.hook.version が 1 に設定されている場合は、環境変数の形で提供されます。もし 0 が設
定されている場合は、スクリプトへの引数として提供されます。
スクリプトからの標準出力は debug レベルでロギングされます。標準エラー出力はロギングされません。しか
し、フックの標準エラー出力を標準出力にリダイレクトすることにより保存することは可能です。
新しい擬似端末のインスタンス (DEVPTS)
さらに厳しい隔離のために、コンテナは自身のプライベートな pseudo tty (擬似端末) を持つことが可能です。
lxc.pty.max
もし設定された場合、コンテナは新しい pseudo tty インスタンスを持ち、それを自身のプライベートとしま
す。 この値は pty インスタンスに許可される pseudo tty の最大数を指定します (この制限はまだ実装され
ていません)。
コンテナのシステムコンソール
コンテナでルートファイルシステムを持つように設定されており、inittab ファイルでコンソールの使用が設定され
ている場合、このコンソールの出力がどこになされるのかを指定したいと思うでしょう。
lxc.console.buffer.size
このオプションを設定すると、liblxc はインメモリのリングバッファを割り当てます。コンテナのコンソー
ルはリングバッファに出力されます。リングバッファは少なくとも標準ページサイズの大きさでなければなり
ません。ページサイズより小さい値を与えた場合は、liblxc はページサイズのリングバッファを割り当てま
す。ページサイズは通常は 4KB です。 'auto' を指定すると、liblxc は 128KB のリングバッファを割り当
てます。 リングバッファサイズを数値指定する場合、値がバイトに変換されるときに 2 の累乗になりま
す。サイズ接頭辞付きの単位として 'KB'、'MB'、'GB' が使えます。(この場合の変換は 1024 の倍数に基づ
いています。つまり 'KB' == 'KiB'、'MB' == 'MiB'、'GB' == 'GiB' という意味です。加えて、単位の大文
字小文字は無視されます。すなわち 'kB'、'KB'、'Kb' は同一に扱われます。)
lxc.console.size
liblxc は lxc.console.logfile で指定したコンソールログのサイズを、このオプションで設定した値に制限
します。ログファイルのサイズは少なくとも標準ページサイズでなければなりません。ページサイズ以下の値
を設定した場合は、liblxc はログファイルのサイズをページサイズに設定します。ページサイズは通常は
4KB です。 'auto' を指定すると、liblxc はログファイルのサイズを 128KB に制限します。 ログファイル
サイズの値を数値指定する場合、値がバイトに変換されるときに 2 の累乗になります。サイズ接頭辞付きの
単位として 'kB'、'MB'、'GB' が使えます。(この場合の変換は 1024 の倍数に基づいています。つまり 'kB'
== 'KiB'、'MB' == 'MiB'、'GB' == 'GiB' という意味です。加えて、単位の大文字小文字は無視されま
す。すなわち 'kB'、'KB'、'Kb' は同一に扱われます。) ディスク上のコンソールリングバッファとミラーに
なるようにしたい場合は、lxc.console.size と lxc.console.buffer.size の値を同じ値に設定します。
lxc.console.logfile
コンソール出力を書き込むファイルのパスを指定します。ディスクに保存されるリングバッファログと異な
り、このファイルはサイズが大きくなり続けるので、ファイルがローテートや削除されない限りは、ユーザの
ディスクをいっぱいにしてしまう可能性があります。この問題は、インメモリのリングバッファオプションで
ある、lxc.console.buffer.size と lxc.console.buffer.logfile を使うことでも回避できます。
lxc.console.rotate
lxc.console.logfile で指定したコンソールログファイルをローテートするかどうかを指定します。ユーザは
ログファイルをローテートするように API リクエストを送ることができます。古いログファイルは、元の
ファイル名と同じ名前のファイルに ".1" というサフィックスが付け加わります。 ユーザがコンソールログ
でディスクがいっぱいになるのを防ぐには、ログファイルをローテートし、不要なログファイルを削除してく
ださい。この問題はインメモリのリングバッファオプションである lxc.console.buffer.size と
lxc.console.buffer.logfile を使うことでも防げます。
lxc.console.path
コンソールを割り当てるデバイスのパスを指定します。'none' というキーワードは、単純にコンソールを無
効にします。 'none' を指定し、コンテナ内のコンソールに対するデバイスノードを /dev/console に作成す
るか、もしくはホストの /dev/console をコンテナ内の /dev/console に bind mount する場合、そのコンテ
ナはホストの /dev/console へ直接アクセスを行うことに注意が必要です。 そのコンテナがデバイスへの書
き込み権を持っている場合は危険ですので、注意してこの指定を使用する必要があります。
TTY を通したコンソール
このオプションはコンテナが root ファイルシステムを持つように設定されており、inittab ファイルで tty 上に
getty の起動が設定されている場合に役に立ちます。 このオプションはコンテナで利用できる tty の数を指定しま
す。 inittab ファイルに設定する getty の数は、このオプションの指定する tty の数より大きくしてはいけませ
ん。 さもなければ、超過した分の getty セッションはコンソールか /var/log/messages にうっとうしいメッセージ
を生死を表示しながら、永久に生死を繰り返すでしょう。
lxc.tty.max
コンテナに作成出来る tty の数を指定します。
コンソールデバイスの位置
LXC のコンソールはホストによって作られ、コンテナ内で要求されたデバイスに bind マウントされた Unix98 PTY
経由で提供されます。 デフォルトでは /dev/console と /dev/ttyN に bind マウントされます。 これはゲスト内で
のパッケージのアップグレードを妨げる可能性があります。 なので /dev 以下のディレクトリを指定することができ
ます。 LXC はこのディレクトリ以下にファイルを作成し、これらのファイルを bind マウントします。 そして、こ
れらの (作成された) ファイルは /dev/console と /dev/ttyN にシンボリックリンクされます。 シンボリックリン
クを消去したり置き換えたりすることは可能ですから、パッケージのアップグレードは成功します。
lxc.tty.dir
コンテナのコンソールデバイスを作成するための /dev 以下のディレクトリを指定します。 LXC は
/dev/console に対する bind mount や /dev/console デバイスノードをこのディレクトリ以下に移動するこ
とに注意が必要です。
/DEV ディレクトリ
デフォルトでは、lxc はコンテナの /dev 以下に fd, stdin, stdout, stderr のシンボリックリンクを作成します
が、自動的にはデバイスノードのエントリは作成しません。 これは、コンテナの rootfs で必要な設定を行えるよう
にするものです。 lxc.autodev が 1 に設定されている場合、コンテナの rootfs をマウントした後、LXC は新しい
tmpfs を /dev 以下にマウントします (デフォルトでは 500k 制限でマウント、lxc.autodev.tmpfs.size で指定可
能)。 そして初期デバイスの最小限のセットを作成します。 これは、"systemd" ベースの "init" 環境のコンテナを
起動する時に通常必要ですが、他の環境の場合はオプショナルなものです。 コンテナの /dev ディレクトリ内の追加
デバイスは lxc.hook.autodev フックを使用して作成されます。
lxc.autodev
コンテナの起動時に LXC が /dev をマウントして最小限の /dev を作成するのを止めるには、この値を 0 に
設定してください。
lxc.autodev.tmpfs.size
この設定で /dev tmpfs のサイズを指定します。 デフォルト値は 500000 (500K) です。このパラメータを値
なしで使うと、デフォルト値が使われます。
マウントポイント
マウントポイントセクションは、マウントするための区別された場所を指定します。 これらのマウントポイント
は、コンテナだけに見え、コンテナ外で実行されるプロセスから見えることはありません。 例えば、/etc や /var
や /home をマウントするときに役に立つでしょう。
注意: 通常 LXC は、マウント対象と相対パス指定のバインドマウントを、適切にコンテナルート以下に閉じ込めま
す。 これは、ホストのディレクトリやファイルに対して重ね合わせを行うようなマウントによる攻撃を防ぎま
す。(絶対パス指定のマウントソース中の各パスがシンボリックリンクである場合は無視されます。) しかし、もしコ
ンテナの設定が最初に、/home/joe のようなコンテナユーザのコントロール配下にあるディレクトリを、コンテナ中
のある path にマウントし、その後 path 以下でマウントが行われるような場合、コンテナユーザがタイミングを見
計らって自身のホームディレクトリ以下でシンボリックリンクを操作するような TOCTTOU 攻撃が成立する可能性があ
ります。
lxc.mount.fstab
マウント情報の書かれた fstab フォーマットで書かれたファイルの場所を指定します。 マウントする場所は
相対バスで書くことができます。そして、ほとんどの場合にコンテナの root からの相対パスとなるはずで
す。例えば、以下のように書きます。
proc proc proc nodev,noexec,nosuid 0 0
この例は、root ファイルシステムがどこにあっても、コンテナの /proc 以下に proc ファイルシステムをマ
ウントします。これは、ブロックデバイスがバックエンドのファイルシステムだけでなく、コンテナのクロー
ンにも柔軟に対応できます。
ファイルシステムがイメージファイルやブロックデバイスからマウントされている場合、3 つ目のフィールド
(fs_vfstype) は mount(8) のように auto を指定することはできず、明確に指定しなければいけません。
lxc.mount.entry
fstab フォーマットの一行と同じフォーマットのマウントポイントの指定をします。 加えて、LXC では
rshared や rprivate といったマウント・プロパゲーションオプションと、独自の 3 つのマウントオプショ
ンが使えます。 optional は、マウントが失敗しても失敗を返さずに無視します。 create=dir と
create=file は、マウントポイントをマウントする際にディレクトリもしくはファイルを作成します。
relative を指定すると、マウントされたコンテナルートからの相対パスとして取得されます。
dev/null proc/kcore none bind,relative 0 0
は dev/null を ${LXC_ROOTFS_MOUNT}/dev/null と展開し、コンテナ内の proc/kcore にマウントします。
lxc.mount.auto
標準のカーネルファイルシステムで自動的にマウントするものを指定します。 これは劇的に設定を容易にす
る可能性があります。
• proc:mixed (or proc): /proc を読み書き可能でマウントします。 ただし、/proc/sys と
/proc/sysrq-trigger は、セキュリティとコンテナの隔離の目的でリードオンリーで再マウントされます。
• proc:rw: /proc を読み書き可能でマウントします。
• sys:mixed (or sys): /sys/devices/virtual/net のみ書き込み可能で、その他の /sys はリードオンリー
でマウントします。
• sys:ro: /sys を、セキュリティとコンテナの隔離の目的でリードオンリーでマウントします。
• sys:rw: /sys を読み書き可能でマウントします。
• cgroup:mixed: /sys/fs/cgroup を tmpfs でマウントし、そのコンテナの追加が行われた全ての階層に対す
るディレクトリを作成し、それらの階層内に cgroup 名でサブディレクトリを作成し、そのコンテナ自身の
cgroup をそのディレクトリにバインドマウントします。コンテナは自身の cgroup ディレクトリに書き込
みが可能ですが、親ディレクトリはリードオンリーで再マウントされているため書き込めません。
• cgroup:mixed:force: force を指定すると、LXC はあらゆる状況でコンテナのための cgroup マウントを実
行します。それ以外は cgroup:mixed と同様です。これは主に cgroup 名前空間が有効な場合に便利で
す。この場合は完全に安全ですので、LXC は通常コンテナの init バイナリが cgroup をマウントしたまま
の状態にしておきます。
• cgroup:ro: cgroup:mixed と同様にマウントされますが、全てリードオンリーでマウントされます。
• cgroup:ro:force: force を指定すると、LXC はあらゆる状況でコンテナのための cgroup マウントを実行
します。それ以外は cgroup:ro と同様です。これは主に cgroup 名前空間が有効な場合に便利です。この
場合は完全に安全ですので、LXC は通常コンテナの init バイナリが cgroup をマウントしたままの状態に
しておきます。
• cgroup:rw: cgroup:mixed と同様にマウントされますが、全て読み書き可能でマウントされます。 コンテ
ナ自身の cgroup に至るまでのパスも書き込み可能になることに注意が必要ですが、cgroup ファイルシス
テムにはならず、 /sys/fs/cgroup の tmpfs の一部分になるでしょう。
• cgroup:rw:force: force を指定すると、LXC はあらゆる状況でコンテナのための cgroup マウントを実行
します。それ以外は cgroup:rw と同様です。これは主に cgroup 名前空間が有効な場合に便利です。この
場合は完全に安全ですので、LXC は通常コンテナの init バイナリが cgroup をマウントしたままの状態に
しておきます。
• cgroup (マウントオプションなしの場合): コンテナが CAP_SYS_ADMIN ケーパビリティを保持している場
合、cgroup:rw となります。保持していない場合、cgroup:mixed となります。
• cgroup-full:mixed: /sys/fs/cgroup を tmpfs でマウントし、そのコンテナの追加が行われた全ての階層
構造に対するディレクトリを作製し、ホストからコンテナまでの階層構造を全てバインドマウントし、コン
テナ自身の cgroup を除いてリードオンリーにします。 cgroup と比べると、コンテナ自身の cgroup に至
るまでの全てのパスが tmpfs の下層のシンプルなディレクトリとなり、コンテナ自身の cgroup の外では
リードオンリーになりますが、/sys/fs/cgroup/$hierarchy はホストの全ての cgroup 階層構造を含みま
す。 これにより、コンテナにはかなりの情報が漏洩します。
• cgroup-full:mixed:force: force を指定すると、LXC はあらゆる状況でコンテナのための cgroup マウン
トを実行します。それ以外は cgroup-full:mixed と同様です。これは主に cgroup 名前空間が有効な場合
に便利です。この場合は完全に安全ですので、LXC は通常コンテナの init バイナリが cgroup をマウント
したままの状態にしておきます。
• cgroup-full:ro: cgroup-full:mixed と同様にマウントされますが、全てリードオンリーでマウントされま
す。
• cgroup-full:ro:force: force を指定すると、LXC はあらゆる状況でコンテナのための cgroup マウントを
実行します。それ以外は cgroup-full:ro と同様です。これは主に cgroup 名前空間が有効な場合に便利で
す。この場合は完全に安全ですので、LXC は通常コンテナの init バイナリが cgroup をマウントしたまま
の状態にしておきます。
• cgroup-full:rw: cgroup-full:mixedと同様にマウントされますが、全て読み書き可能でマウントされま
す。 この場合、コンテナは自身の cgroup から脱出する可能性があることに注意してください (コンテナ
が CAP_SYS_ADMIN を持ち、自身で cgroup ファイルシステムをマウント可能なら、いずれにせよそのよう
にするかもしれないことにも注意してください)。
• cgroup-full:rw:force: force を指定すると、LXC はあらゆる状況でコンテナのための cgroup マウントを
実行します。それ以外は cgroup-full:rw と同様です。これは主に cgroup 名前空間が有効な場合に便利で
す。この場合は完全に安全ですので、LXC は通常コンテナの init バイナリが cgroup をマウントしたまま
の状態にしておきます。
• cgroup-full (マウントオプションなしの場合): コンテナが CAP_SYS_ADMIN ケーパビリティを保持してい
る場合、cgroup-full:rw となります。保持していない場合、cgroup-full:mixed となります。
cgroup 名前空間が有効の場合、cgroup の自動マウントの指定はどれも無視されます。これは、コンテナが自身で
ファイルシステムをマウントするため、自動マウントがコンテナの init を混乱させる可能性があるためです。
cgroup ファイルシステムの自動マウントが有効の場合、/sys/fs/cgroup 以下の tmpfs は常に読み書き可能でマウン
トされることに注意が必要です (しかし :mixed と :ro の場合は、個々の階層の /sys/fs/cgroup/$hierarchy は読
み込み専用となるでしょう)。これは Ubuntu の mountall(8) コマンドの特異な動きに対処するためのものです。特
異な動きとは、/sys/fs/cgroup が読み込み専用でマウントされた状態で、コンテナが CAP_SYS_ADMIN を持たない場
合、/sys/fs/cgroup を読み書き可能で再マウントしようとしてできないため、コンテナのブート時にユーザからの入
力を待ってしまうというものです。
例:
lxc.mount.auto = proc sys cgroup
lxc.mount.auto = proc:rw sys:rw cgroup-full:rw
ルートファイルシステム
コンテナのルートファイルシステムは、ホストのルートファイルシステムと異なるようにすることも可能です。
lxc.rootfs.path
コンテナのルートファイルシステムを指定します。 この値はイメージファイル、ディレクトリ、ブロックデ
バイスのどれかを取ることができます。 もし指定されない場合、コンテナはホストとルートファイルシステ
ムを共有します。
ディレクトリ、単純なブロックデバイスのバックエンドを持つコンテナの場合、パス名を使うことができま
す。 もし rootfs が nbd デバイスの場合、nbd:file:1 という指定は file を nbd デバイスとして使用
し、その 1 番目のパーティションが rootfs としてマウントされます。 nbd:file という指定は、nbd デバ
イス自身をマウントします。 overlayfs:/lower:/upper という指定は、rootfs は /lower という読み込み専
用でマウントされるディレクトリの上に、/upper というディレクトリを読み書き可能で重ね合わせてマウン
トします。 overlayfs は、複数の /lower ディレクトリを指定できます。 loop:/file は /file を loop デ
バイスとして使用し、loop デバイスをマウントします。
lxc.rootfs.mount
root ファイルシステムの変更の前に、lxc.rootfs.path を再帰的にどこにバインドするのかを指定しま
す。これは pivot_root(8) システムコールが確実に成功する事を保証します。 どんなディレクトリでも良
く、デフォルトでも通常は動くはずです。
lxc.rootfs.options
rootfs をマウントするときに使うマウントオプション。マウントオプションのフォーマットは fstab で使う
フォーマットと同じです。 加えて、LXC では独自の idmap= マウントオプションが使えます。このオプショ
ンを使うと、LXC に対してコンテナの rootfs を idmapped マウントするように指示できます。 これは、コ
ンテナが使うユーザー名前空間の ID マッピングと一致させるために、コンテナの rootfs を再帰的に chown
したくない場合に役に立ちます。代わりに idmapped マウントが使えます。 idmap= の引数は、LXC が開いて
rootfs を idmap するのに使うユーザー名前空間ファイルを指すパス、もしくは "container" という特別な
値のどちらかです。"container" という値は、コンテナのユーザー名前空間を使って rootfs を idmap する
ように LXC に指示します。
lxc.rootfs.managed
LXC がコンテナのストレージを管理していない場合は、この値を 0 に設定します。 0 に設定すると、LXC は
コンテナのストレージを変更しません。デフォルト値は 1 です。
CONTROL GROUP ("CGROUP")
CONTROL GROUP セクションは、(lxc とは) 別のサブシステムの設定を含みます。 lxc は、このサブシステム名の正
しさはチェックしません。 実行時のエラーを検出するのに不便ですが、別の将来のサブシステムをサポート出来ると
いう有利な点もあります。
カーネルにおける cgroup 実装は長年にわたって大きく変化してきました。 Linux 4.5 で新しい cgroup ファイルシ
ステムのサポートが追加されました。通常は "cgroup2" や "unified hierarchy"（単一階層構造） と呼ばれていま
す。 それ以来、通常は古い cgroup ファイルシステムは "cgroup1" や "legacy hierarchies"（レガシー階層構
造）と呼ばれています。 この 2 つのバージョンの違いについての詳細な説明は、cgroup のマニュアルページをご覧
ください。
LXC は cgroup1（レガシー階層構造）と cgroup2（単一階層構造）に対する設定を、異なる設定プレフィックスを
使って区別しています。 cgroup1 に対する設定を変更するには lxc.cgroup. というプレフィックスを使う必要があ
り、cgroup2 の設定を変更するには lxc.cgroup2. を使う必要があります。 LXC は、cgroup2 だけが使われているシ
ステム上の lxc.cgroup. を無視します。逆に cgroup1 だけが使われているシステム上の lxc.cgroup2. を無視しま
す。
cgroup 階層の本質は、プロセスを階層的に構造化する方法です。通常は、cgroup 階層では 1 つ以上の「コントロー
ラー」が有効になっています。 通常、cgroup 階層の「コントローラー」は階層に従って特定のタイプのシステムリ
ソースを分配する役割を果たします。 コントローラーには "pids" コントローラー、"cpu" コントロー
ラー、"memory" コントローラーなどがあります。 しかし、システムリソースの分配するという役割に該当しないコ
ントローラーもあります。このようなコントローラーは「ユーティリティー」コントローラーと呼ばれたりします。
ユーティリティーコントローラーの 1 つにデバイスコントローラーがあります。このコントローラーはシステムリ
ソースを分配する代わりにデバイスへのアクセスを管理できます。
cgroup1 では、デバイスコントローラーは他の多くのコントローラーと同様に、書き込みできるファイルのセットと
して実装されていました。 これらのファイルは "devices.allow" と "devices.deny" という名前のファイルでし
た。レガシーデバイスコントローラーは「許可リスト（allowlists）」と「拒否リスト（denylists）」の両方を実装
できました。
許可リスト（allowlist）とは、すべてのデバイスへのアクセスをブロックするデバイスプログラムです。特定のデバ
イスへのアクセスを行うには、特定のデバイスもしくはデバイスクラスに対する「許可ルール（allow rules）」を指
定する必要があります。 一方、拒否リスト（denylist）はデフォルトですべてのデバイスへのアクセスを許可するデ
バイスプログラムです。特定のデバイスへのアクセスを拒否するには、特定のデバイスもしくはデバイスクラスに対
する「拒否ルール（deny rules）」を指定する必要があります。
cgroup2 では、デバイスコントローラーの実装が完全に変わりました。読み書きするファイルの代わり
に、BPF_PROG_TYPE_CGROUP_DEVICE の eBPF プログラムを cgroup にアタッチできます。 カーネルの実装が完全に変
わったのにもかかわらず、LXC は cgroup1 のデバイスコントローラーと cgroup2 の eBPF ベースのデバイスコント
ローラーで同じセマンティクスに従えるようにしています。 このあとの段落では、cgroup2 の eBPF デバイスコント
ローラーに対するセマンティクスを説明します。
先に述べたように、cgroup2 の eBPF ベースのデバイスコントローラーに対するデバイスルールを指定するフォー
マットは、cgroup1 のデバイスコントローラーと同じです。ただし、設定キーのプレフィックスは変更されていま
す。 具体的には、cgroup1 のデバイスコントローラーに対するデバイスルールは lxc.cgroup.devices.allow と
lxc.cgroup.devices.deny を使って指定します。一方、cgroup2 の eBPF ベースのコントローラーでは
lxc.cgroup2.devices.allow と lxc.cgroup2.devices.deny を使わなければなりません。
• 拒否リスト（denylist）のデバイスルール
lxc.cgroup2.devices.deny = a
は、カーネルに対してデフォルトですべてのデバイスへのアクセスをブロックするように LXC が指示します。 デ
バイスへのアクセスを許可するには、デバイスに対する許可ルールを lxc.cgroup2.devices.allow を使って追加す
る必要があります。これは「許可リスト」デバイスプログラムとして参照されます。
• 許可リスト（allowlist）のデバイスルール
lxc.cgroup2.devices.allow = a
は、カーネルに対してすべてのデバイスへのアクセスをデフォルトで許可するように LXC が指示します。 デバイ
スへのアクセスを拒否するには、デバイスに対する拒否ルールを lxc.cgroup2.devices.deny を使って追加する必
要があります。これは「拒否リスト」デバイスプログラムとして参照されます。
• 前述の 2 つのルールのいずれかを指定すると、それ以前に指定していたルールがすべてクリアされます。つま
り、デバイスリストがリセットされます。
• 許可リストプログラムが要求される場合、つまりデフォルトですべてのデバイスへのアクセスがブロックされてい
る場合、個別のデバイスやデバイスクラスへの拒否ルールを指定しても無視されます。
• 拒否リストプログラムが要求される場合、つまりデフォルトですべてのデバイスへのアクセスが許可されている場
合、個別のデバイスやデバイスクラスへの許可ルールを指定しても無視されます。
例えば、次のようなルールの組
lxc.cgroup2.devices.deny = a
lxc.cgroup2.devices.allow = c *:* m
lxc.cgroup2.devices.allow = b *:* m
lxc.cgroup2.devices.allow = c 1:3 rwm
は、許可リスト（allowlist）デバイスプログラムを実装します。つまり、カーネルはこのリストで許可されるように
設定されていないすべてのデバイスへのアクセスをブロックします。 このプログラムでは、すべてのキャラクターデ
バイスとブロックデバイスが作成できますが、読み書きは /dev/null に対してしか行なえません。
代わりに先のルールから次のようなルールの組に変更したとすると、
lxc.cgroup2.devices.allow = a
lxc.cgroup2.devices.deny = c *:* m
lxc.cgroup2.devices.deny = b *:* m
lxc.cgroup2.devices.deny = c 1:3 rwm
LXC はカーネルに拒否リスト（denylist）の実装を指示します。つまりカーネルはこのリストで拒否を指定していな
いすべてのデバイスへのアクセスを許可します。 このプログラムでは、キャラクターデバイスとブロックデバイスは
作成できません。そして /dev/null の読み書きと作成は許可されません。
ここで、同じプログラムでも、前述のようにデバイスのプログラムタイプを決定するような「グローバルルール」が
続いている場合を考えてみましょう。
lxc.cgroup2.devices.allow = a
lxc.cgroup2.devices.deny = c *:* m
lxc.cgroup2.devices.deny = b *:* m
lxc.cgroup2.devices.deny = c 1:3 rwm
lxc.cgroup2.devices.allow = a
最後の行は、デバイスプログラムのタイプを変更せずに、LXC がデバイスリストをリセットしてしまいます。
次のように指定した場合、
lxc.cgroup2.devices.allow = a
lxc.cgroup2.devices.deny = c *:* m
lxc.cgroup2.devices.deny = b *:* m
lxc.cgroup2.devices.deny = c 1:3 rwm
lxc.cgroup2.devices.deny = a
前の例と違って最後の行によって、LXC はデバイスリストをリセットし、許可リスト（allowlist）から拒否リスト
（denylist）にプログラムを変更してしまいます。
lxc.cgroup.[control name].[controller file]
レガシー cgroup 階層 (cgroup v1) に設定する値を指定します。コントローラー名は control group そのま
まの名前です。 許される名前や値の書式は LXC が指定することはなく、コンテナが実行された時に実行され
ている Linux カーネルの機能に依存します。 例えば lxc.cgroup.cpuset.cpus のようになります。
lxc.cgroup2.[controller name].[controller file]
単一の cgroup 階層 (cgroup v2) に設定する値を指定します。 許される名前や値の書式は LXC が指定する
ことはなく、コンテナが実行された時に実行されている Linux カーネルの機能に依存します。 例えば
lxc.cgroup2.memory.high のようになります。
lxc.cgroup.dir
コンテナの cgroup を作成するパスやディレクトリを指定します。 例えば、"c1" という名前のコンテナで
lxc.cgroup.dir = my-cgroup/first のように設定すると、"my-cgroup" のサブ cgroup のようにコンテナの
cgroup を作成します。 例えば、ユーザのカレントの cgroup である "my-user" が cgroup v1 階層にある
cpuset コントローラの root cgroup 内に存在する場合、この設定は "/sys/fs/cgroup/cpuset/my-user/my-
cgroup/first/c1" という cgroup をこのコンテナ向けに作成します。 存在しない cgroup は LXC が作成し
ますが、ユーザがカレントの cgroup に書き込み権を持っていることが前提となります。
lxc.cgroup.dir.container
これは lxc.cgroup.dir と同様の設定ですが、かならず lxc.cgroup.dir.monitor と同時に使わなければなり
ません。そして、設定はコンテナの cgroup パスにのみ影響を与えます。このオプションは lxc.cgroup.dir
と同時に設定できません。コンテナがアタッチされる最終的なパスは lxc.cgroup.dir.container.inner オプ
ションによりさらに変更される可能性があります。
lxc.cgroup.dir.monitor
このオプションは、モニタプロセスに対してlxc.cgroup.dir.container と同様の働きをします。
lxc.cgroup.dir.monitor.pivot
コンテナ終了時に、モニタープロセスの PID がここで指定した cgroup にアタッチされます。 コンテナ終了
時に、他の cgroup パスが確実に適切に削除されるように、ここに設定するパスは他で設定した cgroup ディ
レクトリのサブパスにすべきではありません。
lxc.cgroup.dir.container.inner
cgroup 名前空間が作られる追加のサブディレクトリを指定します。このオプションを使うと、cgroup の制限
は lxc.cgroup.dir.container で指定した外部パスに適用されます。lxc.cgroup.dir.container はコンテナ
内部からアクセスできないため、特権コンテナに対する制限を上書きできない方法でよりよい方法で強制でき
ます。 このオプションは lxc.cgroup.dir.container と lxc.cgroup.dir.monitor と同時に指定したときの
み機能し、それ以外の場合は効果がありません。
lxc.cgroup.relative
LXC に root cgroup へのエスケープを行わないように指示するには、この値を 1 に設定してください。 こ
れにより、ユーザは cgroup2 と systemd が強制する制限を遵守するのが容易になります。 具体的には、こ
れにより LXC コンテナを systemd のサービスとして実行できます。
ケーパビリティ
コンテナが root 権限で実行されていても、コンテナ内ではケーパビリティ (capabilities) を削除する事は可能で
す。
lxc.cap.drop
コンテナ内で削除するケーパビリティ (capability) を指定します。 一行でスペース区切りで複数のケーパ
ビリティを指定することも可能です。 指定は、"CAP_" というプレフィックスなしで、小文字でケーパビリ
ティを指定します。 例えば、CAP_SYS_MODULE というケーパビリティは sys_module と指定する必要がありま
す。 詳しくは以下を参照してください。 capabilities(7) この設定を、値を指定しない状態で使った場
合、それ以前に指定された削除対象のケーパビリティの指定をすべてクリアします (lxc.cap.drop に何も指
定しない状態になります)。
lxc.cap.keep
コンテナ内で維持するケーパビリティを指定します。指定した以外の全てのケーパビリティはドロップされま
す。 特別な値 "none" が指定されている時点で、lxc はこの時点で保持することになっている全てのケーパ
ビリティをクリアします。"none" を単独で使用するとすべてのケーパビリティを削除できます。
名前空間
名前空間は clone したり (lxc.namespace.clone)、keep したり (lxc.namespace.keep)、share したり
(lxc.namespace.share.[namespace identifier]) できます。
lxc.namespace.clone
コンテナ作成時に作成する名前空間を指定します。作成する名前空間はスペース区切りのリストで指定しま
す。指定する名前空間名は、/proc/PID/ns ディレクトリ内に存在する標準の名前空間指示子でなければなり
ません。 lxc.namespace.clone を明示的に設定していない場合は、カーネルがサポートするすべての名前空
間と現在の設定が使われます。
新しいマウント、ネット、IPC 名前空間を作る場合は lxc.namespace.clone=mount net ipc と指定します。
lxc.namespace.keep
コンテナが、作成元のプロセスから継承する (新しい名前空間を作らずに元のプロセスの名前空間のまま実行
する) 名前空間を指定します。継承する名前空間はスペース区切りのリストで指定します。指定する名前空間
名は、/proc/PID/ns ディレクトリ内に存在する標準の名前空間指示子でなければなりませ
ん。lxc.namespace.keep はブラックリストを指定するオプションです。つまり、コンテナに特定の名前空間
を使い続けることを強制したい場合に便利です。
ネットワーク、ユーザ、IPC 名前空間を元のプロセスの名前空間のままで実行したい場合は
lxc.namespace.keep=user net ipc と指定します。
PID 名前空間を共有すると、ほとんどの init で動作しない可能性があることに注意してください。
コンテナが新しいユーザ名前空間をリクエストし、そのコンテナがネットワーク名前空間は継承したい場合
は、ユーザ名前空間も同様に継承する必要があることに注意してください。
lxc.namespace.share.[namespace identifier]
他のコンテナやプロセスから継承する名前空間を指定します。[namespace identifier] には、/proc/PID/ns
ディレクトリ内に現れる名前空間のひとつが入ります。
他のプロセスから名前空間を継承するには、lxc.namespace.share.[namespace identifier] の値をプロセス
の PID に設定します。例えば lxc.namespace.share.net=42 のようになります。
他のコンテナから名前空間を継承するには、lxc.namespace.share.[namespace identifier] の値をコンテナ
名に設定します。例えば lxc.namespace.share.pid=c3 のようになります。
標準の liblxc のパスとは異なるコンテナパスに存在する他のコンテナから名前空間を継承するに
は、lxc.namespace.share.[namespace identifier] をそのコンテナのフルパスで指定します。例えば
lxc.namespace.share.user=/opt/c3 のようになります。
名前空間を継承するためには、呼び出し元が継承元のプロセスまたはコンテナに対して十分な権限を持ってい
る必要があります。
システムコンテナ間での PID 名前空間の共有は、ほとんどの init システムではうまく動作しない可能性が
あることに注意が必要です。
ふたつのプロセスが異なるユーザ名前空間に存在し、そのうちのひとつが他のネットワーク名前空間を継承し
たい場合、通常はユーザ名前空間も同様に継承する必要があることに注意が必要です。
LSM で慎重に設定を追加しないで、タスクでユーザ + PID 名前空間を共有すると、そのタスクは liblxc を
呼び出したタスクの権限に昇格できることに注意が必要です。
lxc.time.offset.boot
ブートタイム(boottime)クロックの正または負のオフセット値を指定します。フォーマット
は、時(h)、分(m)、秒(s)、ミリ秒(ms)、マイクロ秒(us)、ナノ秒(ns)を指定できます。
lxc.time.offset.monotonic
monotonicクロックの正または負のオフセット値を指定します。フォーマットは、時(h)、分(m)、秒(s)、ミリ
秒(ms)、マイクロ秒(us)、ナノ秒(ns)を指定できます。
リソース制限
コンテナに対するソフトもしくはハードリミットを変更できます。非特権コンテナでは、制限を下げることしかでき
ません。明示的に指定されていないリソースは継承されます。
lxc.prlimit.[limit name]
設定したいリソースと制限値を指定します。制限値はコロンで区切られた 2 つの値で指定します。値は数値
もしくは 'unlimited' で指定します。ソフトもハードも同じ値を指定する場合は単一の値を指定できま
す。指定できる名前は、"RLIMIT_" 接頭辞がなく小文字で書かれた、"RLIMIT_" リソース名です。例え
ば、RLIMIT_NOFILE は "nofile" と指定します。詳しくは setrlimit(2) を参照してください。 値を指定せ
ずに使用した場合、lxc はこの指定以前に設定されたリソース制限をクリアします。明示的に制限が設定され
ていないリソースについては、コンテナを起動したプロセスから継承します。
SYSCTL
コンテナ用のカーネルパラメータを設定します。
lxc.sysctl.[kernel parameters name]
設定したいカーネルパラメータを指定します。指定できるパラメータは /proc/sys 以下に存在するもので
す。 すべての sysctl パラメータが仮想化（名前空間化）されているわけではないことに注意してくださ
い。仮想化されていない sysctl を設定すると、システムワイドで設定が変更されてしまいます。
sysctl(8). 値を指定しないでこの設定を指定した場合は、この設定より前に設定されたパラメータをクリア
します。
APPARMOR プロファイル
lxc が apparmor サポートでコンパイルされ、インストールされている場合で、ホストで apparmor が有効な場
合、コンテナが従って動くべき apparmor プロファイルは、コンテナの設定で指定することが可能です。 デフォルト
は、ホストのカーネルで cgroup 名前空間が使える場合は lxc-container-default-cgnsです。使えない場合は lxc-
container-default です。
lxc.apparmor.profile
コンテナが従うべき apparmor プロファイルを指定します。 コンテナが apparmor による制限を受けないよ
うに設定するには、以下のように設定します。
lxc.apparmor.profile = unconfined
もし apparmor プロファイルが変更されないままでなくてはならない場合 (ネストしたコンテナである場合
や、すでに confined されている場合) は以下のように設定します。
lxc.apparmor.profile = unchanged
もし LXC に AppArmor プロファイルを生成するように指示するには次のように設定します。
lxc.apparmor.profile = generated
lxc.apparmor.allow_incomplete
apparmor プロファイルはパス名ベースですので、多数のファイルの制限を行う際、執念深い攻撃者に対して
効果的であるためにはマウントの制限が必要です。 しかし、これらのマウントの制限は upstream のカーネ
ルではまだ実装されていません。マウントの制限なしでも、apparmor プロファイルによって予想外のダメー
ジに対する保護が可能です。
このフラグが 0 の場合 (デフォルト)、カーネルが apparmor のマウント機能をサポートしていない場合にコ
ンテナが起動しません。これはカーネルを更新した後に機能が退行したことが検出できるようにするためで
す。 不完全な apparmor の保護の下でコンテナを起動するためには、このフラグを 1 に設定してください。
lxc.apparmor.allow_nesting
1 に設定すると次のような変更が行われます。 generated な AppArmor プロファイルが使われる場合、ネス
トしたコンテナを使うのに必要な変更が含まれます。通常のマウントポイントに加えて、lxcfs のオーバーレ
イなしで、/dev/.lxc/proc と /dev/.lxc/sys が procfs と sysfs のマウントポイントに含まれます。
generated な AppArmor プロファイルが使われている場合は、直接読み書きはできません
lxc.apparmor.raw
プロファイルに加える、生の AppArmor プロファイル行のリストです。generated なプロファイルを使ってい
るときのみ有効です。
SELINUX コンテキスト
lxc が SELinux サポートでコンパイルされ、インストールされている場合で、ホストで SELinux が有効な場合、コ
ンテナが従って動くべき SELinux コンテキストは、コンテナの設定で指定することが可能です。 デフォルトは
unconfined_t であり、これは lxc がコンテキストを変えないという意味になります。 ポリシーの例と追加の情報は
/usr/share/lxc/selinux/lxc.te ファイルを参照してください。
lxc.selinux.context
コンテナが従うべき SELinux コンテキストを指定するか、unconfined_t を指定します。例えば以下のように
設定します。
lxc.selinux.context = system_u:system_r:lxc_t:s0:c22
lxc.selinux.context.keyring
コンテナのキーリングを作成する SELinux コンテキストを指定します。 デフォルトでは
lxc.selinux.context と同じになります。 lxc.selinux.context が設定されていない場合は、LXC のコンテ
キストで実行されます。
lxc.selinux.context.keyring = system_u:system_r:lxc_t:s0:c22
カーネルキーリング
Linux キーリング機能は、さまざまなカーネルコンポーネントが、セキュリティーデータ、認証キー、暗号化
キー、その他のデータをカーネルに保持またはキャッシュするための機能です。 デフォルトでは、LXC は開始したア
プリケーションのために、新しいセッションキーリングを作成します。
lxc.keyring.session
LXC による新しいセッションキーリングの作成を無効にできます。その場合、開始したアプリケーション
は、その時点のセッションキーリングを継承します。 デフォルトは 1 で、1 の場合は LXC は新しいキーリ
ングを作成します。
lxc.keyring.session = 0
SECCOMP の設定
コンテナは、起動時に seccomp プロファイルをロードすることで、利用可能なシステムコールを減らして起動するこ
とが可能です。 seccomp の設定ファイルは、1 行目がバージョン番号、2 行目がポリシーのタイプで始まる必要があ
り、その後に設定を書きます。
現時点では、バージョン番号は 1 と 2 をサポートしています。バージョン 1 では、ポリシーはシンプルなホワイト
リストですので、2 行目は "allowlist" でなければなりません。 そして残りの行には 1 行に 1 つずつ、システム
コール番号を書きます。各行のシステムコール番号がホワイトリスト化され、リストにない番号は、そのコンテナで
はブラックリストに入ります。
バージョン 2 では、ポリシーはブラックリストもしくはホワイトリストで表され、ルールごとのアクションと、ポリ
シーごとのデフォルトのアクションを設定できます。そして、アーキテクチャごとの設定と、テキストで書かれたシ
ステムコール名での設定が可能です。
以下にブラックリストのポリシーの例を示します。これは mknod 以外の全てのシステムコールが許可され、mknod が
呼ばれると、何もせずに単に 0(成功) を返します。
2
denylist
mknod errno 0
ioctl notify
アクションとして "errno" を指定すると、LXC は seccomp フィルタを登録します。これにより、指定した errno を
呼び出し元に返します。 errno の値は "errno" という単語の後に指定します。
アクションとして "notify" を指定すると、LXC は seccomp リスナーを登録し、カーネルからリスナーのファイル
ディスクリプタを取得します。 "notify" として指定しているシステムコールが作成されると、カーネルは poll イ
ベントを生成し、ファイルディスクリプタを通してメッセージを送信します。 呼び出し元はこのメッセージを読
み、引数を含めてシステムコールを調査できます。 呼び出し元はこの情報に基づき、どのアクションを取るべきかを
カーネルに知らせるメッセージを送り返すことが期待されます。 このメッセージが送られるまで、カーネルは呼び出
し元のプロセスをブロックします。読み書きするメッセージのフォーマットは seccomp 自身に記述されています。
lxc.seccomp.profile
コンテナがスタートする前にロードする seccomp の設定を含むファイルを指定します。
lxc.seccomp.allow_nesting
このオプションを 1 に設定すると、すでに seccomp プロファイルがロードされている、いないに関わら
ず、seccomp フィルタが重ね合わせられます。 これにより、ネストされたコンテナが自身の seccomp プロ
ファイルをロードできます。 デフォルト値は 0 です。
lxc.seccomp.notify.proxy
LXC が接続し、seccomp イベントを転送する UNIX ソケットを指定します。 パスは unix:/path/to/socket
もしくは unix:@socket の形式でなければなりません。 前者はパス指定の UNIX ドメインソケットを指定
し、後者は抽象 (abstract) UNIX ドメインソケットの指定です。
lxc.seccomp.notify.cookie
プロキシーされた seccomp 通知リクエストと一緒に送る追加文字列。
PR_SET_NO_NEW_PRIVS
PR_SET_NO_NEW_PRIVS を付与すると、対象の execve() は、execve() の呼び出しなしでは実行できなかったことに対
する特権を許可しなくなります (例えば、set-user-ID、set-group-ID 許可ビットや、ファイルケーパビリティが動
作しなくなります)。 一度設定されると、このビットは解除できません。このビットの設定は fork() や clone() で
生成される子プロセスにも継承され、execve() の前後で保持されます。 PR_SET_NO_NEW_PRIVS は、コンテナに適用
しようとする AppArmor プロファイルもしくは SELinux コンテキストへの変更がなされたあとに適用されます。
lxc.no_new_privs
コンテナに対して PR_SET_NO_NEW_PRIVS ビットを設定するかどうかを指定します。1 に設定すると有効にな
ります。
UID のマッピング
コンテナは、ユーザとグループの id のマッピングを持った専用のユーザ名前空間で起動することが可能です。 たと
えば、コンテナ内のユーザ id 0 を、ホストのユーザ id 200000 にマッピングすることが可能です。 コンテナの
root ユーザはコンテナ内では特権を持ちますが、ホストでは特権を持ちません。 通常は、システムコンテナは id
の範囲を要求し、それをマッピングします。 例えば、コンテナ内のユーザとグループの id 0 から 20,000 を
200,000 から 220,000 にマッピングします。
lxc.idmap
4 つの値を記述する必要があります。 最初の文字は 'u' か 'g' のどちらかで、ユーザかグループの ID の
どちらをマッピングするかを指定します。 次はコンテナのユーザ名前空間内に現れる最初のユーザ ID で
す。 その次は、そのユーザ ID のホスト上での値です。 最後は、ID のマッピングをいくつ連続して行うか
の数を指定します。
コンテナのフック
コンテナのフックは、コンテナの存続期間の色々な場面で実行することのできるプログラムやスクリプトです。
コンテナフックが実行されるとき、追加の情報が渡されます。追加の引数がコマンドライン引数で渡されるか、環境
変数経由で渡されるかを判断するのに、lxc.hook.version が使えます。引数は:
• コンテナ名
• セクション (常に 'lxc')
• フックのタイプ ('clone' や 'pre-mount' など)
• 追加の引数。clone フックの場合、lxc-clone に渡される追加の引数は、フックへの引数として追加されま
す。stop フックの場合は、コンテナの名前空間のそれぞれに対するファイルディスクリプタへのパスが、名前空間
名とともに渡されます。
次の環境変数がセットされます。
• LXC_CGNS_AWARE: コンテナで cgroup namespace が使えるかどうか
• LXC_CONFIG_FILE: コンテナの設定ファイルのパス
• LXC_HOOK_TYPE: フックのタイプ (例えば 'clone'、'mount'、'pre-mount')。この環境変数が存在するかどうかは
lxc.hook.version の値次第です。この値が 1 なら、LXC_HOOK_TYPE が設定されています。
• LXC_HOOK_SECTION: セクションタイプ (例えば 'lxc'、'net')。この環境変数が存在するかどうかは
lxc.hook.version の値次第です。この値が 1 なら、LXC_HOOK_TYPE が設定されています。
• LXC_HOOK_VERSION: フックのバージョン。この値は、コンテナの lxc.hook.version の値と同じです。もし、この
値が 0 に設定されているなら、古いスタイルのフックが使われます。もし 1 に設定されているなら、新しいスタ
イルのフックが使われます。
• LXC_LOG_LEVEL: コンテナのログレベル
• LXC_NAME: コンテナ名
• LXC_[NAMESPACE IDENTIFIER]_NS: コンテナの名前空間が参照する /proc/PID/fd/ 以下のファイルディスクリプタ
のパス。それぞれの名前空間ごとに別々の環境変数になります。これらの環境変数は lxc.hook.version が 1 に設
定されてる場合のみ設定されます。
• LXC_ROOTFS_MOUNT: マウントされた root ファイルシステムへのパス
• LXC_ROOTFS_PATH: コンテナの lxc.rootfs.path エントリ。これはマウントされた rootfs が存在する場所にはな
らないでしょう。それには LXC_ROOTFS_MOUNT を使用してください。
• LXC_SRC_NAME: clone フックの場合、元のコンテナの名前
スクリプトからの標準出力は debug レベルでロギングされます。 標準エラー出力はロギングされません。 しか
し、フックの標準エラー出力を標準出力にリダイレクトすることにより保存することは可能です。
lxc.hook.version
環境変数経由の新しいスタイルで引数を渡すには 1 に設定します。そうでなく、引数として渡すには 0 に設
定します。この設定は、古い方法でスクリプトに引数として渡されているすべてのフック引数に影響しま
す。特に、コンテナ名のセクション (例: 'lxc', 'net') とフックタイプ (例: 'clone', 'mount', 'pre-
mount') 引数に影響します。新しいスタイルのフックが使われる場合、引数は環境変数として利用できます。
コンテナ名は LXC_NAME に設定されます(これはこの設定項目に設定されている値とは関係なく設定されま
す)。セクションは LXC_HOOK_SECTION に設定されます。そしてフックタイプは LXC_HOOK_TYPE に設定されま
す。 この設定は、コンテナの名前空間を参照するファイルディスクリプタのパスをどのように渡すかにも影
響します。1 に設定した場合、名前空間ごとに別の環境変数 LXC_[NAMESPACE IDENTIFIER]_NS に設定されま
す。0 に設定すると、パスは stop フックの引数として渡されます。
lxc.hook.pre-start
コンテナの tty、コンソールの作成、マウントが実行される前に、ホストの名前空間内で実行するフック。
lxc.hook.pre-mount
コンテナのファイルシステムの名前空間で実行されますが、rootfs が設定される前に実行するフック。 これ
により rootfs の操作が可能になります。 例えば、暗号化されたファイルシステムのマウントなどです。 こ
のフック内でなされるマウントはホストには影響しません (mounts propagation を除いて)。 なので、それ
らはコンテナがシャットダウンする時に自動的にクリーンアップされます。
lxc.hook.mount
マウントが完了した後ですが、pivot_root の前にコンテナの名前空間で実行されるフック。
lxc.hook.autodev
lxc.autodev == 1 が設定されている場合で、マウントが完了し、マウント時のフックも実行された後です
が、pivot_root の前にコンテナの名前空間で実行するフック。 このフックの目的は、systemd ベースのコン
テナ向けの autodev オプションが設定されている時に、コンテナの /dev ディレクトリを設定するのを支援
することです。コンテナの /dev ディレクトリは、このフックが実行される時有効な ${LXC_ROOTFS_MOUNT}
環境変数からの相対パスとなります。
lxc.hook.start-host
コンテナのセットアップが済んだあと、コンテナの init を実行する直前に、ホストの名前空間で実行するた
めのフックです。
lxc.hook.start
コンテナの init が実行される直前にコンテナの名前空間で実行されるフック。 コンテナ内で利用可能なプ
ログラムである必要があります。
lxc.hook.stop
コンテナのシャットダウン後、コンテナの名前空間への参照とともに、ホストの名前空間で実行されるフック
です。 それぞれの名前空間に対応する追加の引数がフックに渡されます。その引数にはコロンで区切られた
名前空間のタイプ名とファイル名が含まれており、ファイル名は名前空間に対するファイルディスクリプタを
取得するのに使えます。 タイプ名は /proc/PID/ns ディレクトリ内のファイル名です。 例えば、マウント名
前空間に対応する引数は通常は mnt:/proc/PID/fd/12 のようになります。
lxc.hook.post-stop
コンテナがシャットダウンされた後にホストの名前空間で実行するフック。
lxc.hook.clone
コンテナが新しいコンテナにクローンされる際に実行されるフック。詳しくは lxc-clone(1) を参照してくだ
さい。
lxc.hook.destroy
コンテナを破壊する際に実行されるフックです。
コンテナのフックで使える環境変数
起動時のフックに設定情報を提供し、フックの機能を助けるための環境変数がいくつか利用可能です。 全ての変数が
全てのコンテキストで利用可能なわけではありません。 具体的には、全てのパスはホストシステム上のパスであ
り、そのため、lxc.hook.start フックの時点では使用できません。
LXC_NAME
LXC コンテナの名前。共通のログ環境内でのログメッセージに使うときに便利です。[-n]
LXC_CONFIG_FILE
コンテナの設定ファイルのホスト上でのパス。 これは、他の方法では得られない追加の設定情報を見つける
ために、コンテナに、元の、トップレベルの設定ファイルの位置を与えるものです。 [-f]
LXC_CONSOLE
設定されている場合のコンテナのコンソール出力のパス。 [-c] [lxc.console.path]
LXC_CONSOLE_LOGPATH
設定されている場合のコンテナのコンソールログ出力のパス。 [-L]
LXC_ROOTFS_MOUNT
初期にコンテナがマウントされる場所。 これは、コンテナインスタンスが起動するためのコンテナの rootfs
へのホスト上のパスであり、インスタンスのための移行が行われる場所です。 [lxc.rootfs.mount]
LXC_ROOTFS_PATH
rootfs.mount へマウントされるコンテナのルートへのホスト上のパスです。 [lxc.rootfs.path]
LXC_SRC_NAME
clone フックの場合のみ使われます。クローン元のコンテナ名が設定されます。
LXC_TARGET
stop フックの場合のみ使われます。コンテナのシャットダウンの場合は "stop"、リブートの場合は
"reboot" が設定されます。
LXC_CGNS_AWARE
この変数が設定されていない場合、お使いのバージョンの LXC は cgroup 名前空間を扱えません。設定され
ている場合、この値は 1 に設定されています。そして、cgroup 名前空間を扱えます。 この変数はカーネル
で cgroup 名前空間が有効であることは保証しません。この変数は lxcfs のマウントフックが使います。
ロギング
ロギングはコンテナごとに設定することが可能です。 デフォルトでは、lxc パッケージのコンパイル条件に依存
し、コンテナのスタートアップは ERROR レベルでのみロギングされ、コンテナのパス以下か、/var/log/lxc 以下の
どちらかにコンテナ名 (の後に '.log' が付与される) をもとにした名前でロギングされます。
デフォルトのログレベルとログファイルは両方とも、コンテナの設定ファイル内で指定され、デフォルトの値を上書
きします。 同様に、設定ファイルのエントリは lxc-start のコマンドラインオプションで上書きすることも可能で
す。
lxc.log.level
ログを取得するレベル。 ログレベルは 0..8 の範囲の整数です。 数字が小さいほど冗長なデバッグを意味し
ます。 具体的には、0 = trace, 1 = debug, 2 = info, 3 = notice, 4 = warn, 5 = error, 6 = critical,
7 = alert, and 8 = fatal です。 指定されない場合、レベルのデフォルトは 5 (error) で、それ以上のエ
ラーがロギングされます。
(フックスクリプトやネットワークインターフェースの起動、停止時のスクリプトのような) スクリプトが呼
ばれた時、スクリプトの標準出力は level 1 の debug でロギングされます。
lxc.log.file
ログ情報を書き込むファイル。
lxc.log.syslog
ログ情報を syslog に送ります。ログレベルとして lxc.log.level の値を使用します。指定する値は使用す
る syslog の facility です。有効な値は daemon, local0, local1, local2, local3, local4, local5,
local5, local6, local7 のいずれかです。
自動起動
自動起動オプションでは、自動起動させるコンテナと順番の設定が可能です。 このオプションは LXC ツールが直接
使用するか、ディストリビューションが提供する外部ツールが使用するかもしれません。
lxc.start.auto
コンテナを自動起動させるかどうかを設定します。 有効な値は 0(オフ) か 1(オン) です。
lxc.start.delay
コンテナを起動させた後、次のコンテナを起動させるまでにどれくらい (秒) 待つかを設定します。
lxc.start.order
自動起動させるコンテナが多数ある場合のコンテナの起動順を決めるのに使う整数を指定します。 小さい値
ほど早く起動します。
lxc.monitor.unshare
この値が 0 でない場合、コンテナが初期化される前 (pre-start フックが実行される前) にマウント名前空
間がホストから unshare されます。この機能を使う場合、スタート時に CAP_SYS_ADMIN ケーパビリティが必
要です。デフォルト値は 0 です。
lxc.monitor.signal.pdeath
lxc のモニタプロセスが終了した際に、コンテナの init プロセスに送出するシグナルを指定します。デフォ
ルトでは、lxc のモニタプロセスが終了した場合には、すべてのコンテナ内のプロセスが停止するように
SIGKILL が設定されています。 lxc のモニタプロセスが終了しても、コンテナがすべて確実に動作しつづけ
るようにするには、この値を 0 に設定します。
lxc.group
コンテナを追加したいコンテナグループ名を指定します。 複数の値を設定でき、複数回指定することもでき
ます。 設定されたグループは、関連する一連のコンテナを起動させるために使われます。
自動起動とシステムブート
コンテナはいくつでもグループに属することができ、全く属さないことも可能です。特別なグループが 2 つ存在しま
す。1 つは NULL グループです。これはどのグループにも属さないコンテナです。もう 1 つは "onboot" グループで
す。
LXC サービスが有効になった状態でシステムがブートすると、最初に "onboot" グループのメンバーである
lxc.start.auto == 1 が設定されたコンテナを起動しようとします。起動は lxc.start.order の順に起動します。
lxc.start.delay が指定されている場合、現在対象となっているコンテナに初期化の時間を与え、ホストシステムの
負荷を低減するために、次のコンテナを開始させるまでに遅延時間を与えます。 "onboot" グループのメンバーが開
始した後、LXC システムは lxc.start.auto == 1 が設定された、どのグループのメンバーでもない (NULL グループ
の) コンテナのブートを onboot グループのコンテナと同様に開始します。
コンテナの環境変数
コンテナに環境変数を渡したい場合 (環境変数はコンテナの init とその子孫全てで利用可能で
す)、lxc.environment パラメータがその用途に使えます。 機微 (センシティブ) な情報を渡さないように注意が必
要です。そのような情報を持たないコンテナ内のプロセスでこれらの環境変数が利用可能になってしまいます。環境
変数は常に /proc/PID/environ 経由で利用可能になります。
この設定項目は、設定したい環境変数ごとに 1 度ずつ、何度でも指定できます。
lxc.environment
コンテナに渡したい環境変数を指定します。 例:
lxc.environment = APP_ENV=production
lxc.environment = SYSLOG_SERVER=192.0.2.42
例
以下に紹介するいくつかの例に加えて、他の設定例が /usr/share/doc/lxc/examples にあります。
ネットワーク
この設定は、片方をブリッジである br0 と接続される veth ペアデバイスを使うコンテナを設定します (ブリッジは
管理者によりあらかじめシステム上に設定済みである必要があります)。 仮想ネットワークデバイスは、コンテナ内
では eth0 とリネームされます。
lxc.uts.name = myhostname
lxc.net.0.type = veth
lxc.net.0.flags = up
lxc.net.0.link = br0
lxc.net.0.name = eth0
lxc.net.0.hwaddr = 4a:49:43:49:79:bf
lxc.net.0.ipv4.address = 1.2.3.5/24 1.2.3.255
lxc.net.0.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3597
UID/GID のマッピング
この設定は、コンテナ内のユーザとグループ両方の id 0-9999 の範囲を、ホスト上の 100000-109999 へマッピング
します。
lxc.idmap = u 0 100000 10000
lxc.idmap = g 0 100000 10000
CONTROL GROUP
この設定は、アプリケーションのための control group をいくつか設定します。 cpuset.cpus は定義された cpu の
み使用できるように制限します。 cpus.share は、control group の (cpu) 優先度を指定します。 devices.allow
は、特定のデバイスを使用可能にします。
lxc.cgroup.cpuset.cpus = 0,1
lxc.cgroup.cpu.shares = 1234
lxc.cgroup.devices.deny = a
lxc.cgroup.devices.allow = c 1:3 rw
lxc.cgroup.devices.allow = b 8:0 rw
複雑な設定
この例は、control group を使って、複雑なネットワークスタックを作成し、新しいホスト名を指定し、いくつかの
場所をマウントし、ルートファイルシステムを変更するような複雑な設定を示します。
lxc.uts.name = complex
lxc.net.0.type = veth
lxc.net.0.flags = up
lxc.net.0.link = br0
lxc.net.0.hwaddr = 4a:49:43:49:79:bf
lxc.net.0.ipv4.address = 10.2.3.5/24 10.2.3.255
lxc.net.0.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3597
lxc.net.0.ipv6.address = 2003:db8:1:0:214:5432:feab:3588
lxc.net.1.type = macvlan
lxc.net.1.flags = up
lxc.net.1.link = eth0
lxc.net.1.hwaddr = 4a:49:43:49:79:bd
lxc.net.1.ipv4.address = 10.2.3.4/24
lxc.net.1.ipv4.address = 192.168.10.125/24
lxc.net.1.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3596
lxc.net.2.type = phys
lxc.net.2.flags = up
lxc.net.2.link = random0
lxc.net.2.hwaddr = 4a:49:43:49:79:ff
lxc.net.2.ipv4.address = 10.2.3.6/24
lxc.net.2.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3297
lxc.cgroup.cpuset.cpus = 0,1
lxc.cgroup.cpu.shares = 1234
lxc.cgroup.devices.deny = a
lxc.cgroup.devices.allow = c 1:3 rw
lxc.cgroup.devices.allow = b 8:0 rw
lxc.mount.fstab = /etc/fstab.complex
lxc.mount.entry = /lib /root/myrootfs/lib none ro,bind 0 0
lxc.rootfs.path = dir:/mnt/rootfs.complex
lxc.rootfs.options = idmap=container
lxc.cap.drop = sys_module mknod setuid net_raw
lxc.cap.drop = mac_override
SEE ALSO
chroot(1), pivot_root(8), fstab(5) capabilities(7)
SEE ALSO
lxc(7), lxc-create(1), lxc-copy(1), lxc-destroy(1), lxc-start(1), lxc-stop(1), lxc-execute(1), lxc-
console(1), lxc-monitor(1), lxc-wait(1), lxc-cgroup(1), lxc-ls(1), lxc-info(1), lxc-freeze(1), lxc-
unfreeze(1), lxc-attach(1), lxc.conf(5)
2025-06-09 lxc.container.conf(5)