データセンターで仮想マシンをあるサーバーから別のサーバーへ移すとき、CPUやメモリの状態を転送する仕組みは20年近く前に整った。VMwareが2003年にVMotionを発表して以来、ライブマイグレーションはクラウド運用の基礎技術になった。ところが、ローカルに接続されたNVMe SSDを直接VMに割り当てている場合、話が一変する。ストレージの状態をどう移すかという問題に、標準的な解がなかったのだ。
USENIX NSDI 2026に掲載された研究によれば、ストレージ最適化VMのライブマイグレーションには数十個のCPUコアを静的に確保する必要があり、マイグレーション中のレイテンシ変動も避けられない。このため主要クラウドプロバイダーはストレージ最適化VMに対してライブマイグレーションを無効化している。VMを止めなければサーバーの保守も負荷分散もできない。NVMe SSDの性能を引き出すほど、運用の柔軟性が失われるという逆説が生じていた。
2026年8月4日、NVM Expressはこの状況を変える可能性を持つ仕様を公開した。NVMe 2.4 Base Specificationを中心に全11本の仕様書を一斉に改訂し、その中核に「PCIe Exported NVM Subsystem Migration」を据えたのである。
15年かけて「速いインターフェース」から「データセンターの基盤規格」へ
NVMeの歴史を振り返ると、この規格がストレージプロトコルとして出発しながら、データセンターインフラの基盤層へと変貌してきた軌跡が見える。
2011年、IntelのAmber Huffmanらが中心となって策定したNVMe Revision 1.0は、SATA/AHCIの限界を突破するために生まれた。AHCIはHDD時代に設計されたプロトコルで、キュー深度32、単一キューという制約があった。NVMeはPCIeバスに直結し、65,535個のキューをそれぞれ65,535コマンド深度で扱える設計を採用した。NANDフラッシュの並列性を引き出すための最適解だった。
2016年にはNVMe over Fabrics（NVMe-oF）が加わり、ネットワーク越しのストレージにもNVMeの低遅延を持ち込めるようになった。2021年には仕様が9本に分割されたNVMe 2.0が公開され、コマンドセットとトランスポートが独立して進化できる構造になった。今回のNVMe 2.4では仕様が11本に増え、Computational Programs Command SetやSubsystem Local Memory Command Setなど、ストレージの計算資源やメモリとしての利用まで射程に入れている。
| 時期 | 仕様 | 仕様本数 | 主な追加要素 |
|---|---|---|---|
| 2011年 | NVMe 1.0 | 1本 | PCIe直結、65,535キュー |
| 2016年 | NVMe-oF 1.0 | 2本 | ネットワーク越しNVMe |
| 2021年 | NVMe 2.0 | 9本 | コマンドセット分離（ZNS、KV等） |
| 2026年8月 | NVMe 2.4 | 11本 | PCIe Exported NVM Subsystem Migration、PQC、Rate Limiting |
この進化の方向性は明確だ。NVMeは「ホストとSSDの間の通信手順」から「データセンターのストレージ層を定義するアーキテクチャ規格」へと拡張を続けている。
ハイパーバイザーが背負い続けてきた仮想化の重荷
VMにNVMe SSDを直接割り当てる場合、従来はPCIeのSR-IOV（Single Root I/O Virtualization）を使うか、デバイスパススルーでSSD全体を1つのVMに専有させるかの二択だった。SR-IOVは1枚の物理SSDを複数のVirtual Function（VF）に分割し、各VFを異なるVMに割り当てられる。性能オーバーヘッドはほぼゼロに近い。
問題はライブマイグレーションとの相性だ。SR-IOVで割り当てたVFの状態は物理ハードウェアに深く結びついており、別のサーバー上の別のSSDに同じ状態で再現する標準的な手段がない。デバイスパススルーに至っては、SSD全体を1つのVMが占有するため、共有もマイグレーションも原理的にできない。
もう一つのアプローチは、ハイパーバイザーがNVMe管理コマンドを傍受してエミュレーションする方法だ。VMが発行したAdmin Queueのコマンドをハイパーバイザーが受け取り、仮想化ルールに基づいて応答を合成する。動作はするが、ハイパーバイザーのコードは複雑になり、ストレージの振る舞いがハイパーバイザーのロジックに密結合する。
NVMe 2.4が挑むのは、この構造そのものの組み替えだ。
SSD自身が仮想化を担う「Exported NVM Subsystem」の仕組み
PCIe Exported NVM Subsystem Migrationの核心は、仮想化の責任をハイパーバイザーからSSDコントローラーに移すことにある。SamsungのシニアディレクターでNVM ExpressボードメンバーのMike Allisonは、公式ブログでこの設計思想を次のように説明している。
「NVM Subsystem Migrationにより、NVMe SSDはExported NVM Subsystemを提示し、基盤ハードウェアの複雑さを隠蔽できる。ホストは物理コントローラーやネームスペースではなく、Exported ControllerとExported Namespaceだけを参照する。これにより、VMが見るものと内部で起きていることの間に明確な分離が生まれる」（原文: "With NVM Subsystem Migration, NVMe SSDs can present exported NVM subsystems that hide the complexity of the underlying hardware. Instead of interacting with physical controllers and namespaces, the host only sees exported controllers and namespaces."）
具体的なマイグレーションの手順は7段階で定義されている。
- 移行先サーバーにExported NVM Subsystemを作成する
- 移行元と同じ識別子でExported ControllerとExported Namespaceを再作成する
- 両システムに同じ設定テンプレートを適用する
- 移行元のExported Subsystemのランタイム状態をキャプチャする
- その状態を移行先に転送して適用する
- VM自体をマイグレーションする
- 移行元のExportedリソースと基盤リソースをクリーンアップする
VMからはストレージの識別子が一切変わらないため、OSやアプリケーションは再設定なしに動作を継続できる。
テンプレートが担保する「同じSSDであるという保証」
この仕組みの要となるのがテンプレート（Exported NVM Subsystem Template）だ。テンプレートは、Exported NVM SubsystemがVMに対してどの機能や識別子、振る舞いを公開するかを定義する設計図である。128ビットのUUIDで識別され、SSDがどのUUIDに対応しているかを報告する。同じUUIDをサポートする2枚のSSDの間では、そのテンプレートを使ったExported NVM Subsystemの設定と状態を完全にマイグレーションできることが保証される。
NVMe仕様は「Reference Exported NVM Subsystem Template」を定義している。これはベンダー間の相互運用性を最大化するために設計されたテンプレートで、コントローラ1基とネームスペース1個からなる最小構成のExported Subsystemを対象とする。ベンダーはこれを拡張して、複数コントローラやネームスペースのサポート、追加のオプション機能、特定のログページの内容などを定義したカスタムテンプレートを作成できる。
ただし、テンプレートが豊富になるほどマイグレーションの互換性は下がる。このトレードオフを仕様に明記した点は、実装上の透明性を確保するうえで重要だ。
従来のアプローチとの比較
| 項目 | SR-IOV | デバイスパススルー | ハイパーバイザーエミュレーション | PCIe Exported NVM Subsystem Migration |
|---|---|---|---|---|
| VM 1台あたりのSSD共有 | 可能（VF単位） | 不可（1 VM = 1 SSD） | 可能 | 可能 |
| ライブマイグレーション | 標準サポートなし | 不可 | 可能（高コスト） | 規格標準 |
| 仮想化の負担 | SSD側（VF分割） | なし | ハイパーバイザー側 | SSD側（Exported Subsystem） |
| VMからのAdmin Queue直接アクセス | VF経由 | 可能 | ハイパーバイザーが傍受 | 可能（Exported Controller経由） |
| 識別子の移植性 | 物理ハードウェア依存 | N/A | ハイパーバイザー実装依存 | ホスト制御（UUIDテンプレート） |
量子コンピュータ時代への備えと運用機能の強化
NVMe 2.4には、仮想化以外にも注目に値する機能がいくつか含まれている。
Post-Quantum Cryptography（PQC）対応は、NISTが2024年8月に確定したFIPS 203（ML-KEM）、FIPS 204（ML-DSA）、FIPS 205（SLH-DSA）の量子耐性アルゴリズムをNVMeプロトコルに組み込むものだ。ホストとSSD間のエンドツーエンド暗号化を量子コンピュータによる解読に耐える形に強化する。現時点で実用的な量子コンピュータによる暗号解読は実現していないが、規格に組み込むことで将来の脅威に備える。
Rate Limitingは、NVMeコントローラー自体が帯域幅とIOPSの上限を強制するQoS機能だ。クラウドプロバイダーがIOPSと帯域幅の閾値に基づいてストレージのサービスタイヤーを定義できるようになる。従来のソフトウェアベースのスロットリングと異なり、コントローラーのハードウェアレベルで制限をかけるため、ポーリングやソフトウェア割り込みのオーバーヘッドがない。
Voltage Monitoringは、過電圧や低電圧の閾値を設定し、リアルタイムのアラートと履歴ログを記録する機能だ。電源異常が性能や信頼性に影響する前に検知できる。Restore Manufacturing Default Settingsは、NVMeサブシステムを工場出荷時の状態に戻す機能で、障害調査やサーバーフリート全体の一貫した設定管理に使う。
NVM Express会長のAmber Huffmanは発表に際し、「最新のNVMe仕様は、ポスト量子時代におけるセキュリティの維持、デバイス管理の効率化、持続可能性の向上に向けた基盤を提供する」（原文: "The latest NVMe Specifications introduce foundational enablers to remain secure in the post-quantum era while streamlining device manageability and improving sustainability"）と述べた。
標準化から実装へ、残された距離
仕様の公開は出発点に過ぎない。PCIe Exported NVM Subsystem Migrationが実際にデータセンターで使われるまでには、いくつかの未解決の課題がある。
第一に、SSDベンダーの実装だ。規格に定義されていても、コントローラーのファームウェアにExported NVM Subsystemの機能を組み込み、テンプレートのUUIDを報告するSSDが出荷されなければ、この機能は存在しないのと同じである。LinuxカーネルのVFIOドライバ側でも対応が必要で、2025年8月の時点でライブマイグレーションコマンドのRFCパッチがメーリングリストに投稿されているものの、マージには至っていない。
第二に、テンプレートの相互運用性検証がある。リファレンステンプレートはコントローラ1基、ネームスペース1個の最小構成に限定されている。実運用では複数ネームスペースを使う場面が多く、ベンダー固有の拡張テンプレート同士の互換性をどう検証するかが課題になる。
第三に、機密計算（Confidential Computing）との統合だ。NVM Expressのブログは、この技術が機密計算やクラウド規模の仮想化、次世代データセンターアーキテクチャを支援する立場にあると述べているが、VMのメモリ暗号化とストレージのExported Subsystemをどう組み合わせるかについては、まだ具体的な相互運用仕様が示されていない。
NVMe 2.4の全仕様書はNVM Expressのウェブサイトでダウンロード可能だ。100を超える加盟企業を持つこのコンソーシアムが提示した方向性は、ストレージの仮想化を「ホストのソフトウェアが処理する問題」から「SSDがネイティブに提供する機能」へと移そうとしている。その成否は、今後1、2年で出荷されるコントローラーのシリコンが判断する。
