背景と目的
商用サービス向けに VMwareを利用しているユーザーがKVMへの移行を検討する際、特にミッションクリティカルなシステムであればあるほど、「VMwareからKVMに移行する際のリスクは何か？」という点が大きな関心事となります。
VMwareはエンタープライズ向けに最適化されており、内部的に多数の性能・安定性向上の工夫が組み込まれています。こうした仕組みを把握せずに移行した場合、それがリスクとして顕在化することなく移行計画から漏れてしまい、運用開始後に致命的な性能劣化や障害を引き起こす可能性もあります。
今回はディスク仮想化の仕組みに焦点をあてて取り上げます。
おさらい
前回の記事「VMwareからKVMに移行する人のための機能比較 Vol.3 メモリ編」で
「仮想化基盤の内部構造」についてメモリ仮想化の仕組みに焦点をあてて解説しました。
メモリ仮想化におけるアーキテクチャを図解すると、VMware（vSphere）とKVMは類似した構造を持っていますが、メモリのオーバーコミット環境下では実際の動作面で異なる点も多く注意が必要と解説しました。
VMwareとKVMにおけるディスクの仮想化
VMwareとKVMはディスクの仮想化の基本アーキテクチャは類似しており、仮想マシンから物理ディスクまでの経路や仕組みは概ね同等です。
ただし、VMwareは仮想化専用に最適化されているためディスクI/Oにおけるオーバーヘッドが小さい一方、KVMではディスクI/O処理の際にカーネルモードとユーザーモード間での切り替えが発生するため、オーバーヘッドが増える傾向があります。
もっとも、KVMでは多様な機能や構成オプションが用意されており、業務特性に応じて適切な構成を選択することで、ディスクI/O性能をVMwareと同等以上に高めることも可能と考えます。
このため、ディスクの仮想化に関しては、単純にVMwareとKVMを比較するよりも、KVMにおける構成オプションを理解し適切に選択することの方が重要となる場合があります。
VMwareとKVMのメモリ仮想化におけるアーキテクチャの違い
（1）VMware（vSphere）
①カーネル・ハイパーバイザ：VMkernel
ESXiホストで動作する中核コンポーネントです。
②VMM（Virtual Machine Monitor）
仮想マシンの仮想ディスクドライバが発行するI/O要求を受け取り、VMkernelに中継します。
③仮想ディスクドライバ/仮想ストレージコントローラ
仮想マシンに仮想ストレージコントローラを提供するドライバです。これにより仮想マシンは物理ディスクと同様にI/Oを扱い、VMkernelを通じて実際の物理ディスクにアクセスできます。
④Storage I/O Control
データストアの遅延を監視し、輻輳発生時のみ制御を発動します。シェア値や制限値に基づき、重要な仮想マシンにより多くI/O処理を行わせる機能です。
⑤仮想ディスク
仮想マシンに割り当てられる論理的なディスクです。仮想マシンからは通常の物理ディスクのように見え、VMkernelを通じて実際の物理ディスクにアクセスします。
（2）Red Hat KVM
①カーネル：RHEL Kernel
RHEL ホスト OS 上で動作する中核コンポーネントであり、KVM モジュールを含む Linux カーネルです。
②エミュレータ：QEMU（Quick Emulator）
仮想マシンが仮想ディスクに対して発行したI/O要求をQEMUプロセスが受け取り、ホストOSが理解できる形式に変換します。ディスクI/OはQEMUスレッドの一部として処理されます。
③virtio
仮想マシンから見える仮想ディスクコントローラを提供し、I/Oを効率化するための準仮想化のフレームワークです。
④virtioドライバ
仮想マシン内にインストールするドライバで、virtioを利用可能にします。
④-1 デバイスの選択
主要なデバイスとして、virtio-blkとvirtio-scsiを挙げることができ、特徴は次の通りです。
・virtio-blk：ブロックデバイスエミュレーション
シンプルであり少数ディスク環境で設定や管理が容易です。仮想マシンからはvda、vdb、vdcといったシンプルなデバイス名で見えるだけです。
ディスク数が少ないWeb/APサーバ、小規模DBサーバに向きます。
・virtio-scsi：SCSI エミュレーション
多数ディスク環境で設定/管理が容易です。例えば、1本のvirtio-scsiコントローラ配下に複数ディスクを紐づけることができます。
ディスク数が多い大規模DBサーバに向きます。
④-2 キューの設計
virtio-blkとvirtio-scsi共にマルチキューに対応し並列処理が可能です。
キューは、仮想化マシン側のvirtioドライバとホスト側のQEMUのvirtio間にまたがって存在する概念です。仮想マシンの各vCPUがI/O処理をキューに投げる動作となり、「vCPU ⇔ キュー ⇔ QEMUスレッド」の流れで処理されます。
このため、キューの数はvCPU数に合わせるのが最適と考えられます。理由は次の通りです。
vCPU数 ＞ キューの数：キューの競合が発生しやすくなります。
vCPU数 ≒ キューの数：各vCPUに専用キューが割り当てられ競合が最小化されます。
vCPU数 ＜ キューの数：実際には使われないキューに対応するQEMUスレッドが生成されスレッドスケジューリングのオーバーヘッドの要因となります。
⑤IOThread
ディスクI/Oを仮想マシンのvCPUスレッドから分離して処理するための専用スレッドです。これによりI/O待ちで仮想マシンのvCPUがブロックされず、I/O性能を向上できます。
RHEL9のドキュメントでは「最適な結果を得るには、ホスト上の CPU ごとに 1 - 2 IOThreads のみを使用してください。」という注記があります。
これは物理ホストマシン上のCPUコア数をベースに設定するように勧めています。その理由は、IOThreadはQEMUプロセスのスレッドとしてホストマシン上で実行される実体であり、ホストマシンのCPUリソース制約を超えるスレッドを生成すると、スレッド切り替えやコンテキストスイッチのオーバーヘッドが高まり、逆に性能低下を招くからと解釈できます。
⑥ディスクIOスロットリング
仮想マシンのディスク単位でIOPS制御が可能です。仮想マシンのすべてのディスクに同じ制御を入れれば「仮想マシン単位のIOPS制御」として機能します。ただし、VMwareのように輻輳状況を検知して調整する機能は無く、ストレージに余裕があっても制限が効き続けるため、利用者が適切な制限値を見積もる必要があります。
⑦仮想ディスク
仮想マシンに対して仮想的なブロックデバイスを提供する仕組みで、実体はrawやqcow2ファイルなどです。仮想マシンからは通常の物理ディスクのように見え、I/OはQEMUを介してホストのディスクに転送されます。
・raw
メタ情報を持たず、ファイルの内容をそのままディスクに書き出しますのでフォーマットの処理にはオーバーヘッドがかかりません。パフォーマンスを重視する場合に適しています。
・qcow2
メタ情報を持ちスナップショット、圧縮、暗号化の機能があります。ディスク容量を節約したい場合、ディスクのオーバーコミットが必要な場合に適しています。
（3）VMwareからKVMに移行する際の主な考慮点
VMwareとKVMはディスクの仮想化の基本アーキテクチャは類似しており、IOPS制御などの機能も両者に実装されています。ただし、VMwareは仮想化専用に最適化されているため利用者側の考慮すべき設計要素は少ない一方、KVMは多様な構成オプションが用意されており柔軟な設計が可能です。その反面、仕様を正しく理解して適切に選択しなければ、期待したI/O性能が得られない可能性があります。
まとめ
ディスクの仮想化に関しては、KVMにおける構成オプションを十分理解し、業務特性に応じて最適な選択を行うことが重要です。
関連記事
VMwareからKVMに移行する人のための機能比較 Vol.1 アーキテクチャ編
VMwareからKVMに移行する人のための機能比較 Vol.2 CPU編
VMwareからKVMに移行する人のための機能比較 Vol.3 メモリ編
参考資料
①仮想化の設定および管理 | Red Hat Enterprise Linux | 9 | Red Hat Documentation
14.2. 仮想デバイスの種類
18.6.2. 仮想マシンのディスク I/O スロットリング
18.6.3. ストレージデバイスでのマルチキューの有効化
18.6.4. 専用の IO スレッドの設定
15.6.5. サポートされているディスクイメージ形式
②書籍：平初・森若和雄・鶴野隆一郎・まえだこうへい『KVM徹底入門 Linuxカーネル仮想化基盤 構築ガイド』翔泳社、2013年出版
③書籍：今井悟志『VMware vSphere7 インテグレーションガイド』インプレス、2021年出版
④書籍：ヴイエムウェア株式会社 Broadcom『VMware vSphere徹底入門』翔泳社、2025年出版
⑤書籍：ヴイエムウェア株式会社『VMware徹底入門』翔泳社、2016年出版
⑥VMware vSphere 8.0
NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。