KVM対OpenVZ対LXC: VPSの仮想化方式が実際に何を可能にするのか

同じページに VPS のプランが二つ。4 vCPU、8 GB RAM、160 GB のストレージ、価格もほぼ同じ。片方には KVM、もう片方には OpenVZ と書かれています。どちらのページにも、その言葉が何を変えるのかは書かれていません。

その言葉は、何を動かしてよいかを変えます。VPS の仮想化方式は、単なる性能上の注釈ではありません。カーネルを自分で制御できるか、Windows が使えるか、プロバイダーの手を借りずに Docker が動くかを決めるものです。KVM・OpenVZ・LXC の比較は、速度の問題である前に、できることの問題です。

本ガイドでは、この購入判断に最も関わる三つの名称を扱います。Xen、VMware、Hyper-V などの仮想化プラットフォームも存在しますが、この三者比較の対象外です。

要約

• KVM は各 VPS に独自のゲストカーネルを与えます。Docker は普通に動き、Windows も技術的には可能で、たいていはカーネルモジュールの読み込みや独自カーネルの起動もできます。ただし KVM だけでは専有 CPU や専有 RAM は保証されません。リソースの確約は依然としてプロバイダーとプラン次第です。
• OpenVZ の VPS プランは通常、ホストのカーネルを共有する Linux コンテナです。OpenVZ 7 で Docker が動くのは、プロバイダーが対応カーネルとテンプレート構成を用いている場合だけです。ホストのカーネルは差し替えられず、RAM を超えるメモリはゲストが管理する通常のディスクスワップではなく、プロバイダーが制御する VSwap で処理されます。
• LXC も同じくホストのカーネルを共有しますが、メインラインの Linux カーネルが備える隔離機能を土台にしています。ホストが必要な機能を有効にすれば Docker は動きますが、Proxmox は最大限の隔離とライブマイグレーションを要するワークロードでは、コンテナを QEMU 仮想マシン内に入れ子にすることを推奨しています。
• コンテナは通常、稼働したままサイズを変更しやすいものです。KVM も CPU やメモリのホットプラグに対応できるため、「KVM は必ず再起動が要る」というのは購入時の判断基準として当てになりません。プラットフォームが実際に何に対応しているかは、プロバイダーに確認してください。
• Docker も Windows もカーネルレベルのカスタマイズも必要としない静的サイトや小規模な LAMP スタックであれば、実用上の差は小さいかもしれません。それでも隔離性、ライフサイクル、リソース方針は異なり得ます。

他のすべての違いを生む、たった一つの違い

KVM はホスト上の各 VPS に独自のゲストカーネルを与えます。OpenVZ コンテナと LXC コンテナは、ホストが起動したカーネルを使います。

KVM は x86 ハードウェア向けの完全仮想化ソリューションです です（仮想化拡張機能が必要）。2.6.20 以降、メインラインの Linux カーネルに統合されました。各ゲストは仮想ハードウェアを認識し、それぞれ独自の OS とカーネルを起動します。

コンテナ型はしくみが異なります。LXC は Linux カーネルの隔離機能に対するユーザー空間インターフェースです。名前空間、cgroups、ケーパビリティ、seccomp、セキュリティプロファイルなどが含まれます。別個のカーネルを起動せずに、通常の Linux インストールに近い環境を提供することを目指しています。

OpenVZ コンテナも大枠では同じ共有カーネル方式ですが、OpenVZ は独自のプラットフォームとカーネルスタックを使います。OpenVZ 7 はコンテナと KVM 仮想マシンの両方を管理できますが、市販の VPS プランに「OpenVZ」と書かれている場合、売られているのは通常コンテナ型です。

以下の機能差はすべてここから生じます。カーネルモジュールは、自分で制御できるカーネルに読み込む必要があります。別の OS には別のカーネルが要ります。Docker にはカーネルレベルの名前空間が必要で、それはカーネル自体が存在する場所で利用できなければなりません。この境界の KVM 側では、ハイパーバイザー層は一般に次のように分類されるアーキテクチャに従います。 タイプ 1 とタイプ 2 のハイパーバイザー.

LXC は Proxmox 環境でよく使われ、自主管理のサーバーや一部のホスティング基盤も含まれます。LXC の高度な機能を有効にできるかどうかは、そのホストを誰が管理しているかで決まります。

読む

KVM vs. OpenVZ 2022: 仮想化の達人はどちらか?

各方式で何を動かせるのか

購入を左右する軸は、カーネルの制御、ゲスト OS の対応、Docker の互換性、メモリの挙動、リサイズ、そしてリソース方針です。

どれを選ぶべきか Windows、独自カーネル、ゲストが読み込むモジュール、あるいは挙動の読める Docker ホストが必要なら、KVM が最も素直な答えです。OpenVZ と LXC も効率のよい Linux 環境になり得ますが、カーネルレベルの判断はプロバイダーに委ねられます。

これは性能測定ではなく、できることの地図です。ストレージのレイテンシ、ネットワーク品質、CPU 世代、ホストの稼働率、プロバイダーのリソース配分方針については何も語っていません。同じ仮想化方式を使う二社が、まったく違うマシンを提供することもあります。

買い手が時間を失うのは、この条件付きのマス目です。以前、ホスト側で必要なネットワーク機能が開放されていないコンテナ型 VPS に VPN を構築したことがあります。インターフェースが立ち上がらず、解決にはゲスト内の設定変更ではなくサポートチケットが必要でした。コンテナ型のプランでは、VPN が必要とするデバイスやカーネル機能がそのまま開放されているかを確認してください。KVM なら、通常はゲスト内で自分で制御できます。

なぜ Docker が多くの購入を決めてしまうのか

要件に Docker が入った瞬間、コンテナ型 VPS と KVM VPS の比較は抽象論ではなくなります。Docker 自体がカーネルの名前空間、cgroups、ネットワーク、ストレージドライバを使うからです。KVM の中では、これらの機能は自分で制御するゲストカーネルに属します。OpenVZ や LXC の中では、最終的にホスト次第になります。

OpenVZ 上の Docker

OpenVZ での Docker 対応は、あなたより上の層で下されるプロビジョニング上の判断です。 SolusVM のサポート記事 によれば、特定の 3.10 系カーネルリリース以降であれば OpenVZ 7 内で Docker を動かせますが、同時に、標準の旧来型プリセットテンプレートでは Docker は動作しないとも書かれています。コンテナは EZ テンプレートか適切なカスタムテンプレートを使う必要があります。同じ記事は CentOS 8 のゲストを対象外としています。

では、OpenVZ で Docker は動くのでしょうか。動くこともあります。プロバイダーが対応する OpenVZ 7 カーネルと適切なテンプレート経路を土台にサービスを構築している必要があります。プラン紹介ページに明記がなければ、購入前にサポートへ確認し、その回答を書面で残しておきましょう。

ホストの構成が非対応の場合、VPS の中で Docker のフラグを変えても根本的な問題は解決しません。プロバイダーにコンテナ構成を変更してもらうか、別の仮想化方式へ移してもらう必要があります。

LXC 上の Docker

ホストが必要な機能を開放していれば、LXC の中でも Docker は動きます。Proxmox では、一般にコンテナのネスティングと keyctl が、非特権コンテナに必要になります。

より重要な購入判断の材料は、プラットフォーム提供元の推奨です。Proxmox のドキュメントには、 コンテナを Proxmox の QEMU 仮想マシン内に入れ子にすることは引き続き推奨される方法である と書かれています。これは最大限の隔離とライブマイグレーションを要する用途についての話で、LXC のシステムコンテナで直接動かす代わりの選択肢です。

LXC のホストを自分で管理しているなら、このトレードオフを自分で評価し、アップグレードも自分の都合で試せます。LXC の VPS を借りている場合は、カーネル、セキュリティプロファイル、高度な機能フラグはプロバイダーが握ります。コンテナ内で root が取れれば十分だと決めつけず、対応構成を確認してください。

KVM 上の Docker

Docker が普通に動くのは、Linux ゲストが自分のカーネル環境を制御しているからです。ゲストの上に LXC のネスティング設定も OpenVZ のテンプレート要件も存在しません。とはいえ、対応する Linux ディストリビューション、互換性のあるカーネル、そしてワークロードに見合う RAM とストレージは必要です。

ゲストカーネルを持つということは、それを保守するということでもあります。アンマネージドの VPS では、更新、ファイアウォール規則、Docker のセキュリティ、バックアップはすべて自分の責任です。

重要なポイント: Docker があるからといって OpenVZ や LXC が使えなくなるわけではありませんが、プロバイダーの構成がアプリケーションの信頼性の一部になってしまいます。本番用に借りる Docker ホストであれば、KVM はその余分な依存関係をなくしてくれます。

「4 vCPU」は専有 CPU コア 4 個を意味するのか

自分の監視ツールでは CPU が空いているのに動作が遅い VPS。これが最もよく語られる症状です。それを可能にしているのがコンテナ型の仮想化です。奪い合いはゲストから見える層の一つ下で起きているため、ゲスト側の指標には何の異常も現れません。

そのしくみは、オーバーヘッドの小ささそのものです。コンテナはホストにとって完全な仮想マシンよりはるかに安上がりなので、同じハードウェアにより多く詰め込めます。この高密度は作るのが安く、ゲストの内側からは検知しにくいため、オーバーセルは KVM より OpenVZ のほうが構造的に容易になります。KVM でもプロバイダーがホストに詰め込むのを防げるわけではありません。ただしゲストごとに実メモリと実 CPU 配分を確保するため、詰め込みには算術的な上限が生まれます。診断の側面については、 プロバイダーがオーバーセルしているかどうかの見分け方.

メモリの振る舞いも違います。OpenVZ ではディスクスワップを追加メモリとして使えないため、プラン紹介ページの RAM の数字は坂ではなく壁です。KVM のゲストはメモリが逼迫すると遅くなります。OpenVZ のコンテナはメモリが逼迫するとプロセスが強制終了されます。

隔離についての帰結もあり、これこそ多くの人が過小評価しているものです。コンテナのメモリは、KVM ゲストのメモリとは違ってホスト側からアドレス指定できます。ゲスト内でのディスク暗号化は、ディスクを盗まれた場合には今も有効です。しかし、稼働中のコンテナの鍵を、それを動かしているマシンから守ることはできません。脅威モデルにホストの運用者が含まれるなら、共有カーネルは選ぶべき土台ではありません。ゲスト内のどんな設定でもこれは変わりません。

重要なポイント: プラン紹介ページの同じ数字でも、方式によって約束の意味が違います。KVM では割り当てです。OpenVZ では、他と分け合う上限です。

OpenVZ が今も意味を持つ場面と、その行く末

静的サイトやトラフィックの少ない LAMP スタックであれば、OpenVZ が制限する機能に一度も触れないかもしれません。Windows も、独自カーネルも、ゲストが読み込むモジュールも、本番の Docker も不要。その限られた用途なら、きちんと運用された OpenVZ コンテナで今でも十分こなせます。

ライフサイクルには、10 年前より注意が要ります。OpenVZ 7 は RHEL 7 のカーネル系列、バージョン 3.10 を土台にしています。ベンダーはパッチをバックポートするため、バージョン番号だけで、保守されている企業向けカーネルにセキュリティ修正が欠けていると断じることはできません。ただし、より新しいカーネルインターフェースを前提とするソフトウェアとの互換性は確認しておくべきです。

The open-source OpenVZ project and the commercial Virtuozzo product are on separate tracks, and the commercial one has published dates. Virtuozzo Hybrid Server 7 reached end of maintenance in July 2024 and is listed for end of life in December 2027 in the 公式のライフサイクルポリシー.

これによって、今動いている OpenVZ のサイトが壊れるわけではありません。ただし、新たに長く使うワークロードを預ける前には、プロバイダーの移行計画が重要になります。稼働している OpenVZ または Virtuozzo のバージョン、セキュリティ修正の提供方法、そして用意されている移行経路を確認してください。

プラン紹介ページに仮想化方式が書かれていない場合は、価格から推測せずサポートに尋ねましょう。その回答は書面で残しておく価値があります。

ワークロードから選ぶ

技術ではなく、要件から出発しましょう。

ワークロードに独自カーネルが要るなら KVM を選ぶ

次のいずれかが必要なら、KVM が素直な選択です。

• ゲスト OS として Windows を使う
• 独自のカーネル
• ゲストが読み込むカーネルモジュール
• コンテナ・イン・コンテナへの依存がない本番 Docker
• プロバイダーが開放している場合のネスト仮想化
• ゲストが制御するスワップとカーネルチューニング

Windows が決定打になるのは、OpenVZ も LXC もコンテナがホストの Linux カーネルを使うからです。アプリケーション自体に Linux と Windows のどちらを選ぶかは別の問題で、ソフトウェアの互換性、運用管理、ライセンスが絡みます。詳しくは Linux と Windows の VPS 比較 をご覧ください。

効率のよい Linux システムコンテナが欲しいなら LXC を選ぶ

ワークロードが Linux 専用で、別個のカーネルを必要とせず、オーバーヘッドの小ささやホスト側での素早い変更が生きる場面では、LXC は理にかなっています。とくに Proxmox や LXC のホストを自分で管理している場合に有用です。

借りる LXC の VPS では、Docker の対応、必要なデバイス、セキュリティモード、バックアップの挙動、そして高度な機能を有効化できるかどうかを確認してください。

単純で検証済みの Linux ワークロードには OpenVZ も検討する

基本的なウェブサイト、小規模な LAMP スタック、DNS サービス、あるいは同じように一般的な Linux ワークロードであれば、次の条件が満たされる場合 OpenVZ は今も許容できます。

• プロバイダーがプラットフォームのバージョンを明示している。
• 使用するソフトウェアが、提供されるカーネル環境に対応している。
• Windows もカーネルのカスタマイズも必要としない。
• Docker が不要か、明確にサポートされている。
• プロバイダーに、信頼できるセキュリティと移行の計画がある。
• 価格または運用モデルに、それを選ぶ確かな理由がある。

古い比較記事が「OpenVZ はいつも安い」と書いているというだけで選ばないでください。現在のプラン、サポート、リソース方針、移行の選択肢を比べましょう。

答えが KVM になったなら、それは好みではなく制約が決めた結果です。Cloudzy の KVM VPS は AMD EPYC と純 NVMe の上で 60 秒で起動し、どのインスタンスにも独自のゲストカーネルが割り当てられます。カーネルモジュールは読み込め、独自カーネルも起動でき、Linux と Windows のどちらのゲストにも対応しています。 Docker はマーケットプレイスにあります 自分でインストールしたくない場合に便利です。

よくある質問

systemd-detect-virt