USBまたはGPUパススルーを使用するDockerホストでは、ProxmoxのLXCとVMのどちらが運用しやすい？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Proxmox LXC vs VM for a Docker Host With USB or GPU Passthrough: Which Is Easier to Operate? - Zima Store Online

Linuxデバイスノードを安全に公開でき、必要なGPUまたはUSBドライバーをホストが管理し、低いオーバーヘッドやGPU共有が重要な場合は、DockerホストにProxmox LXCコンテナを選択します。ゲストがドライバースタックを管理する必要がある場合、PCIデバイスをIOMMUで分離する必要がある場合、またはDockerとそのハードウェアアクセスをProxmoxホストから独立させる必要がある場合は、VMを選択します。USBシリアルデバイスはどちらの方法にも適していますが、GPUの専用パススルーでは通常VMが適しています。

LXCとVMを比較する前に「パススルー」を定義する

LXCとKVMでは、ワークロードへのハードウェアの割り当て方法が同じではありません。LXCコンテナはProxmoxカーネルを共有するため、通常は`/dev/dri`、`/dev/ttyUSB0`、`/dev/bus/usb`など、ホストが作成したデバイスノードへのアクセス権を与えられます。ハードウェアの検出とカーネルドライバーの読み込みは、引き続きホストが行います。

VMは独自のカーネルを実行します。ProxmoxはUSBデバイスをエミュレートしたり、選択したUSBデバイスまたはポートを接続したり、VFIOとIOMMUを介してPCIデバイスを割り当てたりできます。ゲストは独自のドライバーを読み込み、割り当てられたハードウェアを、直接インストールされたデバイスに近い形で扱います。

現在のZimaSpaceのProxmox NASセットアップガイドでは、両方のゲストタイプを紹介しています。この記事では、USBドングル、シリアルアダプター、メディアGPU、またはコンピュートアクセラレーターを必要とするコンテナ向けのDockerホストに、選択肢を絞って説明します。

比較項目	Proxmox LXC内のDocker	VM内のDocker
カーネル	Proxmoxホストのカーネルを共有	独立したゲストカーネルを実行
USBアクセス	ホストのデバイスノードとアクセス権を公開	選択したUSBデバイスまたはポートをゲストに接続
GPUアクセス	通常は、ホストで読み込まれたドライバーとレンダリングデバイスを共有	VFIOを介して専用PCIデバイスを割り当て可能
リソースのオーバーヘッド	メモリとストレージのオーバーヘッドが少ない	ゲストOS用の追加メモリとディスク
分離	ホストとの結び付きが強く、カーネル境界を共有	ドライバーとカーネルの分離がより強固
移植性	互換性のあるホストデバイス、ドライバー、ID、マッピングに依存します	ゲストのドライバー状態はVMとともに移行しますが、物理PCIマッピングはホスト固有のままです
GPU共有	対応していれば、複数のコンテナで同じホストのレンダリングデバイスを使用できます	デバイス全体のパススルーでは、通常、そのデバイスを1台のVM専用にします
最適な選択肢	メディア、シリアルUSB、共有Linux GPUサービス	専用アクセラレーター、プロプライエタリドライバー、より強力な分離、異なるゲストOSの要件

USBデバイスは、安定したLinuxデバイスノードとして動作する場合、LXCに適しています

USBシリアルアダプター、Zigbeeコーディネーター、UPSインターフェース、Coral USBアクセラレーターなどのデバイスは、Proxmoxがデバイスノードを公開し、正しい所有権をマッピングすれば、LXCで問題なく動作します。その後、LXC内のDockerコンテナは、Linuxホスト環境からそのデバイスを受け取ります。

Proxmox LXC内でのUSBアクセスについての実用的な解説では、基礎となる仕組みが示されています。デバイスをマウントするだけでは不十分で、コンテナからのアクセスも許可する必要があります。

アプリケーションが対応している場合は、`/dev/serial/by-id`のような安定したパスを使用してください。バス番号や`/dev/ttyUSB0`の割り当ては、再起動や再接続後に変わることがあります。ホストを更新するたびにcgroup、UID、GID、デバイスパスを手動で修復する必要があると、LXC方式は不安定になりやすくなります。

USBの所有権を自己完結させる必要がある場合はVMのほうがクリーン

VMでは、ベンダーIDと製品ID、または物理ポートを指定してUSBデバイスを割り当て、そのデバイスドライバーを独自のオペレーティングシステム内に読み込めます。デバイスにベンダー提供のパッケージ、異なるカーネルバージョン、またはProxmoxホストのライブラリに依存させたくないアプリケーションスタックが必要な場合に便利です。

VMでは、より明確な診断境界も得られます。ゲストがUSBデバイスを失った場合、管理者はハイパーバイザー側の接続と、ゲスト側のドライバーを個別に確認できます。LXCでは、ホストドライバー、デバイスノード、権限、コンテナのマッピング、Dockerランタイム、アプリケーションが1つの連鎖に関与します。

トレードオフは再接続時の挙動です。ゲストの再起動中に、一部のUSBデバイスがリセットされたり、識別情報が変わったり、見えなくなったりすることがあります。最初に正常に接続できたからといって安定動作を前提にせず、抜き差し、ホストの再起動、ゲストの再起動、アプリケーションの復旧をテストしてください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

GPUの共有アクセスでは通常LXCが有利

IntelまたはAMDのレンダーデバイスや、対応するNVIDIAワークロードでは、LXCからホストのGPUデバイスノードを複数のLinuxサービスに公開できます。GPUはProxmoxホストのドライバーによって管理されたままなので、PCIデバイス全体を1つのゲストに割り当てなくても、複数のコンテナでハードウェアトランスコードやコンピュートを利用できます。

XDAの最近のProxmoxに関する例では、VMパススルーでGPUを専有するのではなく、LXCでホストが管理するGPUを共有する方法を説明しています。同じ運用モデルは、ドライバーと権限の要件が一致する場合、Jellyfin、Plex、Frigate、複数のDockerサービスにも適しています。

共有するとバージョンの依存関係が生じます。ホストのカーネルドライバー、LXC内のユーザー空間ライブラリ、Dockerランタイムとの統合、アプリケーションパッケージの互換性を維持しなければなりません。そのため、Proxmoxのカーネルやドライバーをアップグレードすると、GPUを使用するすべてのコンテナに一度に影響する可能性があります。

GPUの排他的パススルーでは通常、VMが有利

1つのワークロードがディスクリートGPUの直接所有権、プロプライエタリなゲストドライバー、Windows対応、CUDAの分離、またはProxmoxにインストールすべきでないカーネルスタックを必要とする場合、VMのほうが適しています。VFIOによる割り当てでデバイスをホストから分離し、ゲストに提示できます。

ProxmoxのPCIモデルは、物理PCIデバイスをKVMゲストに割り当てる構成を前提に設計されています。Level1TechsのDockerに関する議論が示す実際の違いは、VMでは通常、パススルーしたGPUを専有する一方、LXCではホストのデバイスアクセスを複数のサービス間で共有できるという点です。

GPUがMediated DeviceやSR-IOVに対応している場合、この判断が逆転することもあります。しかし、コンシューマー向けGPUやホームサーバープラットフォームには、共有のための汎用的な方法がありません。排他的なパススルーを前提に設計する前に、IOMMUグループ、リセット動作、ファームウェア、ディスプレイの初期化、そしてホストがそのGPUを必要とするかどうかを確認してください。

LXC内のDockerは管理レイヤーをさらに追加する

LXCはすでにOSレベルの分離を提供しており、その中にDockerを入れると、さらに別のコンテナランタイムが加わります。これは効率的な場合もありますが、名前空間、cgroups、ストレージドライバー、ケーパビリティ、マウント動作が入れ子になります。Dockerの一部機能では、Proxmoxコンテナでネスト設定や追加の権限が必要です。

VMはDockerに一般的なLinuxホストを提供します。ゲストがカーネル設定を管理するため、Dockerのドキュメント、カーネルモジュール、ファイアウォールの動作、ストレージドライバーを解釈しやすくなります。その代わり、完全なゲストOS、予約メモリ、仮想ディスク管理、そして別のパッチ適用層が必要です。

必要な構成によって特権コンテナ、広範なデバイス権限、文書化されていないホスト側の変更が求められるなら、数百MBを節約するためだけにLXCを選ぶべきではありません。アップグレードのたびに、VMならゲスト内に収められる例外事項を思い出す必要があると、軽量という利点は薄れます。

分離とセキュリティによって、パフォーマンス面での優位性は逆転することがあります。

LXCはホストカーネルを共有するため、設定を誤った特権コンテナや広すぎるデバイスマッピングによって、意図した以上にProxmoxノードを露出させる可能性があります。非特権LXC、限定的なデバイス権限、読み取り専用マウント、最小限のケイパビリティによって境界は改善できますが、アーキテクチャは完全なVMよりも密結合です。

VMは分離されたカーネルを提供し、独自GPUスタック、Dockerネットワーク、ファイアウォールモジュール、実験的なソフトウェアをProxmoxのベース環境から隔離できます。Dockerホストでサードパーティ製イメージ、公開サービス、ローカルAIパッケージ、または頻繁なドライバー実験を実行する場合、この分離は有効です。

VMだからといって自動的に安全になるわけではありません。PCIパススルー、共有ストレージのマウント、管理認証情報、ブリッジネットワークは、依然として攻撃や障害につながる経路を生み出します。独立したカーネルとドライバーの境界によって脅威モデルと保守モデルが実際に簡素化される場合に選択してください。

バックアップと移行では、異なる種類のシンプルさが重視されます

LXCのバックアップは、ゲストに完全な仮想ハードウェアスタックが含まれないため、コンパクトで高速です。ただし、別のProxmoxノードでハードウェアアクセスを復元するには、デバイスノード、グループ、ドライバー、権限を一致させる必要があります。コンテナのファイルシステムは移行できても、物理デバイスの要件は移行できません。

VMのバックアップにはゲストOSとドライバー構成が含まれるため、アプリケーションの復旧をより自己完結させられます。ただし、USBアタッチメントとPCIアドレスは移行先で再マッピングする必要があり、パススルーしたGPUは物理デバイスが1つのノードに紐づくため、ライブマイグレーションを妨げる可能性があります。

ZimaSpaceのProxmoxバックアップワークフローは、ゲストの保護を扱います。この比較では、Dockerが起動し、USBまたはGPU依存のアプリケーションが交換先のデバイスを認識できて初めて、復旧が完了したとみなします。

ゲストタイプを選ぶ前にデバイス復旧テストを実施する

Dockerアプリケーションが必要とするすべてのUSBデバイスとPCIデバイスを一覧にします。
各デバイスをホストと共有するか、1つのゲスト専用にするかを決定します。
LXC向けに、ホストドライバー、デバイスノード、UID/GIDマッピング、Dockerの権限をテストします。
IOMMUグループ、ゲストドライバーのインストール、VMのリセット動作をテストします。
Proxmoxホストを再起動し、デバイスのアタッチが自動的に復旧することを確認します。
バックアップからゲストを復元し、文書に基づいてハードウェアマッピングを再作成してください。
移行やハードウェア交換が重要な場合は、互換性のある別のノードでも繰り返し確認してください。

ゲストのオーバーヘッドだけでなく、アプリケーションの挙動を測定してください。ハードウェアトランスコーディングの安定性、USBの再接続、ドライバーの更新、ホストのメンテナンス、復旧時間は、通常LXCとKVMのCPU差がわずかであることよりも重要です。

Dockerホストに適したProxmoxゲストはどれですか？

LXCを選択する場合

すべてのワークロードがLinuxベースで、ホストがドライバーを管理でき、USBデバイスが安定したノードを公開し、GPUを複数のサービスで共有したい場合は、LXCを選択します。可能な限りコンテナは非特権のままにし、すべてのデバイスとグループのマッピングを文書化してください。

VMを選択する場合

DockerホストにPCI GPUの専有、プロプライエタリまたは実験的なドライバー、より強固なカーネル分離、またはソフトウェアスタック全体の容易な可搬性が必要な場合は、VMを選択します。ゲスト用に十分なRAMとストレージを確保し、再起動後のデバイスリセットをテストしてください。

ワークロードを分割する場合

軽量なメディアサービスやUSBサービスはLXCで実行し、GPUを専有するコンピューティング、Windows依存ツール、信頼できないDockerスタックはVMに配置します。Proxmox対応プラットフォームでは両方をサポートできますが、各物理デバイスには文書化された所有権モデルを1つ設定してください。

よくある質問

非特権LXC内でDockerを安定して実行できますか？

多くのワークロードでは可能ですが、ネスティング、ストレージドライバー、マウント、ネットワーク、デバイスアクセスには追加設定が必要になる場合があります。説明のつかない権限問題を回避するためだけに、特権コンテナへ切り替えるのは避け、Dockerの機能を正確にテストしてください。

1台のGPUをLXCとVMの両方で使用できますか？

通常のデバイス全体のVFIOパススルーを同時に行うことはできません。LXCではホスト管理のレンダーデバイスを共有できる場合がありますが、VMでは通常、そのデバイスをホストから切り離す必要があります。特定のハードウェアでは、SR-IOVやメディエーションデバイスのサポートによって事情が変わることがあります。

USB Zigbeeコーディネーターにはどちらが適していますか？

どちらでも動作します。安定したserial-by-IDパスと権限を確保できる場合は、LXCが効率的です。コーディネーターのソフトウェアスタックやドライバーをProxmoxホストから独立させたい場合は、VMのほうがすっきりします。

最終結論

USBやGPUリソースをProxmoxホストのLinuxドライバースタック経由で共有でき、オーバーヘッドの低さが重要な場合は、DockerホストにLXCを使用します。ハードウェアをゲストに割り当てる必要がある場合、ドライバーを分離する必要がある場合、または復旧時に自己完結型のオペレーティングシステムを維持したい場合は、VMを使用します。コンテナのほうが常に簡単だと決めつけるのではなく、デバイスの所有権と復元方法で選択してください。