既存の3ノード Hyper‑V クラスタを止めずに別ドメインへ移行したい──オンプレのActive Directory環境ではよくある悩みです。本記事では、旧クラスタから新クラスタへノードとVMを少しずつ移動させる「スイング移行」を前提に、認証（Kerberos・制約付き委任）、ストレージ、ネットワーク、クラスタ構成などを含めた実務レベルの手順と注意点を詳しく解説します。
3ノード Hyper‑V クラスタを別ドメインへ移行するシナリオ
ここでは、次のような典型的な構成を想定します。
- 旧ドメインに参加した 3ノード構成の Hyper‑V クラスタ
- 共有ストレージ（CSV）上に 約10台の仮想マシン（VM）
- 新しいActive Directoryドメインへの段階的な移行が必要
- 可能な限り VM停止時間を短くしたい
この要件に対し、次のような移行プランが提示されています。
- 旧クラスタでノードを1台ずつ ドレイン → オフライン → クラスタから除外
- 除外したノードを新ドメインに参加させ、新クラスタを作成（ディスク系クォーラムなど）
- 移行対象VMは、一旦「クラスター管理から外して」スタンドアロンVMとして稼働継続
- 旧側ホスト ↔ 新側ホスト間で ライブ マイグレーションを有効化
- VMを旧→新へライブ マイグレーションし、新クラスタに取り込み
- 残りノードも順に同様の手順で移行
結論から言うと、この方針は Hyper‑V でよく用いられる 「スイング移行」として妥当です。ただし、いくつかの前提条件と「やってはいけないポイント」を押さえておかないと、認証エラーやCSVロックなどで思わぬ停止を招きます。
移行パターンの比較：なぜスイング移行なのか
まずは代表的なクラスタ移行パターンと特徴を整理しておきます。
| 移行パターン | 概要 | メリット | デメリット | 今回シナリオとの相性 |
|---|---|---|---|---|
| インプレース移行 | 既存クラスタをそのまま新ドメインへ参加させる、もしくは同一ホスト上で順次設定変更 | 追加ハードウェア不要、構成イメージをそのまま引き継げる | 一時的にクラスタ全体の信頼性が落ちる。ロールバックが難しい | 停止リスクが高く、推奨しにくい |
| リビルド移行 | 新ドメイン上に新クラスタを別途構築し、VMをエクスポート/インポートなどで移行 | 新環境をクリーンに構築できる。設計の見直しがしやすい | VM停止時間が長くなりやすい。大量VMでは作業時間も長い | 停止許容度が高い場合には有力だが、今回のように最小停止が要求される場合はやや不向き |
| スイング移行 | ノードを1台ずつ新ドメインへ「スイング」させていき、VMはライブ マイグレーションで段階移行 | サービス停止を最小化できる。常に旧環境側へ戻せる逃げ道を残せる | 設計と手順がやや複雑。認証・ストレージ周りの理解が必須 | 今回もっとも現実的で安全な選択肢 |
この記事では、この「スイング移行」を軸に、具体的な前提条件と手順を詳しく見ていきます。
大前提：認証・ネットワーク・ストレージ・クラスタの4本柱
3ノード Hyper‑V クラスタのドメイン移行を安全に行うには、次の4つのポイントを最初に固めておくことが重要です。
- 認証・ドメイン信頼（Kerberos・制約付き委任）
- ネットワーク・DNS・時刻同期
- ストレージ（CSV/LUN）の扱い
- クラスタ/ADオブジェクトとホスト・VMの互換性
認証・ドメイン信頼：Kerberos と制約付き委任
旧ドメインと新ドメインにまたがって ライブ マイグレーションを行うには、原則として次が必須です。
- 旧ドメインと新ドメインの双方向の信頼関係
- Kerberos認証の利用（CredSSPではなく）
- Hyper‑V ホストのコンピュータアカウントに対する制約付き委任（Constrained Delegation）の設定
制約付き委任では、少なくとも下記のサービスを委任先として登録しておきます。
| 委任先サービス | 用途 |
|---|---|
| Microsoft Virtual System Migration Service | Hyper‑V のライブ マイグレーションに使用 |
| CIFS | SMBによるストレージアクセス（SMB 3.0共有など）に使用 |
ADユーザー/コンピュータで各 Hyper‑V ホストのコンピュータアカウントを開き、「委任」タブから上記サービスを指定しておきましょう。
もし、どうしてもドメイン間の信頼関係が用意できない場合は、後述の Hyper‑V Replica または エクスポート/インポート を用いた移行方式に切り替える必要があります。
ネットワーク・DNS・時刻同期のポイント
Kerberosやライブ マイグレーションが正常に動くかどうかは、意外なほど DNSと時刻 に左右されます。
- 旧/新ドメイン双方の DNS から、すべての Hyper‑V ホストの 正引き/逆引き ができること
- ドメインコントローラとホスト間の 時刻差が±5分以内 であること
- ファイアウォールで、ライブ マイグレーション、SMB、RPC、WMI関連のポートが開放されていること
- ライブ マイグレーション用ネットワークと、VM用ネットワークが論理的に分離されていること（パフォーマンスと安全性のため）
ネットワークまわりの「ちょっとしたズレ」が、移行当日の「ライブ マイグレーションが全く動かない」という大事故に直結するので、事前検証が重要です。
ストレージ：同じLUN/CSVを2つのクラスタで「同時に」所有しない
もっとも危険なのが、旧クラスタと新クラスタで 同じLUN/CSVを同時にオンラインにしてしまう ケースです。SCSI予約が衝突し、最悪の場合、データ破損につながります。
- 旧クラスタの CSV は旧クラスタのノードだけが所有する
- 新クラスタでは 別のストレージ（新しいCSV、SMB 3.0共有、ローカルSSDなど） をVM保存先として用意する
- VM移行は 「共有なしライブ マイグレーション」 を使って、VHDXごとコピーする
また、新側のVM格納フォルダには、忘れずに次のような NTFS権限を設定しておきます。
NT VIRTUAL MACHINE\Virtual Machines- Hyper‑V ホストのコンピュータアカウント
- バックアップ製品や管理アカウントに必要な権限
クラスタとActive Directory：CNO/VCOとクォーラム
新ドメイン側のクラスタを作成する際には、AD上のオブジェクトも意識する必要があります。
- CNO（Cluster Name Object）：クラスタ全体を表すコンピュータオブジェクト
- VCO（Virtual Computer Object）：クラスター化された役割（例：ファイルサーバー、VMなど）のためのオブジェクト
事前にクラスタ用のOUを作成し、必要であれば CNO/VCO を 事前ステージング しておくと、運用部門との調整がスムーズです。クラスタ作成後は、必ず Test-Cluster を実行し、クォーラム構成（ディスク / ファイル共有 / クラウド ウィットネス）も適切に設定しましょう。
ホストとVMの整合性：OSビルド・CPU・仮想スイッチ名
移行前に、新旧環境の次の項目を揃えておくと、トラブルを大幅に減らせます。
- Windows Server / Hyper‑V のOSビルド・パッチレベルを可能な限り揃える
- 世代の違うCPUが混在する場合は、VM側で CPU互換モード を有効化する
- 旧クラスタと新クラスタで 仮想スイッチ名とVLAN設定を完全に一致させる
とくに仮想スイッチ名は、ライブ マイグレーション失敗のトップ原因です。「ProdLan」「DMZ」などの名前を事前に統一しておきましょう。
全体フロー：ノードとVMを順にスイングさせる
ここからは、実際の流れをざっくり俯瞰したうえで、詳細手順に入っていきます。
| フェーズ | 概要 | 主な作業 |
|---|---|---|
| 準備 | 認証・ネットワーク・ストレージの基盤を固める | ドメイン信頼、制約付き委任、DNS/時刻同期、FW、保存先ストレージ準備 |
| 新クラスタ構築 | 旧クラスタから切り離したノードで新クラスタを作る | ノードドレイン、旧クラスタから除外、新ドメイン参加、新クラスタ作成、Test-Cluster |
| VM移行 | VMを旧→新へライブ マイグレーションし、新クラスタに取り込み | VMをクラスタ管理から外す、共有なしライブ マイグレーション、新クラスタにVM登録 |
| 残ノード移行 | 残りのノードを順に新クラスタへ組み入れる | ドレイン→除外→新ドメイン参加→新クラスタへ追加 |
| 後処理 | 旧クラスタ/旧ドメイン側の整理と最終確認 | バックアップ/Replica再設定、監視設定変更、旧オブジェクト削除 |
詳細手順：3ノード Hyper‑V クラスタのスイング移行
準備フェーズ：ロールバック前提で設計する
クラスタのドメイン移行では、「何かあったら元の構成に戻せる」状態をキープすることが重要です。以下を最低限の準備として行いましょう。
- 全VMの直近バックアップを取得（イメージバックアップ＋アプリ整合性）
- Hyper‑V Replica を利用している場合は、設定とレプリケーション状態を確認
- 旧・新ドメイン間の信頼関係を作成（双方向）
- 新旧ホストでライブ マイグレーションを有効化（認証方式は Kerberos）
- Hyper‑V ホストのコンピュータアカウントに対して制約付き委任を設定
- 新クラスタ用のストレージ（新CSVやSMB 3.0共有）を準備し、必要なNTFS権限を付与
- 仮想スイッチ名とVLAN設定を新旧で揃える
可能であれば、ラボ環境やテスト用サーバーで 同じ手順を一度通しておくと、本番での心理的な負担がかなり軽くなります。
Step1：VMをクラスタ管理から外し、スタンドアロン化する
まず、移行対象のVMを 旧クラスタの高可用性役割から外します。VM自体は停止させず、そのままスタンドアロンのHyper‑V VMとして稼働させるイメージです。
- フェールオーバー クラスター マネージャーで該当VMの役割を選択
- 「高可用性の構成を削除」などの操作で、クラスタ管理から外す
- VMが Hyper‑V マネージャー上で通常の VM として残っていることを確認
PowerShellでのイメージとしては、Remove-ClusterGroup コマンドレットでグループを削除する形になりますが、「VM自体を削除しない」ことだけは慎重に確認してください。
Step2：1台目のノードを旧クラスタから除外し、新ドメインへ参加させる
次に、対象VMが載っていないノードを選び、そのノードを新ドメインへ移行します。
- フェールオーバー クラスター マネージャーまたは PowerShell で、対象ノードを 一時停止（Pause）＋ロールのドレイン
- クラスタからノードを除外（Evict）
- サーバーを旧ドメインからワークグループまたは新ドメインへ移行
- 再起動後、新ドメインへ参加
ここでは、共有ストレージ（旧CSV）へのアクセスをそのノードで行わないように注意します。新クラスタ側では別ストレージを使う前提なので、旧CSVをこのノードからマウントしない構成にしておきましょう。
Step3：新ドメイン上で新Hyper‑Vクラスタを作成
新ドメインに参加したノード上で、Hyper‑Vとフェールオーバー クラスタリング機能を確認し、新クラスタを構成します。
- 新ドメイン上でクラスタ用のOU/CNO/VCOを事前に用意しておく
- Failover Clustering管理ツールからクラスタ作成ウィザードを実行
- クォーラムは環境に応じて ディスク/ファイル共有/クラウド ウィットネスから選択
- 作成後、
Test-Clusterを実行し、警告・エラーを確認
この段階では、まだ VM は旧クラスタ上で稼働しており、新クラスタ側は「空の器」という状態です。新クラスタ用CSVやSMB共有をこのタイミングで構成しておくと、後の作業がスムーズになります。
Step4：旧・新ホスト間でライブ マイグレーションを設定し、テストする
いきなり本番VMを移行せず、まずは小さなテストVMで 共有なしライブ マイグレーションが通ることを確認します。
- 旧ホスト・新ホストの両方で、Hyper‑V 設定 → 「ライブ マイグレーション」を有効化
- 認証プロトコルは Kerberos を選択
- ライブ マイグレーションに利用するNIC/ネットワークを指定（専用ネットワークが望ましい）
- テストVMを用意し、旧ホストから新ホストへ共有なしライブ マイグレーションを実施
ここでのポイントは、「共有なし」として移行先の保存先フォルダを 新クラスタ用ストレージに指定することです。CSVやSMB 3.0共有を使う場合は、事前にフォルダ構造やNTFS権限も確認しておきます。
Step5：本番VMを旧→新へライブ マイグレーションし、新クラスタに登録
テストVMの移行が問題ないことを確認できたら、本番VMを順次移行していきます。
- 影響が小さいVMから順に、旧ホストから新ホストへ 共有なしライブ マイグレーションを実施
- VHDXが新ストレージ上にコピーされたことを確認
- 新クラスタ側のホストでVMが起動し、ネットワーク・ディスク・アプリケーションの動作を検証
- 問題がなければ、新クラスタに対してVMをクラスタ化（役割として登録）
VMのクラスタ登録には、PowerShellで次のようなコマンドを利用できます。
Add-ClusterVirtualMachineRole -VirtualMachine <VM名>
登録後は、フェールオーバー クラスター マネージャーから「役割」としてVMが見えるようになります。各VMについて、次の観点で動作確認しておくと安心です。
- VMコンソールが正常に開けるか
- ゲストOSからのネットワーク疎通（クライアント/他サーバー）
- アプリケーションの起動とログ（イベントログ含む）
- バックアップエージェントや監視エージェントの動作
Step6：残りのノードを同様に新クラスタへ組み込む
1台目のノードと一部のVM移行が安定していることを確認できたら、残りの2ノードについても同様の手順でスイング移行していきます。
- 旧クラスタ側で対象ノードを Pause＋Drain
- 旧クラスタからノードを除外（Evict）
- 新ドメインへ参加させ、再起動
- 新クラスタにノードを追加
- 必要に応じて、新クラスタのクォーラム設定を再調整
すべてのVMが新クラスタ上で稼働し、残りの旧クラスタノードが空になった状態で、旧クラスタの役目は終了です。旧ドメイン上のクラスタ関連オブジェクト（CNO/VCO）やDNSレコードを整理し、最後にドキュメントを更新しておきましょう。
代替案：ドメイン間のライブ マイグレーションが使えない場合
組織ポリシー上、旧・新ドメイン間に信頼関係を張れないケースや、Kerberos／制約付き委任の設定が難しい場合には、次の代替方式が現実的です。
Hyper‑V Replica（証明書ベース/HTTPS）を利用する
Hyper‑V Replica を使えば、ドメイン信頼がなくても HTTPS（証明書ベース）でレプリケーションが可能です。
- 旧ホストから新ホストへ Replica のペアリングを設定（証明書ベース）
- 移行前に、VMの状態を新ホストへ事前レプリケーション
- 切替タイミングで 計画フェールオーバー（Planned Failover）を実行
- フェールオーバー後、新ホスト側でVMを新クラスタに登録
この方式では、実際の切替時の停止時間をかなり短くできますが、「Replica用のストレージ容量」や「証明書の準備」が必要になります。
エクスポート/インポートによる移行
もっとも単純だが停止時間が長くなる方式が、VMの エクスポート/インポートです。
| 方式 | 停止時間 | 準備コスト | 適した場面 |
|---|---|---|---|
| ライブ マイグレーション | ほぼゼロ〜数秒 | 認証/ネットワークの調整が必要 | 停止がほぼ許されない本番系 |
| Hyper‑V Replica + 計画フェールオーバー | 数分程度 | 証明書・Replica構成が必要 | 中規模〜大規模環境で停止短縮したい場合 |
| エクスポート/インポート | VHDXコピー時間分（長め） | 構成はシンプル | 停止許容度が高い検証環境・小規模本番 |
本記事のメインシナリオからは外れますが、設計段階で「万一ライブ マイグレーションがどうしても使えなかった場合の最終手段」として押さえておくと安心です。
よくあるハマりどころと対処法
実際に作業すると、ほぼ必ずといっていいほど何かしらのトラブルが発生します。代表的なパターンと対処法を表にまとめます。
| 症状 | 主な原因 | 確認ポイント | 対処方針 |
|---|---|---|---|
| ライブ マイグレーションが認証エラーで失敗 | SPN/制約付き委任の不足、DNS逆引きなし、時刻差 | コンピュータアカウントの委任設定、 DNSのPTRレコード、 ドメインコントローラとの時刻同期 | Kerberos前提条件を再設定後、 テストVMで再検証 |
| CSVがロックされてアクセス不能 | 同じLUN/CSVを旧クラスタと新クラスタで同時所有 | 各クラスタのディスク所有状態、 ストレージの接続状況 | どちらか一方のクラスタで該当CSVをオフラインにし、 所有クラスタを明確にする |
| 移行後、VMのネットワークがつながらない | 仮想スイッチ名やVLANが旧/新で不一致 | Hyper‑V マネージャーで仮想スイッチ設定を比較 | 仮想スイッチ名とVLANを統一し、 必要ならVMのNIC割当を修正 |
| バックアップやReplicaが動作しなくなる | クラスタ名やホスト名が変わり、ジョブ設定が古い | バックアップソフト・Replicaの設定画面、ログ | 新クラスタ/新ホスト名を前提にジョブを再作成 |
| Test-Clusterで多数の警告 | ドライババージョン差、ネットワーク冗長性不足など | Test-Clusterレポート | 本質的なエラー（ストレージ/ネットワーク）を優先的に是正 |
実行前チェックリスト（抜粋）
最後に、本番作業直前の「最終チェック」として使えるよう、要点をチェックリスト形式でまとめます。
| カテゴリ | チェック項目 | 確認方法・メモ |
|---|---|---|
| 認証/ドメイン | 旧・新ドメイン間の信頼関係が構成済み | AD管理ツール/ドメインと信頼関係のコンソールで確認 |
| 認証/ドメイン | Hyper‑V ホストのコンピュータアカウントに制約付き委任を設定済み | 「Microsoft Virtual System Migration Service」「CIFS」が登録されていること |
| ネットワーク | DNS正引き/逆引きが双方のドメインから可能 | pingやnslookupでホスト名/逆引きを確認 |
| ネットワーク | ホストとドメインコントローラの時刻差が±5分以内 | w32tm /query /status などで確認 |
| ネットワーク | ライブ マイグレーション用ネットワークが確保されている | Hyper‑V 設定でライブ マイグレーション用NICを指定 |
| ストレージ | 新クラスタ用の保存先（CSV/SMB/ローカル）が準備済み | 容量・IOPS・NTFS権限・アクセス経路を確認 |
| ストレージ | 旧CSVと同じLUNを新クラスタで使用しない設計になっている | ストレージ管理画面でマッピング状況を確認 |
| クラスタ/AD | 新クラスタのCNO/VCO作成権限を事前に確認済み | 必要ならOUに事前ステージング |
| クラスタ/AD | 新クラスタでTest-Clusterを実施済み | 致命的エラーが無いことをレポートで確認 |
| ホスト/VM | 新旧ホストのOSビルド・パッチレベルが揃っている | winverやPowerShellでバージョン確認 |
| ホスト/VM | 仮想スイッチ名とVLANが新旧で一致している | Hyper‑V マネージャーと構成管理資料で確認 |
| バックアップ | 最新のバックアップと復元テストの実績がある | 少なくとも1台のVMで実機復元テストを実施済み |
| ロールバック | トラブル時に「どこまで戻すか」の基準と手順が決まっている | ノード単位で旧クラスタへ戻すのか、VM単位で戻すのかを事前に決める |
現場で役立つベストプラクティスと小ネタ
- 1台目のノードは「パイロット」と割り切る
1台目のノードと数台のVM移行で得られた知見をもとに、2台目・3台目の作業手順書をアップデートすると、後半のミスが激減します。 - PowerShellトランスクリプトを必ず保存
クラスタ関連の作業はPowerShellで行うことが多いので、Start-Transcriptで操作ログを残しておくと、後からのトラブル解析や監査対応に役立ちます。 - VM名・IP・依存関係を一覧化しておく
どのVMがどのサービスに依存しているかを可視化しておけば、「このVMを先に動かす」「このDNSレコードを先に切り替える」といった判断が素早くできます。 - 移行中は監視やバックアップのアラート設定を一時的に見直す
ホスト名・クラスタ名が変わることで、監視システムやバックアップから大量のアラートが飛ぶことがあります。計画的にメンテナンスモードを設定しておくと、運用チームの混乱を防げます。 - 「停止してもよい時間」を明文化しておく
システムごとに許容停止時間を決めておくと、「このVMはReplica方式で移行する」「このバッチサーバーはエクスポート/インポートで十分」といった切り分けがしやすくなります。
まとめ：ポイントを押さえればスイング移行は十分現実的
3ノード構成の Hyper‑V クラスタを、旧ドメインから新ドメインへ段階的に移行する「スイング移行」は、適切な前提条件を満たせば現実的かつ安全な手段です。
- 旧クラスタからノードを1台ずつ切り離し、新ドメインに参加させて新クラスタを構成
- VMは一旦クラスタ管理から外し、ライブ マイグレーション（もしくはReplica/エクスポート）で新ホストへ移行
- 移行したVMを新クラスタに役割として登録し、動作確認
- 認証（Kerberos＋制約付き委任）、ストレージの同時所有禁止、ネットワーク・権限の事前整備が成功の鍵
この記事で整理したチェックリストとベストプラクティスをベースに、自社環境に合わせた詳細手順書を作成すれば、停止時間を最小限に抑えつつ、3ノード Hyper‑V クラスタの別ドメイン移行を着実に実現できるはずです。
コメント