共有ストレージが無い、あるいはクラスタが別でも、VMを止めずにストレージごと別ホストへ移せます。ハードウェア更改やオンプレの段階移行で効く、Shared Nothing Live Migrationの仕組みと現場の勘所を整理します。
「共有ストレージが無いとVMは無停止で動かせない」——これはWindows Server 2012までの常識でした。以降のHyper-Vには Shared Nothing Live Migration（共有ストレージなしライブマイグレーション）があり、SANもクラスタも無いスタンドアロンのホスト同士で、稼働中VMをメモリもストレージも丸ごと相手ホストへ移せます。ハードウェア更改や基盤の段階移行で、これを知っているかどうかで移行計画の自由度が大きく変わります。
01そもそも何が「Shared Nothing」なのか
通常のフェールオーバークラスタ内のライブマイグレーションは、VMのストレージ（VHDX）がCSVやSMB 3.0ファイル共有といった両ホストから見える共有領域に置かれている前提です。移動するのはメモリと実行状態だけで、ディスクは動かしません。
これに対しShared Nothing Live Migrationは、その名のとおり共有するものが何も無い状態から始まります。VMのメモリ・実行状態に加えて、ローカルディスク上のVHDXそのものを相手ホストのローカルストレージへコピーしながら、無停止で切り替えます。Microsoft Learnはこの構成を「running virtual machines between servers with minimal downtime（最小のダウンタイムで稼働中VMをサーバ間移動）」と表現しており、必要なのは事実上イーサネット接続だけです。
02VMとストレージを同時に運ぶ仕組み
内部的にはライブマイグレーションとストレージライブマイグレーションという独立した2つの機能が協調して動きます。処理の流れはおおむね次のとおりです。
- 移行元VMを稼働させたまま、まずVHDXを移行先へコピーする。この間の書き込みはミラーリングされ、移行元・移行先の両ディスクへ同時に反映される。
- ストレージの同期が追いついたら、メモリページを反復コピーする通常のライブマイグレーション処理（ダーティページの追いかけ）へ移る。
- 最後にごく短い停止で残りの状態を送り、実行主体を移行先へ切り替える。VMからはディスクの場所が変わったことすら見えない。
ストレージのコピーは時間がかかるため、10GbE以上のネットワークと、移行元・移行先双方のディスクI/Oが律速になります。数百GBのVHDXなら「ネットワークとディスクの実効スループット × サイズ」で所要時間を見積もると現実的です。
03認証がすべて — Kerberos制約付き委任か、CredSSPか
Shared Nothingでいちばんハマるのは、ディスク性能でもネットワークでもなく認証です。VMの移動処理は「Microsoft Virtual System Migration Service」を、ストレージ（VHDX）の移動はcifsを、移行先ホストのコンピュータアカウントに対して委任する必要があります。認証方式は2択です。
- Kerberos（制約付き委任）：移行元へサインインせずに操作できる。ただし
Active Directory上で各ホストのコンピュータアカウントに制約付き委任を構成する必要があり、設定にはDomain Adminsが要る。 - CredSSP：委任設定は不要だが、必ず移行元ホストにサインインした状態で操作を起動しなければならない。リモートから叩くと
0x8009030E（No credentials are available）で失敗する。
Windows Server 2025では、ドメイン参加した非DCサーバでCredential Guardが既定で有効になったため、CredSSPベースのライブマイグレーションは使えなくなります（Microsoft Learn明記）。2025世代を触るなら、迷わずKerberos制約付き委任で設計してください。当社でライブマイグレーション用ADを構築した際も、この委任設計を最初に固めました。委任の考え方をもう一段深掘りしたい方は、Kerberos制約付き委任とライブマイグレーションと、クラスタ／ライブマイグレーションのためのAD設計もあわせてどうぞ。
04SMB3・SMB Direct — 転送を速くする道具立て
ライブマイグレーションの転送方式（Performance option）は3つから選べます。Microsoft Learnの記述どおり整理すると次のとおりです。
- TCP/IP：メモリ内容をそのままTCP/IPで転送。
- Compression：メモリを圧縮してTCP/IPで転送。これが既定。CPUに余裕があり回線が細いなら効く。
- SMB：
SMB 3.0で転送。NICがRDMA対応ならSMB Directが、適切に構成されていればSMB Multichannelが自動的に使われる。
SMB DirectはiWARP／RoCE／InfiniBandといったRDMA対応NICを使い、Microsoft Learnの言葉を借りれば「full speed with lower latency without compromising CPU utilization（CPUを食わずに低遅延・フルスピード）」で転送します。10GbEを超える広帯域NICを持っているなら、圧縮でCPUを焼くよりSet-VMHost -VirtualMachineMigrationPerformanceOption SMB でSMB Directに寄せたほうが速く、ホストのCPUも空きます。RDMAの束ね方はSET（Switch Embedded Teaming）とMultichannelが担います。
この辺りのRDMA／SETの勘所はS2DのネットワークとRDMA／SET設計で詳しく扱っています。ライブマイグレーション網の帯域とMTU、QoSは、S2Dのストレージ網と同じ緊張感で設計する価値があります。
05クラスタの外、ドメインを跨ぐ移行
Shared Nothingはクラスタを前提としません。だからこそクラスタ外のホスト間、あるいは別クラスタのメンバー同士でも成立します。要件はシンプルで、Microsoft Learnは「同一のActive Directoryドメイン、または相互に信頼するドメインに属すること（domains that trust each other）」と明記しています。
つまり、旧クラスタと新クラスタが別物でも、両者が同じドメイン（あるいは信頼関係のあるドメイン）にあり、ホスト間で委任と転送網が通っていれば、VMを1台ずつ無停止で新基盤へ渡していけます。移行の順番も自由に組めます。ただしプロセッサ互換には注意が必要で、世代の違うCPU間ではVMのプロセッサ互換モード（Set-VMProcessor -CompatibilityForMigrationEnabled $true）を有効化しないと、スナップショットを持つVMなどで弾かれます。
06ハードウェア更改・段階移行での使いどころ
この機能がいちばん光るのは、既存クラスタを止めずにハードウェアを更改する場面です。新ホストを1台用意し、旧ホストのVMをShared Nothingで新ホストへ逃がし、空いた旧ホストを撤去・更改する——これを繰り返せば、ローリングでハードウェアを入れ替えられます。Storage Spaces Direct（S2D）クラスタの更改でも、いったんVMをクラスタ外の一時ホストへ退避させる逃げ道として有効です。
もう一つはオンプレから次期基盤への段階移行です。旧世代のHyper-Vから、Windows Server 2025で組んだ新しいS2Dクラスタへ、業務を止めずにVMを少しずつ移していく。全システムを一斉に切り替える「ビッグバン移行」の怖さを避けられます。新基盤の設計はWindows Server 2025 DatacenterでのS2D設計にまとめています。
07AWSへの移行とは何が違うのか
ここまで読むと「同じ理屈でAWSへも無停止で移せるのでは」と思われるかもしれませんが、そこは明確に線を引くべきです。Shared Nothing Live MigrationはHyper-Vホスト間の技術であり、ハイパーバイザもドメインも共有する世界の話です。AWSへVMを運ぶ場合は仕組みが根本的に異なります。
- Shared Nothing（オンプレ内）：Hyper-VのライブマイグレーションでメモリごとVMを移す。真の無停止。前提はAD・Hyper-V・転送網の共有。
- AWSへの移行（P2V）：
AWS Application Migration Service（MGN）などで、稼働中サーバのディスクをブロック単位で継続レプリケーションし、カットオーバー時にEC2として起動する。メモリ状態は運ばず、短い停止（カットオーバーウィンドウ）を伴う。
とはいえ、両者は無関係ではありません。VHDX・世代・プロセッサ互換・AD依存といったオンプレHyper-Vを深く理解しているほど、AWSへのP2V設計もクリーンになります。どのVMを無停止でオンプレ内に寄せ、どれをカットオーバーでクラウドへ渡すか——その仕分けこそ移行計画の肝です。手順の詳細はMGNによるP2V移行、Windows特有の落とし穴はWindows Server移行の落とし穴にまとめています。
08Azure Local（旧Azure Stack HCI）との棲み分け
「無停止でVMを動かすならAzure Localでは」という声もあります。整理すると、Azure Localはクラスタ内の可用性を前提としたHCI基盤で、S2DとフェールオーバークラスタでVMを守る世界です。一方Shared Nothing Live Migrationはクラスタの枠にとらわれず、スタンドアロンや別クラスタ間でVMを動かすための道具です。両者は競合ではなく、レイヤーが違います。
製品名やライセンス、対応バージョンは更新が速い領域です。Windows Server 2025のS2D新機能（薄いプロビジョニング、キャンパスクラスタ等）やAzure Localの位置づけは、実装前に必ずMicrosoft Learnで最新を確認してください。ここに挙げたコマンドや既定値も、環境とバージョンで挙動が変わり得ます。
—まとめ
Shared Nothing Live Migrationは、「共有ストレージが無ければ無停止移行できない」という前提を崩す、地味だが強力な機能です。ポイントを絞ると次の4点です。
- VMのメモリとVHDXを同時に運び、必要なのは事実上イーサネットだけ。クラスタ外・別クラスタ間でも成立する。
- 最大の関門は認証。
Windows Server 2025ではKerberos制約付き委任が事実上必須（Credential Guard既定有効でCredSSP不可）。 - 広帯域NICがあるならSMB Direct（RDMA）に寄せると速くCPUも空く。転送網はS2D網と同じ緊張感で設計する。
- ハードウェア更改やオンプレ→次期基盤の段階移行で真価を発揮する。ただしAWSへの移行はP2V（MGN）で、仕組みも停止の性質も別物。
当社は、S2D（Windows Server 2025 Datacenter）の構築、Hyper-Vライブマイグレーションの移行、その土台となるAD構築まで、実際に手を動かしてきました。オンプレの更改から次期基盤・AWSへの橋渡しまで、フェーズごとに正しい手段を選ぶ設計をご支援します。導入事例もご覧ください。