Info2softは、ウェブサイトでより快適で適切な閲覧体験を提供するためにCookieを使用しています。 プライバシーポリシー
Loading...
著者:
クロスvCenter vMotionはVMware標準搭載機能です。稼働中の仮想マシン（VM）を複数のvCenter Server間で無停止でライブマイグレーションすることが可能です。同一管理クラスタ内でVMを移動する標準vMotionと異なり、本技術は管理境界を超え、柔軟なリソーススケジューリングを実現します。
企業運用において、2つの概念を明確に区別する必要があります。
本来の目的は基盤更改時にアプリケーションを稼働させ続けることです。VMware標準のストリーミング機能は優れた手段ではあるものの、目標を達成するための選択肢の一つに過ぎず、唯一の解決策ではありません。
多くの企業プロジェクトではvCenter間のワークロード移行を実施するため、利用者は自環境に適したソリューションを選定する必要があり、標準vMotionのみに固執するべきではありません。
ハイパーバイザー層において、クロスvCenter vMotionは共有ストレージを使用しない「共有なし型」移行方式で動作します。隔離された環境同士でワークロードを複製する際、ネットワーク経由で2系統のデータストリームを同時に同期します。
データ同期完了後、仮想ネットワークカード（vNIC）が瞬時に移行先ネットワークへ切り替わり、アプリケーションの停止を発生させません。
本プロセスの管理方法は、vCenter Server同士の連携方式によって2種類に分かれます。
標準・拡張モードいずれにおいても、標準vMotionは基盤環境の完全な統一性に強く依存します。この「完全なVMware環境」を要求する厳格な仕様が、実際の企業移行現場でエラーや失敗が発生する主な要因となっています。
標準クロスvCenter vMotionは連鎖的な仕組みのため、一箇所でも条件が満たされないと移行全体が中断されます。自動事前検証に合格するには、移行元・移行先の両環境が同時に以下の厳格な基準をすべて充足する必要があります。
複雑な企業環境において、この完全な統一性を実現することはほぼ困難です。信頼関係のないActive Directoryドメイン、パッチレベルの不整合、遅延の大きなWAN回線、他種ハイパーバイザーが存在する状況では、上記の前提条件が完全に崩れ、標準vMotionを利用できなくなります。
ワークロード移行の規模に応じ、vSphere Client画面または自動スクリプトによる標準クロスvCenter移行を実行できます。
少数のワークロードを臨時で移行する場合、vSphere Clientに標準搭載されたグラフィカルウィザードを利用します。
手順1：エクスポートウィザードを起動
移行元vSphere Clientにログインし、対象の仮想マシンを右クリック、「移行」を選択し、「クロスvCenter Serverエクスポート」を選んで次へをクリック。
手順2：移行先vCenterの認証
移行先vCenterのFQDNまたはIPアドレスを入力し、管理者権限の認証情報（例：administrator@vsphere.local）を記入し、SSL証明書のフィンガープリントを許可。
手順3：移行先コンピュートリソース選択・事前検証実行
移行先のインベントリツリーを展開し、移行先クラスタ、リソースプールまたはホストを選択。事前検証エンジンが「互換性チェック合格」と表示されるのを待機。
手順4：ストレージ・ネットワークのマッピングと実行
移行先データストアを選択し、移行元の仮想ネットワークアダプタ（vNIC）を移行先ポートグループに手動で対応付け、概要を確認後完了をクリック。
連携していない複数のvCenter間で大規模一括移行を実施する場合、VMware PowerCLIスクリプトを活用します。
手順1：独立した2台のvCenter Serverに接続
$SourceVC = Connect-VIServer -Server "source-vc.domain.local" -User "admin@vsphere.local" -Password "SourcePass123!"
$TargetVC = Connect-VIServer -Server "target-vc.domain.local" -User "admin@vsphere.local" -Password "TargetPass123!"
手順2：移行対象インベントリ変数を定義・切り分け
$VMToMigrate = Get-VM -Name "Prod-App-Server-01" -Server $SourceVC
$TargetHost = Get-VMHost -Name "esxi-host-01.target.local" -Server $TargetVC
$TargetDS = Get-Datastore -Name "Target_SAN_Datastore_01" -Server $TargetVC
$TargetPortGd = Get-VirtualPortGroup -Name "VLAN-200-Target-Net" -Server $TargetVC
手順3：インスタンス間Move-VM自動処理を実行
Move-VM -VM $VMToMigrate `
-Destination $TargetHost `
-Datastore $TargetDS `
-NetworkAdapter $VMToMigrate.NetworkAdapters[0] `
-PortGroup $TargetPortGd `
-Server $SourceVC `
-Confirm:$false
資料上の手順は単純に見えますが、実際の運用では課題が多く発生します。移行時間帯には8000番ポート遮断、VMkernelセグメントのルーティング不可、ホストパッチレベルの不整合など予期せぬ障害が頻出します。
結局のところ、標準のワークフローは理想的なVMware環境向けに設計されており、複雑な企業のvCenter間移行現場の実情に対応しきれていません。
クロスvCenter vMotionが失敗する場合、厳格な前提条件に起因する固有のエラーが表示されます。これらのエラーを解消するには単純な設定修正だけでなく、基盤側の根本的な制約へ対処する必要があります。
根本原因：移行元・移行先ESXiホストの専用vMotion VMkernelポート間で、TCP 8000のパケットが相互にルーティングできない状態。
解決策：移行元ホストでSSHを有効化し、双方向のvmkpingを実行して移行先vMotion IPとのL3ルーティングを検証。
vmkping -I vmk1 [移行先vMotion_IP]
コマンドが失敗する場合、物理ネットワーク、ファイアウォールまたはVLANタグによりvMotion通信が遮断されています。
根本原因：移行先ESXiホストのCPUアーキテクチャが古い、または移行元VMの仮想ハードウェアバージョンに対応していない。
解決策：移行先クラスタに拡張vMotion互換性（EVC）を設定しCPU基盤を下位に合わせる、またはウィザード起動前にVM単位のEVCマスクを適用。
根本原因：独立した2台のvCenterアプライアンス間の時刻差が、SAMLトークン認証の許容時間である5分を超過している。
解決策：双方のvCenter管理画面VAMI（`https://vcenter-ip:5480`）にログインし、同一の企業向けNTP階層サーバーと時刻同期を強制実行。
これらのエラーは単なる設定ミスではなく、変更困難な基盤境界の副次的な症状です。企業のセキュリティポリシーによりデータセンター間の8000番ポート開放が禁止されている、または旧来ハードウェアが最新のEVC基盤に対応できない場合、従来のトラブルシューティングでは解決に至りません。
これらの障害は標準vMotionフレームワーク自体の仕様上の制限であるため、プロジェクトのボトルネックを解消するには標準vMotionの枠組みを完全に離れる必要があります。
標準vMotionのエラーが設定ミスではなく変更不可な基盤境界に起因する場合、通常のトラブルシューティングでは対応できません。セキュリティ規則でデータセンター間の8000番ポート開放が禁止されている、旧機器が最新EVC基盤に対応しない状況では、標準機能の枠を超えて以下の根本的な運用制限に対処する必要があります。
つまり標準vMotionは限定的な機能に過ぎず、総合的な移行戦略とは言えません。実際の企業環境では、ハイパーバイザーバージョン、厳格なドメイン信頼関係、ネットワーク制限に依存しない全シナリオ対応のクロスvCenter移行基盤が必要です。
ハイパーバイザー標準機能の制約によりプロジェクトが停滞する場合、複製処理を仮想化層から切り離した企業グレードのライブ移行プラットフォームが必要となります。i2Migrationは複雑なvCenter間・クロスプラットフォーム移行のニーズに対応します。
SSOドメイン依存なし：ゲストOS内部で動作するため、vCenter同士の連携SSOドメイン、共有認証情報、SSL証明書のペアリングが不要
ハードウェア制限なし：ハイパーバイザーの互換性チェックを迂回可能。EVC基盤なしで異なる世代CPU間の移行に対応
WAN回線に最適化：バイト単位の変更追跡とデータ圧縮を活用し、遅延または帯域幅の少ない回線での複製タイムアウトを防止
クロスプラットフォームの柔軟性：ハイパーバイザーロックインを解消。複数バージョンのvSphere、他種ハイパーバイザー（KVM、Nutanix AHV、Proxmox VE）、主要パブリッククラウド間の移行に対応
業務影響を最小限：バックグラウンド同期により本番性能を維持し、最終切り替え時の停止時間を数秒に抑える
いいえ。VHD・VHDXはMicrosoft Hyper-Vのディスク形式であり、VMwareはVMDKのみを使用します。MicrosoftとVMwareのディスク形式相互変換には、専用のクロスプラットフォームツールが必要で、標準vMotionのワークフローでは実施できません。
はい、デフォルトで変更されます。移行先vCenterが移行後に新しいMACアドレスを割り当てます。アプリケーションが固定MACアドレスでライセンス管理を行っている場合は、移行前にネットワークアダプタ設定を静的MACアドレスに変更する必要があります。
はい、対応バージョン範囲内であれば可能です。拡張クロスvCenter vMotionは、移行先ホストがVMハードウェアバージョンに対応している前提で、vSphere 7.0または8.0からvSphere 9.0基盤へ直接ワークロードを移行できます。
標準のクロスvCenter vMotionは統一されたVMware環境では完璧に動作します。一方i2Migrationは、バージョン不整合、WAN遅延、クロスプラットフォームの要件といった実環境のvCenter間移行課題をすべて解決し、信頼性の高い企業グレード移行ソリューションとなります。
