Hyper-Vライブマイグレーション設計 — 認証と性能オプション

ライブマイグレーションは「ボタン一つでダウンタイムゼロ」に見えますが、その裏では認証プロトコル・転送方式・CPU互換性・ネットワーク分離という設計判断が積み重なっています。本稿では、これらを現場でハマる順に整理します。

ライブマイグレーションは、稼働中の仮想マシンを別のHyper-Vホストへ、ネットワーク接続を切らさず、体感上のダウンタイムなしで移す機能です。デモでは「ボタン一つ」に見えますが、実際に設計するとなると、認証プロトコルの選択、転送方式(性能オプション)、CPUの互換性、そしてネットワークの分離という、少なくとも4つの判断が絡みます。どれか一つでも詰めが甘いと、本番当日に「認証エラー」「予想外の遅さ」「移行先で起動しない」といった形で表面化します。本稿では、私たちが実際にHyper-V基盤の構築・移行で踏んだ勘所を、ハマりやすい順に整理します。

01ライブマイグレーションで何が起きているのか

まず内部動作を押さえます。ライブマイグレーションは、大きく分けて次のステップで進みます。移行元ホストが移行先ホスト上に空のVMを構成し、稼働中VMのメモリページをネットワーク越しにコピーします。VMは動き続けているので、コピー中も一部のページは書き換わります。書き換わったページ(ダーティページ)は差分として繰り返し転送され、残りが十分小さくなった瞬間に、ごく短い時間だけVMを一時停止し、最後の差分とCPU/デバイス状態を移してから移行先で再開します。この最終切り替えの停止時間が、体感上のダウンタイムに相当します。

ここで重要なのは、共有ストレージ構成(フェールオーバークラスター＋CSV)であればディスクは移動せずメモリだけを転送する、という点です。ストレージも一緒に運ぶ「共有なしライブマイグレーション」は転送量が桁違いになります。本稿は主に共有ストレージ前提のクラスター内移行を扱いますが、共有なし移行の設計は別記事「Hyper-V 共有なしライブマイグレーション」で扱います。

02認証プロトコル：KerberosかCredSSPか

設計で最初に決めるべきは認証方式です。Hyper-VはCredSSPとKerberosの2択で、選択によって「運用の手触り」が大きく変わります。Microsoft Learnの整理はシンプルです。Kerberosはサーバーへのサインインが不要な代わりに制約付き委任(Constrained Delegation)の事前設定が必要、CredSSPは制約付き委任の設定が不要な代わりに、移行元サーバーへ実際にサインインしている必要がある、という対比です。

CredSSPの厄介さは、この「サインインしていないと動かない」が直感に反する形で出る点にあります。TestServer01にサインインしてVMをTestServer02へ移した後、それを戻そうとすると、今度はTestServer02にサインインしていないと失敗します。エラーは No credentials are available in the security package 0x8009030E. という、初見だと原因を掴みにくいメッセージです。SCVMMやスクリプトからリモートで一括移行したい運用では、この単一ホップ制約が地味に効いてきます。

03【重要】Windows Server 2025ではCredSSPが使えない

ここが2025年時点で最もハマる落とし穴です。Windows Server 2025では、ドメイン参加済みかつドメインコントローラーでないサーバーで、Credential Guardが既定で有効になりました。この結果、Windows Server 2025へアップグレードした後は、Hyper-VでCredSSPベースのライブマイグレーションが使えなくなります。Windows Server 2022以前はCredSSPが既定だったため、既存環境をそのままアップグレードすると、ある日突然ライブマイグレーションが通らなくなる、という事故が起こり得ます。

Microsoft Learnの明確な推奨は、Windows Server 2025ではKerberos制約付き委任を使うことです。私たちがWindows Server 2025 Datacenterで基盤を組む際は、この一点を理由に、設計段階からKerberos前提で制約付き委任のADオブジェクトまで含めて計画します。ライブマイグレーション用のAD設計そのものは「クラスターとライブマイグレーションのためのAD設計」で深掘りしています。

04Kerberos制約付き委任の設定勘所

Kerberosを選んだ場合、移行に関わる両ホストのコンピューターアカウントに対して、Active Directoryユーザーとコンピューターの[委任]タブで「指定されたサービスへの委任でのみこのコンピューターを信頼する」＋「任意の認証プロトコルを使用する」を設定します。委任先には相手ホストを指定し、サービスとして次の2つを登録します。

• Microsoft Virtual System Migration Service — VM本体(メモリ・状態)を移すために必須。
• cifs — VMのストレージを一緒に移す場合、またはストレージのみを移す場合に必要。SMBストレージ上でHyper-Vを構成しているなら、通常は既に選択済みです。

設定は双方向で必要です。移行元ホストのアカウントに移行先を委任先として登録し、移行先ホストのアカウントにも移行元を登録します。よくある失敗は片側だけ設定して「片道は通るのに戻せない」というものです。もう一点、設定はドメインコントローラーへ複製され、新しいKerberosチケットが発行されて初めて有効になります。設定直後に動かないときは、複製待ちかチケットの更新待ちを疑ってください。制約付き委任の具体的な設計は「ライブマイグレーションのKerberos制約付き委任」で詳述します。

05性能オプション：TCP/IP・圧縮・SMB Direct(RDMA)

転送方式はホスト単位の設定で、そのホストから開始される全ライブマイグレーションに適用されます。Hyper-V Managerの[Live Migrations]→[Advanced Features]、またはPowerShellのSet-VMHost -VirtualMachineMigrationPerformanceOptionで指定します。選択肢は3つです。

• TCP/IP — メモリをTCP/IP接続でそのまま移行先へコピーします。素直ですが帯域とCPUの使い方は最も原始的です。
• Compression(既定) — メモリ内容を圧縮してからTCP/IPでコピーします。これが既定値で、CPUに余力があるがネットワーク帯域が限られる一般的な環境で効きます。
• SMB — メモリをSMB 3.0接続でコピーします。両ホストのNICでRDMAが有効ならSMB Directが使われ、適切なSMBマルチチャネル構成があれば複数接続を自動で束ねます。

SMB Directの肝は、RDMAによってCPUをほとんど使わずに超高速な転送を実現する点です。10GbE超の高速NICが載っていて、かつ大量のVMを短時間で退避させたい(例：ホストのパッチ適用でノードを空にする)ような場面では、SMB＋RDMAが圧倒的です。逆にNICが1GbE中心で圧縮に回すCPUがあるなら、既定のCompressionのままが無難です。RDMAとSMBの詳細設計は「S2DネットワークとRDMA/SET設計」も併せてご覧ください。

06同時実行数とネットワーク設計

[Simultaneous live migrations]の既定値は2です。ここを闇雲に増やすと、1本あたりの帯域が細って全体としてはむしろ遅くなったり、切り替え時のダーティページ収束が遅れたりします。ライブマイグレーション用ネットワークの実効帯域と相談して決める値であって、大きければ良いものではありません。

ネットワーク設計では、ライブマイグレーション専用のネットワーク/VLANを分離するのが原則です。理由は2つ。第一に、ライブマイグレーショントラフィックはリンクを飽和させ得るため、同居する他トラフィック(管理・クラスターハートビート・ストレージ)のレイテンシを巻き込んで悪化させます。第二に、ライブマイグレーショントラフィックは既定で暗号化されません。速度を優先するための仕様であり、だからこそ物理分離やVLANといった信頼できるプライベートネットワークへ隔離すべきです。

フェールオーバークラスターでは、Failover Cluster Managerの[Live Migration Settings]、またはPowerShellでライブマイグレーションに使うネットワークを優先順位付きで明示できます。10GBのクラスター内移行用と、1GBのクラスター間移行用を分ける、といった設計が可能です。クラスターネットワークのRole設定では、ライブマイグレーション用ネットワークは「クラスター通信は許可、クライアント接続は不許可」が推奨です。QoSの重み付けでも、ライブマイグレーションとストレージは高め(例：重み40)に割り当てるのがMicrosoft Learnの目安です。

07CPU互換モード：移行先で起動しない事故を防ぐ

ハードウェア更新時に必ず問題になるのが、移行元と移行先でCPU世代が違うケースです。新しいCPUが持つ命令セット(拡張機能)を使っているVMを、古いCPUのホストへ移すと、ライブマイグレーションが失敗したり、最悪起動できなくなったりします。これを避けるのがプロセッサ互換モードです。

PowerShellではSet-VMProcessor -VMName <名前> -CompatibilityForMigrationEnabled $trueで有効化します。既定では移行に安全な最小限の機能セット(MinimumFeatureSet)にVMから見えるCPU機能を制限し、世代差を吸収します。Windows Server 2025では、クラスター内の全ノードに共通する最大の機能セットを使う動的モード(-CompatibilityForMigrationMode CommonClusterFeatureSet)も選べ、過度に機能を削らずに互換性を取れるようになっています(利用可否・詳細はMicrosoft Learnで最新を確認してください)。

08「ダウンタイムほぼゼロ」の実際と限界

ライブマイグレーションは正しく設計すれば、ping一発すら落とさずに移行できます。これは誇張ではありません。ただし「ほぼゼロ」であって「常にゼロ」ではない、という現実は設計者として押さえておくべきです。

• メモリの書き換えが激しいVM(高負荷DBなど)は、ダーティページの発生速度が転送速度に追いつき、収束に時間がかかります。帯域が細いと最終切り替えの停止時間が伸び、まれにタイムアウトすることもあります。
• 最終切り替えの瞬間には、ごく短いながらVM停止が発生します。ミリ秒〜秒未満のオーダーですが、極端にシビアなリアルタイム処理では影響し得ます。
• ネットワーク経路の切り替えで、移行先のスイッチがMACアドレスの学習を更新するまで、瞬間的なパケットロスが起こる場合があります。

だからこそ、専用の高速ネットワーク、適切な性能オプション、同時実行数のチューニングが効いてきます。「ダウンタイムゼロ」を約束するのではなく、「どこまでゼロに近づけ、どこに限界があるか」を説明できることが、エンタープライズ案件では信頼につながります。

—まとめ

ライブマイグレーション設計は、(1)認証(Windows Server 2025ではKerberos制約付き委任が事実上の前提)、(2)性能オプション(既定は圧縮、高速環境ならSMB Direct/RDMA)、(3)CPU互換モード(世代差の吸収)、(4)ネットワーク分離(非暗号ゆえの隔離とQoS)という4本柱で決まります。デモの手軽さの裏にあるこれらの判断を、事前に一つずつ潰しておくことが、本番当日の「なぜか動かない」を消す最短路です。

そして、このオンプレHyper-Vとメモリ/CPU/ネットワークの深い理解は、AWS移行にもそのまま活きます。オンプレのCPU機能依存やメモリ挙動を把握していれば、EC2インスタンスのサイジングや世代選定の勘所も掴みやすく、無停止移行の考え方はDR設計にも通じます。私たちEMWは、オンプレHyper-V/Windows Serverの実構築から、その先のAWS移行まで、手を動かすコンサルとして一気通貫で支援します。関連して「Windows Server移行の落とし穴」もご覧ください。

—参考(一次情報)

• Set up hosts for live migration without Failover Clustering(Microsoft Learn)
• Network recommendations for a Hyper-V cluster(Microsoft Learn)
• Configure processor compatibility mode in Hyper-V virtual machines(Microsoft Learn)
• Hyper-V Virtual Machine Live Migration Troubleshooting Guide(Microsoft Learn)