選ぶなら「Xen」か「KVM」か 仮想化方式の違いから選定基準までを解説：一番重要なのは「自社のインフラ要件」にマッチするかどうか

TechTargetは「XenとKVMの違い」に関する記事を公開した。オープンソースのハイパーバイザーとして著名な「Xen」と「KVM」はどういった違いがあるのか。判断で重要になるのは「自社のインフラ要件」と「クラウド導入への関心度」だ。

[Paul Ferrill，TechTarget]

　TechTargetは2024年3月25日（米国時間）、「『Xen』と『KVM』（Kernel-based Virtual Machine）」に関する記事を公開した。代表的な2つのハイパーバイザーをどのような基準で選べばいいのか。

Xen対KVM、違いは何ですか？（提供：TechTarget）

　XenとKVMはどちらもLinux OSベースのハイパーバイザーで、基盤となるコードはオープンソースだが、有償でベンダーサポートも受けられる。サポートを提供しているベンダーはCitrix、Oracle、Red Hatなど。

　XenとKVMは、AMDとIntelのプロセッサの双方にあるCPU仮想化命令セットを利用している。「v7」以降のCPUを使用する「ARM」ベースのシステムはKVMの仮想化支援機能を利用できるようになっている。

　KVMとXenのどちらを使用するかは、自社の主要インフラ要件、スタッフ数、クラウド利用への関心度（クラウドをどのくらい使いたいと考えているか）によって決まる。また、環境の初期構築や長期利用時にかかるコストも重要な要素になる。

用語と定義

　XenとKVMについて具体的に掘り下げていく前に、混乱を避けるため、幾つかの用語について改めて定義しておく。

タイプ1ハイパーバイザー（Type 1 hypervisor）

　ホストマシンの物理的なハードウェア上で直接実行されるハイパーバイザーのこと。ホストOSを介さないので、基盤となるOSは不要

タイプ2ハイパーバイザー（Type 2 hypervisor）

　ホストマシンのOS上で実行されるハイパーバイザー。OSを通じてハードウェアに間接的にアクセスするのが一般的

準仮想化（Paravirtualization）

　仮想化方式の一種。ホストマシンのリソースの一部を論理的に分離し、別のOSやアプリケーションとして動作させる方式。ハイパーバイザーと連携しやすいようにVM（仮想マシン）のOS（ゲストOS）に修正を加える必要がある

完全仮想化（Full virtualization）

　仮想化方式の一種。ハードウェアを含む、物理的なホストマシンを再現（模倣）する方式。仮想化を提供するホストOSとは異なるゲストOSも起動できる特徴がある。一方、ハイパーバイザーの負担が大きく、準仮想化に比べるとパフォーマンスが低くなる傾向がある

ハードウェア仮想化

　CPUがハードウェアレベルで仮想化をサポートする技術、または機能。AMDとIntelで開発され、それぞれのCPU製品に実装されている。

Xenとは

　タイプ1ハイパーバイザーであるXenは、ケンブリッジ大学の学術プロジェクトから生まれ、2024年現在はLinux Foundationが引き継いでいる。

　IT管理者はXenを使い、同じハードウェア上で複数のOSを起動させ、共有リソースの管理に役立つ“小さな管理層”を構築できる。Xenは、LinuxベースのゲストOSに準仮想化の仕組みを適用している。一方、Microsoftの「Windows」がベースになっているゲストOSについてはハードウェア仮想化が利用されている。

　CitrixとOracleは自社の仮想化製品にXenを採用している。Citrixは「XenServer」というXenの名称を使った製品を提供していたが、オープンソースのXenと区別するために「Citrix Hypervisor」にブランド名を変更した。Citrixにとっては、仮想デスクトップのサポートは依然優先度が高いようで、XenServerは仮想デスクトップのワークロード向けに最適化されている。

　2022年にCitrixがCloud Software Groupの傘下に入った時点から、XenServerは独自のWebサイトとマーケティング戦略を持つ新たな製品になっている。Citrix Hypervisorは、「Citrix Virtual Apps and Desktops」を使っているユーザーであれば追加費用なしで利用できる。

　2024年3月現在、最も新しいXenプロジェクトは「XCP-ng」（Xen Cloud Platform - next generation）で、2024年2月15日に「バージョン8.3β2」がリリースされている。XCP-ngはXenServerのフォークとして立ち上げられ、Linux Foundationでは「Xen Projectのインキュベーションプロジェクト」という立ち位置になっている。XCP-ngには、Xenの基本ディストリビューションにはないGUIベースの管理ツールが多数用意されている。

Xenの長所

• タイプ1ハイパーバイザーのため、ハードウェアに直接アクセスでき、オーバーヘッドが少ない

Xenの短所

• 基盤となるOSのリソースを共有できない
• セキュリティ機能を強化する「sVirt」をサポートしていない

KVMとは

　2007年にLinuxに採用されたKVMは、x86サーバ上でOSを仮想化するハイパーバイザーだ。KVMはLinuxカーネルに組み込まれる形でゲストOSを起動するため、タイプ1ハイパーバイザーとタイプ2ハイパーバイザーのどちらに分類するかで議論が分かれている。

　カスタムインストールプロセスを使用すると、KVMはタイプ1ハイパーバイザーとして利用できる。Linux OS上でKVMを実行すると、ゲスト同士でリソースの交換、共通ライブラリの共有、システムパフォーマンスの最適化といったメリットを得られる。また、一般的なタイプ1ハイパーバイザーでは得られないsVirtなどのセキュリティ機能も追加される。

　オープンソースの「OpenStack」と「oVirt」は、2024年3月現在、デフォルトのハイパーバイザーとしてKVMを使用している。管理者はKVMによってさまざまなゲストOSを起動できる。ゲストOSとしては、「UNIX」のオープンソースOS「Berkeley Software Distribution」（BSD）、Oracleの「Solaris」、Windows、オープンソースの「ReactOS」、Appleの「macOS」が利用できる。オープンソースの「openSUSE」「Ubuntu」、Red Hatの「Red Hat Enterprise Linux」（RHEL）といった主流のLinuxディストリビューションの大半は、KVMをサポートしている。

　KVMの主なベンダーサポートはRed Hatが担っているが、Linuxカーネル開発チームもサポートを提供している。管理者もベンダーもこうしたサポート体制をメリットと考えており、Amazon Web Services（AWS）はKVM統合を含め、よりハイブリッドなアプローチへと積極的に移行している。

　2008年にRed HatはイスラエルのQumranetを買収した。他のオープンソース製品（RHELなど）と同様に、Red Hatはサービスとアップデートを有償にしている。なお、Red Hatは2019年にIBMに買収されている。

KVMの長所

• Linuxカーネルに組み込まれるため、セキュリティやパフォーマンスの定期アップデートに加え、Linuxの通常のアップグレードチャネルによるバグ修正を受け取れる

KVMの短所

• タイプ2ハイパーバイザーの機能を利用するためにはホストマシンのハードウェア上でLinux OSを実行する必要がある

ベンダーの対応状況

　Citrixは、創業以来、“リモートデスクトップの基盤”としてMicrosoftと提携してきた。XenServerもその流れを受け継ぎ、一元管理されたサーバ上でWindowsデスクトップを実行できるようになっている。これによって、イメージの管理による脆弱（ぜいじゃく）性フットプリントの制御など、セキュリティ面でさまざまなメリットが得られる。

　KVMはAWSをはじめとするクラウドプロバイダーの間で確固たる地位を築いている。KVMはRed Hatの仮想化の主力として同社の製品ファミリー全体で利用されている。

KVMとXenのハイパーバイザーとしての違い

　Xenはマイクロカーネル設計を採用しているため、仮想化拡張機能のないベアメタルハードウェアでも利用できる。これは最近のサーバではあまり気にならないポイントだが、仮想化拡張機能のない古いハードウェアでは重要だ。

　2023年11月にリリースされたXenの「バージョン4.18」では、人工知能（AI）と機械学習のアプリケーションに重点を置いてセキュリティ、パフォーマンス、アーキテクチャの機能が提供された。このバージョンでは、ARMとIntelの最新CPUハードウェア（x86ワークロード用の「Sapphire Rapids」や「Granite Rapids」など）がサポート対象となっている。

　KVMの長所はLinuxカーネルで機能する点にある。Linuxの新たなリリースが公開される際にバグ修正やセキュリティアップデートを受け取れるメリットがある。セキュリティの観点でいえば、KVMは手動ラベリング攻撃を防ぐ“sVirt”や「強制アクセス制御対策」といったメリットが得られる。

　AWSの「Nitro System」は、同じインスタンス内で複数のコンピューティング環境を切り分けられる仕組みだ。Nitro Systemで使われているのはKVMベースにカスタムされた最小ハイパーバイザーだ。ネットワークとストレージ入出力を実装するため、アプリケーション固有の集積回路を備えたカスタム設計のハードウェアカードを使っている。こうした機能は、異なるサブシステム間でセキュリティを分離するのに役立ち、VMレベルで機密データを保護する手段として有効だ。

どちらを選択するか

　KVMとXenのどちらを選ぶべきか。判断基準はユーザーエクスペリエンス（UX）、スタッフの知識、コード要件なども幾つかあるが、特に重要なのが「自社のインフラ要件」だ。

　管理者は（どのハイパーバイザーを使うか判断するに当たって）、現在のベンダーとの関係をしっかりと理解し、ITプロジェクトの方向性について明確なビジョンを持つ必要がある。

　2024年2月時点でBroadcomは「VMware ESXi」の無償版を廃止している。そのため、中小企業（SMB）ユーザーやホームユーザーは、NutanixのKVMベースの「Community Edition」に切り替える可能性がある。Xenを自社の主要ハイパーバイザーとして推進するOracleとCitrixは大きな顧客基盤を有している。Red Hat、SUSE、Canonicalは、各社のLinuxバージョン向けの仮想化オプションとしてKVMをサポートしている。

　クラウドの利用に関しても、管理者には同様の判断が求められる。CitrixやOracleがXenベースのサービスを用意しているのに対し、GoogleはKVMベースのサービスを提供している。また、AWSはXenとKVM双方のサービスを用意している。例えば、自社の新たなプロジェクトにAWSを利用したい管理者であればKVMを選択するかもしれない。CitrixやOracleを利用しているITチームがシステムをクラウドに移行する場合はXenを好む可能性がある。

　また、現状はオンプレミスとクラウドを組み合わせた使い方（ハイブリッドクラウドやオンプレミスでクラウドサービスを利用する、など）もあるので、そうした傾向を踏まえた判断も必要になる。管理者は両ハイパーバイザーを調査し、自社の既存の仮想化ソフトウェアが今後利用予定のクラウドプロバイダーとどの程度統合されるかを把握、検討することが重要だ。例えばAWSはXenとKVMの両方をサポートしているが、同社はCitrixとの協力関係も維持している。

　管理者は最終決断を下す前に、使えるユーザーインタフェースについても把握しなければならない。主要なクラウドベンダーは、ITチームと管理者に柔軟性を提供するために、Webベースとプログラムによるインタフェースの両方を提供している。

　大規模仮想化プロジェクトを管理する場合、誰かがコードを記述する必要が生じるため、自動化も大きな要素になる。コードを記述する必要性を理解し、記述方法について計画する場合は、その能力を有するスタッフがいるかどうかも判断材料になる。