Windows Server 2019 の Hyper‑V クラスターで 250 台規模の仮想マシンを動かしながら、新しい Windows Server 2025 ノードへ「ほぼ無停止」で移行したい──そんなときにまず考えるのが「既存クラスターへ 2025 ノードを足してライブ マイグレーションで移せないか？」という案です。本記事では、この疑問に対する結論と、実際に現実的で安全な移行方法を、設計ポイントやチェックリスト付きで詳しく解説します。
シナリオと前提の整理
まず、よくある想定シナリオを整理しておきます。
- 現状構成
- OS：Windows Server 2019 Datacenter
- 構成：8 ノードの Hyper‑V フェールオーバー クラスター
- VM 数：約 250 台（業務システム、ファイルサーバー、VDI など混在）
- ストレージ：FC / iSCSI / SMB 3.0 + CSV などの共有ストレージ
- 新規構成
- OS：Windows Server 2025 Datacenter（新規ハードウェア 6 台）
- 目的：既存 VM を順次 2025 クラスターへ移行し、最終的に 2019 クラスターを退役
- 要件：可能な限り「無停止」（少なくとも業務時間の停止無し）で移行したい
ここでよく出る質問が次のとおりです。
Q. Windows Server 2025 ノードを既存の Windows Server 2019 Hyper‑V クラスターに直接参加させて、そのままライブ マイグレーションだけで移行できないか？
結論：Windows Server 2019 クラスターに Windows Server 2025 ノードは「追加できない」
結論から言うと、Windows Server 2019 の Hyper‑V クラスターに Windows Server 2025 ノードを直接参加させることはサポートされていません。Microsoft Q&A でも同様の質問に対し、2019 クラスターへ 2025 ノードを追加する構成はサポート外であり、新たに 2025 クラスターを構築して移行するように回答されています。
また、Windows Server 2025 では「Cluster OS Rolling Upgrade（クラスター OS ローリング アップグレード）」の仕組みが継続強化されていますが、クラスター OS のアップグレードは常に「1 バージョンずつ」しか行えないと明記されています。2019（機能レベル 10）から 2025（機能レベル 12）へ一気に飛ぶことはできず、間に 2022（機能レベル 11）を挟む必要があります。
つまり、
- 2019 ノード ＋ 2022 ノード … 混在クラスター（ローリング アップグレード用）としてサポート
- 2022 ノード ＋ 2025 ノード … 混在クラスターとしてサポート
- 2019 ノード ＋ 2025 ノード … 混在クラスターとして 非サポート
という整理になります。
バージョン組み合わせのイメージ
| クラスター内 OS 組み合わせ | 状態 | 用途 |
|---|---|---|
| 2019 のみ | サポート | 通常運用 |
| 2019 ＋ 2022 | サポート | 2019 → 2022 への Cluster OS Rolling Upgrade 期間中のみ |
| 2022 のみ | サポート | 通常運用 |
| 2022 ＋ 2025 | サポート | 2022 → 2025 への Cluster OS Rolling Upgrade 期間中のみ |
| 2019 ＋ 2025 | 非サポート | クラスター参加自体が不可 |
したがって、「既存 2019 クラスターに 2025 ノードを足す」という移行プランは、仕様・サポート両面から実現できません。
なぜ 2019 ＋ 2025 の混在クラスターが NG なのか
2019 クラスターへ 2025 ノードを参加させられない理由は、単なる「サポートポリシー」の話だけではなく、内部実装の観点からも合理性があります。
クラスター機能レベルと互換モードの制約
- Windows Server クラスタリングでは、OS バージョンごとに「ClusterFunctionalLevel」が定義されています（2019=10、2022=11、2025=12 など）。
- Cluster OS Rolling Upgrade では、新旧 OS が一時的に混在する「Mixed‑OS モード」が存在しますが、常に隣り合うバージョン同士（例：2019＋2022、2022＋2025）のみを対象としています。
- 2019 と 2025 のように 1 世代飛び越えた組み合わせは、互換モードの設計範囲から外れており、ストレージ メタデータやクラスター内部プロトコルの互換性が保証されません。
ネットワーク／ストレージまわりの変更
Windows Server 2022 以降では、以下のような変更も入っています。
- Hyper‑V での LBFO NIC チーミングの非サポート（代わりに Switch Embedded Teaming, SET を利用）
- Network ATC によるクラスター ネットワーク構成の一元管理
- Storage Spaces Direct や CSV に関するメタデータ・フェイルオーバー挙動の強化
2019 と 2025 を同一クラスターで混在させると、これらの差分が「古いノードの制約」と「新しいノードの機能」を同時に満たさなければならず、非常に複雑な互換性問題を生じます。そのため Microsoft は、隣接バージョン同士の一時的混在のみを許可し、それ以外は新クラスターへの移行を推奨しています。
推奨構成：新規 Windows Server 2025 クラスター＋クロスクラスター ライブ マイグレーション
ではどうすればよいかというと、Microsoft の公式回答も含め、ベストプラクティスは非常にシンプルです。
- 6 台の Windows Server 2025 ノードで新しい Hyper‑V クラスターを作成する。
- 2019 クラスターと 2025 クラスターの両方から同じ共有ストレージにアクセスできるようにする（またはストレージ レプリケーションを構成）。
- 両クラスター間でクロスクラスター ライブ マイグレーションを有効にし、VM を順次移行する。
ここでいう「クロスクラスター ライブ マイグレーション」とは、同じドメイン内（あるいは信頼関係のあるドメイン）の別クラスター間で、同一ストレージ上の VM を生かしたまま移動させるシナリオです。Hyper‑V では、早くから「同一クラスター内」「別クラスター間」「スタンドアロン同士」など、様々な形態でライブ マイグレーションがサポートされています。
現行クラスターと新クラスターの比較イメージ
| 項目 | 旧クラスター（2019） | 新クラスター（2025） | 移行におけるポイント |
|---|---|---|---|
| ノード数 | 8 台 | 6 台 | 2025 ノードのほうがハードウェア性能が高い前提 |
| OS バージョン | Windows Server 2019 | Windows Server 2025 | 2019 クラスターへ 2025 ノードの直接参加は不可 |
| ストレージ | 既存 SAN / SMB / S2D | 同一ストレージを共有、またはレプリケーション | パスや CSV 名が両クラスターで一致していることが重要 |
| ネットワーク | 既存 vSwitch, VLAN, チーミング | SET + Network ATC 等 | ライブ マイグレーション用ネットワークを共通設計にする |
| VM 構成 | VM バージョン 8.0〜10.0 など混在 | VM バージョン 12.0 までサポート | 古い VM 構成バージョンの取り扱いに注意 |
移行方式の候補と比較
2019 から 2025 への移行方式は大きく分けて次の 3 パターンが考えられます。
| 方式 | 概要 | 長所 | 短所 |
|---|---|---|---|
| ① クラスター OS ローリング アップグレード（多段） | 2019 → 2022 → 2025 と段階的に OS アップグレード | 同一クラスター名を維持できる | 2 回のメジャーアップグレードが必要で手間・リスクともに大きい |
| ② 新 2025 クラスター ＋ クロスクラスター LM | 2019 クラスターと並行して 2025 クラスターを構築し、ライブ マイグレーション | 旧環境を温存しながら、無停止に近い移行が可能 | 一時的にストレージやネットワーク設計が複雑になる |
| ③ エクスポート／インポート、共有なしライブ マイグレーション | 共有ストレージを使わず、Move‑VM などで VM とストレージごと移動 | 共有ストレージが共用できない環境でも利用可能 | VM ごとに時間がかかり、短時間の停止が発生しがち |
250 台規模・8 ノードから 6 ノードへのリプレースという前提では、②「新 2025 クラスター＋クロスクラスター ライブ マイグレーション」方式が、作業工数とリスクのバランスが最もよく、Microsoft のサポート モデルにも沿った方法になります。
クロスクラスター ライブ マイグレーションの要件とチェックポイント
共有ストレージの要件
クロスクラスター ライブ マイグレーションの前提として、基本的に両クラスターから同一ストレージ上の VM ファイルにアクセスできることが必要になります。
- SAN（FC / iSCSI）＋ CSV
- 全ノード（2019 / 2025）の HBA / NIC から同一 LUN をマッピング
- CSV 名（例：
C:\ClusterStorage\Volume1）が両クラスターで同じになるように構成
- SMB 3.0 ファイル共有（SOFS など）
- ファイルサーバー クラスターは 2019 / 2022 / 2025 など、互換性のある OS で構成
- 2019 クラスターと 2025 クラスターのコンピューター オブジェクトの両方に対し、共有フォルダーに適切な NTFS / SMB 権限を付与
- Storage Replica / サードパーティ製レプリケーション
- ストレージを物理的に共有できない場合は、一次側（2019 側）→ 二次側（2025 側）へのブロック複製を構成
- レプリカ先に対して 2025 クラスターから CSV を構成し、共有ストレージとして扱えるようにする
ネットワーク設計（ライブ マイグレーション ネットワーク）
Hyper‑V の公式ドキュメントでは、ライブ マイグレーション用に専用のネットワーク（または VLAN）を用意し、他のトラフィックと分離することが推奨されています。
- クラスター内とクロスクラスター用で、ライブ マイグレーション ネットワークを明示的に指定する
- 帯域は 10GbE 以上を目安（GPU-P や大容量メモリ VM が多い場合は 25GbE 以上を検討）
- QoS（ネットワーク / SMB トラフィック）で、他の業務トラフィックへの影響を抑制
- 2019 ノードと 2025 ノード間で、同一 IP セグメントまたはルーティングが確立されていること
ライブ マイグレーション ネットワークを正しく分離しておくことで、業務時間中でも少数ずつ VM を流し続ける「ダラ移行」戦略が取りやすくなります。
CPU 世代の違いと「プロセッサ互換性モード」
旧クラスターと新クラスターで CPU 世代やベンダーが違う場合（例：旧 Intel、 新 AMD）、Hyper‑V のライブ マイグレーションではそのままでは移動できないケースがあります。
- VM 設定の「プロセッサ」から 「異なるプロセッサ バージョンの物理コンピューターへの移行を許可する」（プロセッサ互換性モード）を有効化
- これにより、VM に見える CPU 機能セットが下位互換な共通サブセットに制限されるため、わずかに性能が落ちる可能性がある点には注意
- 移行完了後、すべての VM が 2025 クラスター上で落ち着いたタイミングで、必要に応じて互換性モードを解除し、ベンチマークなどで性能を確認する
VM 構成バージョンの確認
Windows Server 2022 以降のクラスターでは、古い VM 構成バージョン（Version 8.0 未満）はサポートされないため注意が必要です。2025 クラスターでは VM 構成バージョン 12.0 までサポートされ、Mixed 環境の VM を順次アップグレードしていく想定です。
| VM 構成バージョン | 対応する OS 世代 | 2025 クラスター上での動作 |
|---|---|---|
| 5.x〜7.x | 2012 R2 世代 | 2022 以降では非サポート（事前アップグレードが必要） |
| 8.x | 2016 世代 | 動作自体は可能だが、新機能は利用できない |
| 9.x〜10.x | 2019 / 2022 世代 | 多くの環境でそのまま移行可能 |
| 12.0 | 2025 世代 | 2025 の新機能をフルに利用可能 |
移行前に Get-VM や Get-VMHostSupportedVersion コマンドで構成バージョンを棚卸しし、旧すぎる VM は 2019 クラスター上で一度アップグレードしておくとスムーズです。
認証方式と委任設定
クラスター間ライブ マイグレーションでは、通常以下のような認証が関わります。
- Active Directory ドメインに参加したホスト同士での Kerberos 認証
- ホスト コンピューター オブジェクトに対する制約付き委任（Constrained Delegation）の設定（必要な場合）
- ワークグループ クラスター間のライブ マイグレーションでは、Windows Server 2025 からローカル アカウント＋PKU2U 証明書による認証がサポートされるようになったが、本記事のシナリオでは通常 AD ドメイン クラスターを想定
移行前チェックリスト（まとめ）
| 項目 | チェック内容 | 具体的な確認ポイント |
|---|---|---|
| VM 構成バージョン | 2025 でサポートされるバージョンか | 構成バージョン < 8.0 の VM がないか、Get-VM で確認 |
| CPU 互換性 | 異なる CPU 世代間での LM が可能か | 必要に応じて「プロセッサ互換性モード」を有効化 |
| ネットワーク | LM 用ネットワークの帯域・分離 | VLAN / QoS 設定が 2019 / 2025 間で一致しているか |
| ストレージ パス | 両クラスターから同一パスでアクセス可能か | LUN / SMB 共有のマウントポイントと CSV 名を事前検証 |
| バックアップ | 移行失敗時に戻せるか | 最新フルバックアップ＋テスト リストアの実施 |
| 運用監視 | 移行時の障害検知能力 | イベントログや監視ツールのアラート閾値を一時的に調整 |
推奨移行手順（ステップ バイ ステップ）
ステップ 1：Windows Server 2025 ノードの構築
- すべての新ノードに Windows Server 2025 Datacenter をクリーンインストール
- 最新の累積更新プログラムとファームウェア／ドライバーを適用
- Active Directory ドメインに参加させ、サーバー名の命名規則（例：HV25‑01〜06）を統一
- Hyper‑V、Failover Clustering、Network ATC など必要な役割と機能をインストール
- SET（Switch Embedded Teaming）ベースの vSwitch を作成し、2019 クラスターと同じ VLAN/サブネットを割り当て
ステップ 2：新しい 2025 Hyper‑V クラスターの作成
- Failover Cluster Manager または PowerShell（
New-Cluster）で 6 ノード クラスターを作成 - クラスター検証（Validate Cluster）を実行し、Error がないことを確認（Warning は内容を精査）
- クラスター名・IP アドレスを定義し、DNS 登録を確認
- 必要であれば、クラスター作成直後に Cluster‑Aware Updating（CAU）や Network ATC のポリシーも合わせて設計
ステップ 3：共有ストレージのマッピング
- 現在 2019 クラスターで利用している LUN / SMB 共有を、2025 クラスターの各ノードにもマッピング
- CSV を利用している場合は、誤って 2025 側から新規フォーマットやサイズ変更を行わない（Mixed 環境では非推奨）
- Storage Replica やサードパーティ レプリケーションを使う場合は、先に 2025 側の LUN を初期化して CSV を構成し、その後複製を切替える計画を立てる
ステップ 4：テスト VM でクロスクラスター ライブ マイグレーションを検証
いきなり本番 VM から移行を始めるのではなく、まずは小さなテスト VM を数台用意して検証します。
- 2019 クラスター上のテスト VM（1〜2GB メモリ程度）を選択
- Hyper‑V Manager や System Center VMM を使い、2025 クラスターの任意ノードを移行先としてライブ マイグレーション
- 移行中の VM の ping 応答やアプリケーション レスポンスをモニタし、停止時間が「数百ミリ秒〜数秒」程度に収まることを確認
- 移行完了後、VM のイベントログやアプリケーション ログに異常がないかをチェック
この段階で問題が出る場合は、多くがネットワーク設定（ライブ マイグレーション用ネットワークの選択ミスや DNS / SPN 問題）か CPU 互換性の設定不足です。
ステップ 5：本番 VM の移行計画とバッチ設計
250 台の VM を一気に移すのではなく、以下のようにバッチに分割して段階的に移行するのが現実的です。
- 重要度・システム種別でグルーピング
- 第 1 バッチ：開発／検証系、影響度の低いファイルサーバーなど
- 第 2 バッチ：中規模業務システム
- 第 3 バッチ：基幹系・ミッションクリティカルなシステム
- 各バッチ内で、1 回のメンテナンス ウィンドウ中に移行する VM 数を調整
- 例：10GbE 環境であれば、ノード間で並列 4〜8 台程度から開始し、ネットワーク負荷を見ながら調整
- バッチ移行ごとに、アプリケーション担当者と簡易な動作確認（疎通／ログイン／主要画面の表示まで）を実施
ステップ 6：VM の定着と旧クラスターの退役
すべての VM が 2025 クラスターへ移行し安定運用に入ったら、以下の作業で環境を整理します。
- VM 構成バージョンのアップグレード（必要に応じて計画停止の上で
Update-VMVersion） - バックアップ ソフトウェア側でのジョブ定義やターゲット ホスト名の更新
- 監視設定（CPU / メモリ / ディスクレイテンシなど）の閾値見直し
- 2019 クラスター上に残っているリソース（空の CSV、古いクラスター ロールなど）の整理
- 2019 クラスターのノードを順次クラスターから削除し、OS 再利用 or 退役
移行時のベストプラクティスとよくある落とし穴
Cluster Validation を「移行中」も定期的に実行する
多くの環境では、クラスター新規構築時にしか Validation を回しませんが、大規模移行の期間中こそ定期的に実行することを推奨します。
- ネットワーク トポロジやストレージ構成を少し変更しただけでも、潜在的な Warning が検出されることがある
- 特に、SAN ゾーニングや iSCSI ターゲットの変更後は Validation を回しておくと安心
LBFO NIC チーミングから SET への移行に注意
2019 クラスター側で LBFO ベースの NIC チーミングを使っている場合、2022 以降の Hyper‑V では LBFO が非推奨／非サポートになっているため、2025 クラスターでは SET ベースの構成に統一する必要があります。
- 2019 クラスター側：既存構成はそのまま維持
- 2025 クラスター側：SET + vSwitch でネットワークを設計し、VLAN 設定や IP アドレス設計だけを 2019 と合わせる
- 将来的には、ネットワーク全体を SET に揃えることを見据え、標準化ドキュメントを整備
インテグレーション サービス（ゲスト拡張）の更新
Windows ゲスト OS では、Windows Update を通じて Hyper‑V インテグレーション サービスが自動更新される仕組みになっていますが、古いテンプレートから展開した VM などでは、サービス バージョンが古いままになっていることがあります。
- 移行後、ゲスト OS 内で「プログラムと機能」「デバイス マネージャー」を確認し、古い仮想 NIC ドライバーや不要な統合コンポーネントが残っていないかチェック
- テンプレート VM も含めて最新版の統合サービスに更新しておくと、今後のトラブルシューティングが楽になります
ワークグループ クラスター／ブランチ環境の特例
本記事のメイン シナリオはドメイン参加クラスターですが、Windows Server 2025 では ワークグループ クラスター間のライブ マイグレーションも正式にサポートされています。
ブランチ オフィスなど、ドメイン コントローラーを置いていない小規模拠点では、「中心拠点：ドメイン クラスター」⇔「拠点：ワークグループ クラスター」のような組み合わせも見えてきます。将来的な設計として頭の片隅に置いておくとよいでしょう。
長期的な視点：次のアップグレードを楽にする設計
今回は「2019 → 2025 への移行」がテーマですが、当然この先も Windows Server の新バージョンや Azure Stack HCI への移行は続いていきます。
次回以降のアップグレードを楽にするために、以下のポイントを盛り込んだ設計にしておくと良いでしょう。
- ストレージ スタックの標準化
- 可能であれば S2D（Storage Spaces Direct）や Azure Stack HCI など、ソフトウェア定義ストレージで統一
- クラスター OS ローリング アップグレードに最適化された構成を選ぶ
- Network ATC によるネットワーク標準化
- 2025 クラスターでは Network ATC を活用し、「管理」「ストレージ」「ライブ マイグレーション」「クラスター」などのネットワーク プロファイルをコード化
- 将来のノード追加や OS アップグレード時にも、同じテンプレートを適用するだけで済むようにする
- VM 構成バージョン管理のルール化
- 新規 VM は常に最新の構成バージョンで作成
- 大きなプラットフォーム更改ごとに、対象 VM の構成バージョンを一括で引き上げる運用ルールを作成
まとめ：2019 クラスターへ 2025 ノードは追加不可、新クラスター併設が最短ルート
ここまでの内容を改めてまとめると、ポイントは次の 3 つです。
- Windows Server 2019 と 2025 を同一 Hyper‑V クラスターに混在させることはサポートされていない。したがって「2019 クラスターに 2025 ノードを追加」は不可。
- 無停止に近い移行を実現するには、6 台の 2025 ノードで新クラスターを構築し、共有ストレージを両クラスターから参照できるようにした上で、クロスクラスター ライブ マイグレーションを用いる。
- 移行前のチェック（VM 構成バージョン、CPU 互換性、ネットワーク、ストレージ パス、バックアップ）と、小さなテストから始める段階的な移行計画が成功の鍵。
「既存クラスターに 2025 ノードを追加」する近道は残念ながら存在しませんが、新クラスター併設＋クロスクラスター ライブ マイグレーションという王道パターンを採用すれば、250 台規模の環境でも現実的なスケジュールとリスクで移行を完遂できます。次の OS 更改を見据えたストレージ・ネットワーク設計も含めて、一度腰を据えて設計を見直してみてください。
コメント