Proxmoxの仕組み：ASNetworkingがVM、コンテナ、KVM、QEMUを解説

エヴァ・ウォン

IceWhale author

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

How Proxmox Works: ASNetworking Explains VMs, Containers, KVM and QEMU

このスペイン語のProxmoxコースで、わかりやすい図解を提供してくれたASNetworkingに感謝します。第2章では、仮想化ホストの基本的な考え方を解説します。VMが物理マシンから何を借りるのか、リソース割り当てがどのように機能するのか、コンテナが異なる点、そしてQEMUとKVMが一緒に登場する理由を取り上げます。制作者による詳しい解説は元の動画をご覧ください。

読む前に視聴しましょう: この20分の概念解説は、ホームラボでProxmox VEの利用を検討しているものの、インストール前にその階層構造を理解したい方に役立ちます。図は、物理サーバーと複数のゲストから、シンプロビジョニングされたディスク、コンテナ、Linuxカーネル、QEMU、KVMへと進みます。一部の図には大型のエンタープライズマシンや説明用の容量が示されていますが、コンパクトサーバー向けのハードウェア仕様ではなく、学習用の例です。

重要なのは、ゲストに見えているものと、ホストが実際に利用できるものの違いです。VMには独自のCPUコア、RAM、ディスク、オペレーティングシステムがあるように見えますが、これらのリソースは最終的に同じ物理ホストから提供されます。Proxmox VEは、VMとLinuxコンテナの管理を1つのインターフェースにまとめています。この章では、パフォーマンスの測定やインストール完了までの手順ではなく、そのアーキテクチャを解説します。

1台の物理ホストで複数の独立したマシンを動かす

仮想化を使うと、1台のサーバーで複数のゲストOSを、それぞれ独立したVMとして実行できます。各ゲストは仮想ハードウェアを認識して独自のアプリケーションを実行し、ホストが基盤となるCPUをスケジュールし、物理メモリ、ストレージ、ネットワークを管理します。そのため、テスト用Linux VMと別のサービス用VMを、タスクごとに物理コンピューターを1台ずつ用意せずに共存させられます。

物理サーバーと、複数の独立した仮想マシンを提供する仮想化ホストを比較する図 — 仮想化レイヤーを通じて、複数の独立したゲストシステムが1台の物理サーバーを共有できます。

オーバーコミットには現実的なリソース予算が必要

ASNetworkingは、オーバーコミットについて紹介します。これは、すべてのゲストが同時にリソースを要求した場合にホストが供給できる量を超えて、ゲスト全体に仮想リソースを割り当てることです。ワークロードのピーク時間が異なる場合には合理的な方法です。ただし、ハードウェアが増えるわけではありません。同時に大きな負荷がかかると、CPU競合、メモリ不足、ストレージ速度の低下が発生する可能性があります。小規模なホームラボでは、まず実際に搭載している物理RAMとストレージを基準にし、ホスト用の余裕を確保して、別のゲストを追加する前に使用状況を確認しましょう。

1台の大型物理サーバーで4台の仮想マシンがプロセッサリソースを共有する動画内の図 — 複数VMの図は共有容量を示すもので、描かれているサーバーとプロセッサ数は例です。

シンプロビジョニングによってディスク容量の消費タイミングが変わる

仮想ディスクは、現時点で消費している物理容量よりも大きな論理容量を提示できます。動画の図では、1TBの物理ディスク上に、容量1TBの仮想ディスクが5台あり、それぞれが現在100GBを使用しています。実際の書き込みが物理ディスクに収まる間だけ、この構成は機能します。ゲスト全体が仮想ディスクを使い切ると、表示容量から想定されるよりもはるかに早くホストの空き容量がなくなる可能性があります。表示上の仮想容量だけを基準に計画せず、物理的な空き容量、ストレージ形式、スナップショット、バックアップを確認してください。

1TBの物理ディスク上で、それぞれ100GBを使用する5台の1TB仮想ディスクを示すシンプロビジョニング図 — 割り当てられた仮想容量はディスクの物理サイズを超えていますが、現在書き込まれているデータの合計は500GBです。

このエピソードでは、メモリ階層化についても触れています。RAMと低速なストレージは異なる役割を担います。使用頻度の低いデータを低速な階層へ移すことでメモリの圧迫を管理しやすくなりますが、ストレージがRAMと同じ速度になるわけではありません。特にメモリ容量が限られたホストでは、リソース節約機能をすべてトレードオフとして捉え、ワークロードに対して効果を確認しましょう。

ハイパーバイザーが管理するもの

ハイパーバイザーは、物理リソースとVMの間に位置します。動画のこの部分の図では、各VMが独自のワークロードを持ちながらも、1台のホストのCPU、RAM、ディスク、ネットワークに依存していることが強調されています。Proxmox VEは、Webインターフェースや設定・管理用サービスなど、これらのゲストを扱う管理ツールを提供します。そのアーキテクチャには、KVM仮想マシンとLXCコンテナが含まれます。

ユーザーツール、サービス、仮想マシン、QEMU、コンテナ、Linuxカーネルを示すProxmox VEのアーキテクチャ図 — Proxmoxのスタックには、VMとコンテナのレイヤー上に管理ツールとサービスが含まれます。

物理CPU、RAM、ストレージ、ネットワークと3台のゲストVMの間にハイパーバイザーを配置したサーバー仮想化の概要図 — ハイパーバイザーは分離されたゲストを提供しながら、物理リソースは共有されたままです。

VMとコンテナでは分離の境界が異なる

VMにはゲストOSと仮想ハードウェアが含まれます。Linuxコンテナは、ホストのLinuxカーネルを共有しながら、アプリケーションとユーザー空間を分離します。そのため一般に、コンテナは完全なVMより軽量ですが、分離とOSのモデルは異なります。Windowsゲストや、独立したカーネルの恩恵を受けるワークロードにはVMが適しています。Linuxで動作するサービスなら、LXCコンテナに適している可能性があります。Proxmox LXCドキュメントでは、コンテナモデルについてさらに詳しく説明しています。

1つの物理ノード上で、独立したアプリケーション、依存関係、ゲストOSを持つ6台のProxmox仮想マシンを示す図 — VMモデルでは、各ゲストが独自のOSレイヤーを備えます。

コンテナとVMを組み合わせることもできます。デプロイに適した境界であれば、VM内でコンテナランタイムを実行できます。動画の比較表には、ベアメタル、仮想化、コンテナ化、そしてVM内でコンテナを動かす構成が含まれています。サービスと、そのセキュリティ、互換性、保守要件に合わせて境界を選びましょう。コンテナは単に小型のVMというわけではありません。

ベアメタル、仮想マシン、コンテナ、仮想マシン内で動作するコンテナを比較する図 — この比較では、VM内のコンテナを含む、複数の有効なレイヤーが示されています。

Linux、QEMU、KVMの位置付け

Proxmox VEは管理インターフェースを備えたLinuxベースのプラットフォームです。各コンポーネントのコマンドをすべて覚えなくても、その役割は理解できます。制作者はまずProxmoxのダウンロードページを簡単に紹介し、その後、VMの下にある技術レイヤーを説明します。Web上のダウンロード画面では製品ファミリーが示されますが、仮想化モデルは続くQEMU/KVMの図でより直接的に説明されています。

Proxmox VEやその他のProxmox製品を一覧表示した公式Proxmoxダウンロードページ — ASNetworkingはプラットフォームを紹介する際にProxmoxのダウンロードページを表示しています。動画内に示されるリリース情報は変更される可能性があります。

KVMはLinuxカーネルに備わる仮想化機能で、対応するCPU仮想化拡張機能を利用します。QEMUは仮想マシンのプロセスと、エミュレートまたは準仮想化されたデバイスを提供します。QEMUとKVMを組み合わせることで、ハードウェアアクセラレーションを利用したVMを実行できます。これは、QEMUとKVMを2つの競合するハイパーバイザーと考えるのではなく、Proxmox内のラベルを読み解くうえで役立つ理解です。ProxmoxのQEMU/KVMガイドでは、VMの設定と機能について説明しています。

Linuxカーネルと基盤ハードウェア上のKVMの上に、QEMUとゲストVMを配置した図 — QEMUはVMのプロセスとデバイスを処理し、KVMはカーネルレベルのハードウェア仮想化を提供します。

小規模なホームラボにモデルを適用する

動画では、ハイパーバイザーの市場シェアを示す図が短時間表示されます。その割合はホームラボのプラットフォームを選ぶうえで必要ではなく、独自に検証された市場データとして扱うべきでもありません。より役立つ判断は具体的なものです。完全なゲストOSが必要なワークロードはどれか、Linuxカーネルを共有できるものはどれか、そして実際のRAMとディスクの予算内にいくつ収まるかを考えましょう。

VMware、Hyper-V、Nutanix、KVMまたはProxmoxなど、エンタープライズハイパーバイザーの市場シェアを示す動画内の図 — これは動画内で提示される図であり、具体的な市場シェアの数値はここでは独自に検証されていません。

ZimaBoard 2ミニホームサーバーのようなコンパクトホストでは、まず控えめなサービスを1つか2つ割り当て、実際のモデルのCPU、メモリ、起動メディア、接続ストレージを確認し、実際の使用状況を観察してから拡張しましょう。これはこのレッスンのリソースモデルを適用したものであり、動画がZimaBoard 2のベンチマークを実施したり、特定のVM数を検証したりしたという意味ではありません。バックアップはシンプロビジョニングされた仮想ディスクとは別に保管してください。