KVM の内部での動作
KVM は、/dev/kvm キャラクターデバイスを公開することで、Linux カーネルを Type-1 ハイパーバイザーに変換します。ユーザー空間プロセス (通常は QEMU) がそのデバイスを開き、カーネルに仮想 CPU の作成を要求し、ハードウェア仮想化拡張を使用して物理 CPU 上で直接ゲスト命令を実行します。カーネルは特権イベントを処理します; その他はすべてネイティブ速度で実行されます。
KVM を機能させる 3 つのコンポーネントがあります。まず、kvm.ko カーネルモジュールが CPU とメモリの仮想化を管理し、/dev/kvm インターフェイスを公開します。次に、アーキテクチャ固有モジュール — Intel VT-x 用の kvm-intel.ko または AMD-V 用の kvm-amd.ko — が、汎用 KVM API と基盤となる CPU の仮想化命令との間を翻訳します。3 番目に、QEMU、cloud-hypervisor、Firecracker などのユーザー空間ハイパーバイザープロセスが、デバイスエミュレーション (仮想ディスク、NIC、USB コントローラー、BIOS または UEFI ファームウェア) を提供します。Linux カーネル自体がハイパーバイザーであるため、すべての Linux スケジューラ、メモリマネージャ、セキュリティ機能は、ネイティブプロセスに適用されるのと同じ方法で VM に適用されます。KVM ゲストはカーネルの観点からは単に重量級のプロセスであり、これが top、perf、cgroups などのツールが変更なしで機能する理由です。
KVM 対 OpenVZ 対 VMware ESXi 対 Hyper-V
KVM は、すべての VM に対して別々のゲストカーネルを持つ完全なハードウェア仮想化を提供します。OpenVZ は、すべてのコンテナがホストカーネルを共有する OS レベルのコンテナ化を使用します。VMware ESXi は、独自のカーネル (VMkernel) を持つプロプライエタリなベアメタル Type-1 ハイパーバイザーです。Hyper-V は Microsoft の Windows ベースの Type-1 ハイパーバイザーです。KVM、ESXi、Hyper-V のみが、真の隔離されたゲストカーネルを提供します。
OpenVZ (およびその後継の Virtuozzo) はコンテナ技術であり、ハイパーバイザーではありません。すべての OpenVZ コンテナはホストの Linux カーネルを共有しており、これは異なるカーネルバージョンを実行できず、カスタムカーネルモジュールをロードできず、非 Linux オペレーティングシステムを実行できないことを意味します。トレードオフは密度です: VM ごとのカーネルオーバーヘッドがないため、OpenVZ ホストは同じハードウェアにより多くのコンテナを詰め込むことができ、これが低価格の共有 VPS プランで頻繁に使用された理由です。VMware ESXi は Type-1 仮想化のエンタープライズ標準ですが、歴史的にコモディティ VPS ホスティングから価格を排除したソケットあたりのライセンスを持つクローズドソース製品として出荷されています。Hyper-V は Windows サーバー環境を支配し、Active Directory と System Center と緊密に統合されますが、Linux 重視のホスティングフリートでは一般的でない選択肢です。KVM が現代の VPS ホスティングのデフォルトになったのは、オープンソースであり、カーネルにメインライン化され、x86_64 または aarch64 で実行される任意のゲスト OS をサポートし、成熟した管理エコシステム (libvirt、oVirt、Proxmox、OpenStack Nova) を持っているからです。
なぜ KVM は VPS の現代的なデフォルトなのか
KVM は、すべての顧客に VMware スタイルのライセンスを支払うことなく真の隔離されたカーネルを提供することで、支配的な VPS 技術になりました。Linux、Windows、BSD、Solaris ゲストをサポートし、コモディティ x86_64 および ARM ハードウェアで実行され、すべての主要なクラウドオーケストレーションスタック — OpenStack、Proxmox VE、KubeVirt 経由の Kubernetes、AWS Nitro はすべてその上に構築されています — に統合されています。
3 つの力が収束して KVM を標準にしました。まず、ハードウェア仮想化拡張機能が普遍的になりました: Intel VT-x は 2006 年に Core 2 チップに搭載され、AMD-V は初期の Athlon 64 に搭載されたため、2010 年代初頭までに本質的にすべてのサーバー CPU がネイティブに近い速度で KVM をホストできるようになりました。次に、Linux コミュニティはメインラインで Xen スタイルの準仮想化を採用することを拒否しましたが、2007 年に KVM をメインライン化し、すべてのディストリビューションに即座に組み込みハイパーバイザーを提供しました。3 番目に、パブリッククラウドエコシステムは多額の投資を行いました: Google Cloud Engine は KVM 上で立ち上げられ、AWS は Xen から KVM ベースの Nitro アーキテクチャに移行し、OpenStack は KVM を参照ハイパーバイザーとして標準化しました。小規模な VPS プロバイダーは、ハイパースケーラーフリートを実行するのと同じツール — libvirt、virtio ドライバー、cloud-init — がコモディティサーバーの単一ラックでも実行されるため、この重力的な引力から恩恵を受けます。
実際のパフォーマンス特性: CPU steal、IO、オーバーヘッド
適切にプロビジョニングされた KVM ホストでは、ベアメタルに対して一桁台のパーセントの CPU オーバーヘッド、ローカルネットワークパスに追加されるサブミリ秒のネットワークレイテンシ、virtio-blk または virtio-scsi が準仮想化ドライバーで使用されている場合のネイティブディスク IOPS の 80〜95% を期待してください。5% を超える持続的な CPU steal time は、ホストの過負荷の標準的な兆候であり、強力なアップグレードシグナルです。
本番環境の KVM ゲストでは 3 つの数値が重要です。/proc/stat の 8 番目のフィールドとして公開される CPU steal time は、仮想 CPU が実行可能だったが物理 CPU が他のゲストの実行で忙しかった時間の割合を測定します。1〜2% 未満は通常のバックグラウンドノイズです; 5% を超える持続的な値は、ホストが過負荷であり、ワークロードがスロットルされていることを意味します。iostat や top などのツールで表面化される IO wait は、CPU がディスクまたはネットワークでブロックされた時間の割合を測定します。virtio 準仮想化ドライバーと現代の NVMe バッキングストレージを使用すると、CPU バウンドのはずのワークロードで 20% を超える持続的な IO wait は、ディスクサブシステムが飽和していることの強力なサインです。virtio-net 上のネットワークスループットは、物理 NIC のラインレートの 80〜95% に達するはずです; それを大きく下回るものは、設定ミスのオフロードまたは古いエミュレートされた e1000 ドライバーを示します。
KVM を使用すべきでない場合
KVM は 3 つの状況で間違った選択です: VM ごとのカーネルオーバーヘッドが支配する超高密度コンテナ化ワークロード、Hyper-V の SPLA 価格が大幅に安い Windows ライセンスに敏感な展開、特定の NIC または GPU モデルで SR-IOV または GPU パススルーがサポートされていない特定の低レイテンシハードウェアパススルーシナリオ。
カーネル隔離を必要としないコンテナ化されたマイクロサービスでは、ベアメタル上で直接実行される Linux コンテナ (Docker、Podman、Kubernetes) は、各コンテナが名前空間と cgroups を持つプロセスグループにすぎないため、KVM ベースの VPS よりも 3〜5 倍高密度になります。密度に敏感な低コストの VPS プロバイダーは、歴史的に同じ理由で OpenVZ を選択しました。Windows 重視の展開 — 特に SPLA を通じて購入された Windows Server ライセンスを実行している展開 — は、Microsoft が競合ハイパーバイザーでゲストライセンスを価格設定する方法のため、Hyper-V で KVM よりも大幅に低いコストを支払うことがあります。最後に、特定のハードウェアパススルーシナリオは KVM では依然として痛みを伴います: GPU パススルーには IOMMU グループがクリーンに隔離されている必要があり、一部のコンシューマー NIC は SR-IOV サポートがなく、NVMe ドライブの PCIe パススルーは時々リセットバグの回避策をトリガーします。一般的な目的の Linux VPS ワークロードの 95% では、これらのいずれも当てはまらず、KVM が正しいデフォルトです。
VPS が本当に KVM ベースであることを確認する方法
Linux ゲスト内で `systemd-detect-virt` を実行します — `kvm` と表示されるはずです。`lscpu` (「Hypervisor vendor」の行は「KVM」と読むはずです) と `dmesg | grep -i kvm` でクロスチェックします。代わりに「OpenVZ」、「lxc」、「VMware」が表示される場合、マーケティングが他の主張をしていても、プロバイダーは異なる技術を使用しています。
契約に署名する前に、トライアル VPS で小さな診断バッテリーを実行してください。標準的な検出出力のために `systemd-detect-virt` を実行します。ハードウェア仮想化拡張が通過していることを確認するために `cat /proc/cpuinfo | grep -E 'vmx|svm'` を実行します (一部のプロバイダーはそれらを取り除き、ネスト仮想化を破壊します)。共有ホストカーネルではなくゲスト固有のカーネルが表示されることを確認するために `uname -r` を実行します — 真の KVM VPS では、`apt install linux-image-...` または `dnf install kernel-...` で異なるカーネルをインストールし、それで再起動できます。OpenVZ ではできません。最後に、`/proc/user_beancounters` をチェックします — そのファイルが存在する場合、マーケティングコピーが何と言おうと、ホストは OpenVZ を実行しています。