午前2時のディスクレイテンシの悪夢
午前2時、スマートフォンが激しく振動した。Zabbixのモニタリングシステムが赤色の警告を発している。データベースサーバーのDisk I/O Latencyが500msという閾値に達していた。物理サーバーがSamsung PM1733 NVMe Enterpriseを搭載していることを考えると、あり得ない数字だ。
SSHで確認したところ、仮想マシン（VM）がいまだに**LSI Logic SAS**コントローラーを使用していることが判明した。これは、互換性を維持するための古いVMwareのデフォルト設定だ。モダンなアプリケーションにおいて、この「ボトルネック」は仮想マシンの「重い」動作の原因となり、SSDハードウェアの性能を著しく制限してしまう。
**Virtual NVMe (vNVMe)**への移行は、物理ディスクへの「直接アクセス」を検討するのと同様に、物理SSDのパワーを最大限に活用するための最短ルートだ。追加コストなしで、劇的な速度向上を実感できるだろう。
なぜLSI Logic SASやSATAでは不十分なのか？
VM作成時に「次へ」を連打する習慣のせいで、図らずも古い規格に縛られてしまうことがある。問題は技術的な限界にある：
- LSI Logic SAS: HDD（磁気ディスク）向けに設計されている。データ処理時に大きなソフトウェアオーバーヘッドが発生する。
- SATA: コマンドキューの深さ（Queue Depth）が32に制限されている。
- Virtual NVMe: 最大64kのキューをサポート。各キューで同時に64kのコマンドを処理可能。I/OタスクあたりのCPUサイクルを削減できる。
本物のNVMe SSDを使用しながらSCSIをエミュレートしているなら、実際のパフォーマンスの20〜30%を無駄にしていることになる。これはデータストア整理で容量を最適化しても解決できない問題だ。例えば、NVMe単体で500,000 IOPS出せるとしても、古いコントローラー経由では350,000 IOPS程度に落ち込んでしまう。
vNVMeアップグレードの前提条件
すぐに変更してはいけない。ブルースクリーン（BSOD）を避けるために、以下のチェックリストを確認してほしい：
- ハードウェアバージョン: 仮想マシンがバージョン13以上であること（ESXi 6.5またはVMware Workstation 14以降に相当）。
- オペレーティングシステム: Windows 8.1またはWindows Server 2012 R2以降。Linuxの場合、カーネル3.3以上（Ubuntu 20.04+、CentOS 7+は標準対応）。
- バックアップ: 実行前に必ず仮想マシンのスナップショットを取得すること。些細なミスで、当直の夜がOS再インストールの惨劇に変わらないように。
Windowsでの安全な移行方法
設定から直接コントローラーを変更すると、Windowsは「Inaccessible Boot Device」エラーで起動しなくなる。これはブートプロセスにNVMeドライバがロードされていないためだ。以下の「ドライバの先行読み込み」テクニックを使用しよう。
ステップ1：ダミーのNVMeディスクを追加する
- 仮想マシンを完全にシャットダウンする。
- 設定の編集から、新しいデバイスとして**NVMeコントローラー**を追加する。
- 新しいハードディスク（1GB程度）を追加し、作成したNVMeコントローラーに割り当てる。
- Windowsを通常通り起動する。
