Xen Summit 2026：セルフホスティングにおけるVM、Docker、ベアメタルの比較

Xen Summit 2026は、仮想化にとって興味深いタイミングとなる9月15日にミュンヘンで開幕します。Dockerは、セルフホストしたいほぼすべてのアプリケーションをパッケージ化できます。それでもハイパーバイザーは、クラウド、セキュリティ、組み込みシステム、ハードウェア負荷の高いワークロードにまたがって進化を続けています。

ホームサーバーの所有者にとって有益な問いは、「XenとDockerのどちらか」ではありません。両者は異なるレイヤーで動作します。本当の判断基準は、各ワークロードにどこで境界を設ける必要があるかです。

Xen Summit 2026：ハイパーバイザーはなぜ今も重要なのか

Xen Summit 2026は9月15日から17日までミュンヘンで開催されます。2日間の技術講演に続き、アーキテクチャと設計に関するセッションが1日行われます。プログラムは、クラウドインフラ、セキュリティ、Arm、組み込みシステム、自動車、ツール、実際の導入事例にわたります。

Xen 4.22もサミットの少し前にリリースされました。現行リリースは2029年7月までサポートされ、セキュリティサポートは2031年7月まで延長されます。このライフサイクルは、現代の仮想化についてあることを示しています。価値はますます「このマシンで何台のVMを実行できるか」ではなく、インフラがワークロードをどれだけ確実に分離・制御し、長期にわたって維持できるかにあります。

だからこそ、コンテナによってハイパーバイザーが不要になることはありませんでした。

Dockerは仮想マシンを廃れさせなかった

コンテナは非常に役立つ問題を解決します。つまり、サービスごとにゲストオペレーティングシステム全体をパッケージ化することなく、アプリケーションと依存関係をパッケージ化できます。

Dockerのコンテナに関するドキュメントでは、アーキテクチャ上の違いが強調されています。コンテナはホストカーネルを共有できますが、仮想マシンは独自のカーネルを持つゲストオペレーティングシステムを実行します。

コンテナ
────────────
アプリケーション
依存関係
────────────
ホストカーネルを共有


仮想マシン
────────────
アプリケーション
ゲストユーザー空間
ゲストカーネル
────────────
仮想化されたハードウェア

コンテナはアプリケーションのデプロイを最適化します。

VMは別のオペレーティングシステム境界を作ります。

そして実際のインフラでは、これらは一般的に積み重ねて使われます。

ハードウェア
   ↓
ハイパーバイザー
   ↓
仮想マシン
   ↓
コンテナランタイム
   ↓
コンテナ

したがって、「VMとDockerのどちらか」という議論は、しばしば的外れです。

本当の問題は、ワークロードが実際にどの境界を必要としているかです。

セルフホスト型サーバーにおける4つの境界

1つのレイヤーに別のレイヤーの問題まで解決させようとするのが間違いです。

コンテナは物理ホストの故障から保護してくれません。同じSSD上に6台のVMを置いても、6つの独立したストレージシステムができるわけではありません。2台目のサーバーを導入しても、アプリケーション認証の弱さは解決しません。

そして、通常のWebアプリにそれぞれ専用VMを割り当てると、コンテナによって解消するはずだったデプロイのオーバーヘッドが再び発生する可能性があります。

要件を実際に満たす、最も軽量な分離境界を使いましょう。

本当にVMが必要ですか？5つの質問で判断するテスト

1. 別のオペレーティングシステムまたはカーネルが必要ですか？

Windows、完全に別のLinuxディストリビューション、ファイアウォールアプライアンス、またはOSレベルのテストは、VMの有力な候補です。

別のOS／カーネルが必要ですか？
            ↓
           VM

2. 別の信頼境界が必要ですか？

セキュリティ実験、信頼性の低いソフトウェア、ビルドワーカー、使い捨てのテスト環境では、ゲストOSを主要ホストから分離する価値がある場合があります。

VMは自動的に「安全」になるわけではありませんが、同じホストカーネルを共有する別のプロセスとは異なる分離境界を提供します。

3. 低レベルのOSまたはネットワーク制御が必要ですか？

ファイアウォール、ルーティングラボ、アプライアンスOSでは、コンテナホストを何度も変更するよりも、独自の実行環境を持つほうが有利な場合があります。

4. ハードウェアを直接所有する必要がありますか？

ここで仮想化が特に興味深いものになります。

ワークロードには次のいずれかが必要になる場合があります。

• GPU
• ネットワークアダプター
• HBA
• USBコントローラー
• その他のPCIeデバイス

Xenの最新のインフラストラクチャドキュメントにPCIパススルーとSR-IOVが含まれているのは、アーキテクチャ上の問いが次のようになる場合があるからです。

この物理デバイスを所有するゲストはどれか？

5. 単なる別のアプリケーションですか？

ワークロードが一般的なダッシュボード、メディアサービス、データベース連携Webアプリ、ダウンロードツール、または自動化サービスで、別のカーネルや特別な信頼境界を必要としない場合、通常はコンテナから始めるのが最も簡単です。

ホームサーバーにおけるVMとコンテナとベアメタルの比較

重要なのは、リソース使用量と分離は別の問題であるという点です。

小さなLinux VMの消費量はごくわずかかもしれません。一方、AIコンテナはGPU全体と数十GBのメモリを消費することがあります。

1台に集約する際の問題：3つの上限

ホームサーバーのサイジングは、CPUとRAMから始めることが多いでしょう。実際には、集約されたサーバーが「いっぱい」になる理由は3つあります。

コンピュート上限

最もよく知られた上限です。別のワークロードを追加するためのCPU、RAM、ストレージ性能、GPU容量、またはVRAMが不足しています。

分離上限

ホストにはまだリソースが残っていますが、同じカーネル、権限、ハードウェア、または管理境界を別のワークロードと共有したくなくなります。

障害上限

ワークロードは技術的には収まっていますが、重要なサービスが同時に停止しすぎる状態になっています。

1台の物理ホスト
├── DNS
├── ストレージ
├── Home Assistant
├── メディア
├── Windows VM
└── 実験

1回の再起動が、家全体に影響するようになる。

これにより、ホームサーバーの集約をより適切に捉えられます。

サーバー容量
だけで制限されるわけではない：

CPU + RAM

また、次の要因によって制限されることもあります。

分離耐性

または

障害耐性

サーバーは、CPU使用率が100%に達するはるか前に、分離または障害の上限に達することがあります。

仮想的な分離は物理的な冗長性ではない

6台のVMを作成すれば、6つの有用なソフトウェア境界が得られます。しかし、独立した物理マシンが6台得られるわけではありません。

ホストが故障する
   ↓
ハイパーバイザーが停止する
   ↓
そのホスト上のすべてのVMが停止する

ストレージにも同じことが当てはまります。1台の故障したSSD上にある5台のVMディスクは、依然として5台すべて使用不能です。

ホームラボがひっそりと家庭内の本番環境へ変わっていくとき、ここが特に重要になります。

Zimaホームラボから学ぶ、仮想化に関する3つの実例

境界モデルは、図ではなく実際のハードウェアに適用すると、より理解しやすくなります。

1. 軽量なVMホストにもメモリ上限がある

ZimaOSはバージョン1.3以降、ネイティブのZVMサポートを搭載しており、WindowsとLinuxのVMをワンクリックでインストールできます。現在の仮想マシンのハードウェア要件も、一般的な「VMを何台実行できるか」の計算ツールが見落としがちな重要な点を示しています。固定されたVM数よりも、ゲストの種類、アクティブなワークロード、スナップショット、メモリ割り当てのほうが重要です。

最近の実環境テストでも、同じ結論に達しました。Martは8 GBのコンパクトサーバー上でProxmoxを使用してWindows 7 VMを実行し、控えめなゲスト1台なら現実的である一方、ゲストに割り当てたメモリによってホストや他のサービスで利用できるメモリが急速に減少することを示しました。このProxmoxとWindows VMのテストは、仮想化によってRAMが増えるわけではないことを思い出させてくれます。

小型サーバーにおける最初の仮想化の限界は、CPUではなくメモリであることが多いです。

2. パススルーの本質は所有権にある

Jonatan Castroによる2026年のProxmox構成は、ハードウェアの境界に関する問題をより明確に示しています。

この構成では、ZimaOSはVMとして動作し、物理SATA AHCIコントローラーがProxmoxからパススルーされます。ZimaOSは接続されたドライブを認識し、ゲストレベルでRAIDを構築します。

物理SATAドライブ
       ↓
SATAコントローラー
       ↓
PCIパススルー
       ↓
ZimaOS VM
       ↓
ストレージマネージャー

重要なのは、単に「NASをVMで実行できる」ということではありません。

この構成で重要なのは、ストレージの所有権が明確であることです。ゲストに抽象化された仮想ディスクだけを渡すのではなく、関連する物理コントローラーをゲストに渡します。

完全なProxmox仮想化とSATAパススルーの構成は、仮想化が実デバイスに関わるようになると、PCIeトポロジーとIOMMUサポートが重要になる理由も示しています。

3. 1台のボックスで多くのことを実行できるが、HAにはもう1台必要

この構成は、障害時の限界についてさらに優れた教訓を示します。

コンパクトな1台のノードがサービスワークロードの大部分を担い、その一方で、別のNASノードとクォーラムデバイスが、より広範なProxmox設計に参加します。HA対象としてマークされたサービスは、いずれかのノードを再起動した際に移動できます。

このアーキテクチャによって、単一サーバーのベンチマークでは見えない違いが明らかになります。

1台のホスト上に多数のVM
≠
高可用性

障害に対応できる複数のノード
+
共有・移動可能なワークロード設計
=
HAへの道筋

一般的なホームサーバーに高可用性は必要ありません。ただし、「物理ノードが1台停止してもこのワークロードを稼働させ続ける」ことが要件なら、同じノード上に別のVMを作成しても要件は満たせません。

仮想化で実際に重要なハードウェア機能とは？

ラボが基本的なVMを超える段階では、「仮想化をサポート」という表現は曖昧すぎます。

通常のゲストでは、CPU仮想化サポート、十分なRAM、高速なVMストレージが基本です。

パススルーやネットワークの実験では、次の点も確認してください。

• Intel VT-dやAMD-ViなどのIOMMUサポート、
• 利用可能なPCIe拡張、
• 複数の物理ネットワークインターフェース、
• ファームウェアのサポート、
• デバイス／IOMMUグループ、
• ホストとゲストの両方に十分なメモリ。

XCP-ngの現在のPCIパススルーのドキュメントでは、通常のCPU仮想化と、物理デバイスの割り当てに必要なIOMMU機能が明確に区別されています。

コンパクトなホームラボでは、VT-x、VT-d、PCIe拡張、複数のEthernetインターフェースを備えたコンパクトなx86ホームサーバーのほうが、単にコア数が最大のCPUを購入するよりも魅力的な場合があります。

ハードウェアは、構築しようとしている境界に合わせるべきです。

Xenはハイパーバイザー、XCP-ngはプラットフォーム

Xen Summitは、仮想化に関するもう一つのよくある混乱も浮き彫りにします。異なるレイヤーにあるプロジェクトが、同等の製品であるかのように比較されることがよくあります。

Xenはハイパーバイザーの基盤です。

XAPIはXenを中心とした管理ツールを提供します。

XCP-ngはこれらのコンポーネントを、完全な仮想化プラットフォームとしてパッケージ化しています。

仮想化プラットフォーム
───────────────────────
XCP-ng + 管理

管理／ツールスタック
───────────────────────
XAPI

ハイパーバイザー
───────────────────────
Xen

ハードウェア
───────────────────────
CPU / RAM / NIC / GPU / ストレージ

同じ原則は他の分野にも当てはまります。仮想化プラットフォームは、その基盤にあるハイパーバイザー以上のものです。

したがって、セルフホスターにとって実際の選択は、ハイパーバイザー技術だけに関するものではありません。VMのライフサイクル、ネットワーク、ストレージ、バックアップ、そしてそのプラットフォームのどれだけを実際に運用したいかも関わります。

AIによってハードウェアの所有が再び重要に

コンテナによってアプリケーションのパッケージングはよりポータブルになりました。ローカルAIは、ハードウェアのポータビリティが低いことをインフラストラクチャ構築者に再認識させています。

GPUを導入すると、通常のWebコンテナでは必要になることのない疑問が生じます。

GPUの所有者は誰ですか？

1台のVMがデバイス全体を必要としますか？

ドライバーはどこにありますか？

デバイスを正常にリセットできますか？

複数のワークロードで共有できますか？

ホストは利用可能なIOMMUグループを公開していますか？

これが、Dockerファーストの世界でもパススルーが依然として重要な理由の一つです。

コンテナはソフトウェアの所有を簡素化しました。アクセラレーターは、ハードウェアの所有をアーキテクチャの議論に再び持ち込みました。

重要なのはVMの数より適切な境界

Xen Summit 2026は、Xenを一度もインストールしない場合でも、セルフホスターにとって有益です。

より大きな教訓は、ベアメタル、VM、コンテナは成熟度の段階ではなく、最終的にどれか1つが他を置き換えるものでもないということです。

ベアメタル
→ ハードウェアの直接所有権

仮想マシン
→ OS / カーネル境界

コンテナ
→ アプリケーション境界

アプリケーションの権限
→ ユーザー / データ境界

アプリケーションの境界で十分な場合は、コンテナを使用します。

オペレーティングシステム、信頼モデル、または物理デバイスの所有権に独自の境界が必要な場合は、VMを使用します。

別の抽象化レイヤーによって、得られる柔軟性以上に復旧が複雑になる場合は、ベアメタルを使用します。

そして、1台のマシンがあらゆる処理を担うようになったら、CPUに余裕があるかどうかだけを問うのはやめましょう。

どの限界に達したのかを確認してください。

コンピュートの上限？

分離の上限？

障害の上限？

仮想化の目的は、VMの数を最大化することではありません。適切なワークロードに適切な境界を設けることです。

よくある質問

Xen Summit 2026はいつ開催されますか？

Xen Summit 2026は、ドイツのミュンヘンで9月15日から17日まで開催されます。9月15日と16日は技術講演が中心で、9月17日は設計セッションとプロジェクト計画に充てられます。

XenはXCP-ngと同じものですか？

いいえ。Xenは基盤となるハイパーバイザーです。XCP-ngは、XenとXAPIツールスタックを中心に構築された完全な仮想化プラットフォームであり、管理、ストレージ、ネットワーク、VMのライフサイクル管理機能を備えています。

セルフホスティングにはVMとDockerのどちらを使うべきですか？

アプリケーションがホストカーネルを安全に共有でき、主に再現可能なパッケージングを必要とする場合は、コンテナを使用します。別のオペレーティングシステム、カーネル、信頼境界、または専用ハードウェアの割り当てが必要なワークロードでは、VMを検討してください。

VMではなくベアメタルを使うべきなのはどんな場合ですか？

1つのワークロードがマシンの大部分を占める場合、ハードウェアを直接管理することが重要な場合、またはパススルーによって有用な分離効果なしに復旧が複雑になる場合は、ベアメタルのほうがシンプルです。

VM内でNASを実行できますか？

はい。ただし、ストレージの所有権を明確に定義してください。ストレージコントローラーをパススルーすると、NASゲストが物理ディスクをより直接的に管理できます。一方、ストレージがマシンの主な役割である場合は、ベアメタルのほうがシンプルな場合があります。

仮想化によって物理サーバーの障害から保護できますか？

いいえ。VMはソフトウェア環境を分離しますが、1台のマザーボード、電源、ストレージシステムを共有することはできます。1台のホスト上に複数のVMを作成しても、物理的な冗長性は生まれません。

GPUパススルーには何が必要ですか？

GPUやその他のPCIパススルーには、通常のCPU仮想化に加えて、Intel VT-dやAMD-ViなどのIOMMUサポート、互換性のあるファームウェア、デバイストポロジー、ハイパーバイザー設定が一般に必要です。