VMware vMotion の 3 種類と実行要件｜帯域・CPU 互換性のポイント

はじめに

VMware vSphere 環境において、稼働中の仮想マシンを停止せずに別の物理ホストへ移行するライブマイグレーション技術が「vMotion」です。ハードウェアの計画メンテナンス、ホスト間の負荷分散、データセンター統合など、サービスを継続したまま運用作業を行うための機能として広く利用されています。

ただし、vMotion を実行するためには CPU 互換性 / ネットワーク帯域 / ストレージアクセス / VM 構成 の各レイヤで一定の要件を満たす必要があります。要件のいずれかが欠けると vMotion は失敗するか、互換性チェックでブロックされます。

本記事では、3 種類の vMotion（vMotion / Storage vMotion / Cross vCenter vMotion）と Long Distance vMotion の違いを整理したうえで、Broadcom 公式ドキュメントに基づく実行要件と、CPU 互換性（EVC）の運用ポイント、よくある失敗パターンまでをまとめます。

VMware vMotion の概要と仕組み

vMotion は、vSphere 環境における運用保守やリソース最適化を支える中核機能です。まずは基本的な動作と、移行時に発生する事象を整理します。

vMotion とは（ライブマイグレーション機能）

VMware vMotion は、稼働中の仮想マシン（VM）の OS やアプリケーションを停止することなく、ある ESXi ホストから別の ESXi ホストへ移動させるライブマイグレーション技術です。

この機能により、システム管理者はサービスを提供したまま物理サーバの計画メンテナンス（ファームウェア更新、部品交換など）を実施できます。また、vSphere DRS（Distributed Resource Scheduler）と連携することで、ホスト間の CPU・メモリ負荷状況を監視し、仮想マシンを自動的に移動させてリソースを最適化することも可能です。

瞬断（短時間のスタン）が発生する仕組みと注意点

vMotion は一般的に「無停止移行」と表現されますが、厳密には移行の最終段階で 短時間のスタン（stun time） が発生します。

移行のプロセスでは、まず仮想マシンのメモリページがバックグラウンドで移行先ホストへ転送されます。メモリのコピーが進むにつれて差分（変更されたページ）も繰り返し転送され、差分が十分小さくなった時点で VM を一瞬停止（スタン）させて最終差分・CPU ステート・MAC アドレス情報などを引き継ぎ、移行先で処理を再開します。

このスタン時間は通常 1 秒未満（典型値は数百ミリ秒） で、Web サーバのような一般的なワークロードでは業務影響は発生しません。一方、ICMP（ping）レベルでは 1〜2 パケット分のロスとして観測されることがあります。レイテンシ要件が厳しいシステム（同期型データベースのトランザクション処理、リアルタイム音声通話など）を移行する場合は、業務影響を考慮して実行タイミングを計画することをおすすめします。

vMotion 中にゲスト OS から見ると、メモリ転送のためにわずかに CPU リソースが消費されることがあります。バルーニングやスワップ起因のパフォーマンス影響については、関連記事『VMware メモリバルーニングとは｜仕組みと esxtop での確認手順』でも整理しています。

vMotion の主要 4 種類と使い分け

「vMotion」と呼ばれる機能には、何を移行対象とするかによって複数のバリエーションがあります。ここでは主要な 4 種類を整理し、最後に比較表でまとめます。

vMotion（ホスト間のコンピューティングリソース移行）

最も基本的な vMotion です。仮想マシンの実体データ（VMDK ファイルなど）は共有ストレージ上に置いたまま、CPU やメモリの稼働状態といったコンピューティングリソースのみを別の ESXi ホストへ移行します。

主な用途はホストの計画メンテナンスや、vSphere DRS によるホスト間の負荷分散です。

Storage vMotion（データストア間のストレージリソース移行）

Storage vMotion（svMotion）は、稼働中の仮想マシンのディスクデータ（VMDK など）を異なるデータストア間で移行する機能です。仮想マシンが稼働している ESXi ホスト自体は変更されません。

主な用途は、ストレージ装置のリプレースや、容量・パフォーマンスを理由としたデータストア間のリバランス、Storage DRS による自動再配置です。

Cross vCenter vMotion（異なる vCenter Server 間の移行）

Cross vCenter vMotion（xMotion）は、異なる vCenter Server 配下の ESXi ホストやデータストアへ仮想マシンを移行する機能です。物理的に離れたデータセンター間の移行や、オンプレミスから VMware Cloud on AWS / Azure VMware Solution などのクラウド環境への移行で利用されます。

Long Distance vMotion（遠距離・高レイテンシ環境向け）

Long Distance vMotion は、vMotion ネットワークの ホスト間 RTT（往復遅延）が 4 ms を超える環境 で利用される vMotion のバリエーションです。

参考: Host Configuration for vSphere vMotion – Broadcom TechDocs（vSphere 8.0）
“The round-trip time between the hosts must be up to 150 milliseconds. Your license must cover vSphere vMotion across long distances.”
（ホスト間の往復時間は最大 150 ミリ秒までである必要があります。Long Distance vMotion をカバーするライセンスが必要です）
https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vcenter-and-host-management/migrating-virtual-machines-host-management/migration-with-vmotion-host-management/host-configuration-for-vmotion-host-management.html

最大 150 ms の RTT までサポートされ、データセンター間の長距離移行や DR 構成の切り替えで利用されます。利用には対応ライセンス（vSphere Enterprise Plus 相当以上）が必要です。

4 種類の比較表

種別	移行対象	ホスト変更	データストア変更	vCenter 変更	主な用途
vMotion	コンピューティング	あり	なし（共有ストレージ前提）	なし	ホストメンテナンス、DRS 負荷分散
Storage vMotion	ストレージ	なし	あり	なし	ストレージリプレース、Storage DRS
Cross vCenter vMotion	コンピューティング / ストレージ（選択可）	あり	任意	あり	DC 間移行、クラウド移行
Long Distance vMotion	コンピューティング	あり	任意	任意	RTT 4〜150 ms 環境での長距離移行

vMotion を実行するための要件

vMotion を正常に実行し、移行時のパフォーマンスとネットワーク接続性を維持するためには、以下のレイヤで要件を満たす必要があります。

ホストおよびネットワークの要件

共有ストレージへのアクセス

通常の vMotion を実行する場合、移行元と移行先の両ホストが、仮想マシンの保存先である同一の共有ストレージ（FC SAN / iSCSI / NFS / vSAN など）へアクセスできる必要があります。

なお、共有ストレージを持たない環境でも、Storage vMotion との併用により vMotion without shared storage（旧称 Enhanced vMotion）として移行が可能です。この場合、VMDK もネットワーク経由で転送されます。

CPU の互換性

移行元と移行先の ESXi ホストで、CPU 機能セットに互換性があることが求められます。Intel と AMD 間の vMotion はサポートされません（同一ベンダ間のみ可）。世代の異なる CPU 間で vMotion を行う場合は、クラスタレベルで EVC（Enhanced vMotion Compatibility）を有効化することで互換性を担保できます。詳細は後述の「CPU 互換性と EVC の運用ポイント」を参照してください。

ネットワーク帯域幅

vMotion 用の VMkernel ポートを用意し、十分な帯域幅を確保する必要があります。Broadcom 公式が定める要件は以下のとおりです。

参考: vSphere vMotion Networking Requirements – Broadcom TechDocs（vSphere 8.0）
“You must ensure that the vMotion network has at least 250 Mbps of dedicated bandwidth per concurrent vMotion session. Greater bandwidth lets migrations complete more quickly.”
（vMotion ネットワークでは、同時 vMotion セッションあたり最低 250 Mbps の専用帯域幅を確保する必要があります。より広い帯域幅を確保するほど移行は速く完了します）
https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vmotion-networking-requirements.html

項目	公式要件 / ベストプラクティス
必須帯域幅	同時 vMotion セッションあたり最低 250 Mbps（公式必須要件）
推奨 NIC	1 GbE（最小推奨）、10 GbE 以上を強く推奨
Long Distance vMotion	最大 150 ms RTT
暗号化 vMotion	vSphere 6.5 以降でサポート

同時 vMotion セッションの上限

ESXi ホスト 1 台が同時に処理できる vMotion 数には上限があり、ネットワーク帯域とリソースコストモデルにより決まります。

参考: vCenter Server Limits on Simultaneous Migrations – Broadcom TechDocs（vSphere 8.0）
“All hosts have a maximum cost per host of 8. For example, on an ESXi 7.0 host, you can perform 2 Storage vMotion operations, or 1 Storage vMotion and 4 vMotion operations.”
（すべてのホストは最大コスト 8 を持ちます。例えば ESXi 7.0 ホストでは、Storage vMotion 2 つ、または Storage vMotion 1 つ + vMotion 4 つを同時実行できます）
https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vcenter-and-host-management/migrating-virtual-machines-host-management/limits-on-simultaneous-migrations-host-management.html

ネットワーク種別	同時 vMotion 数（ESXi ホストあたり）
1 GbE	4
10 GbE 以上	8

これを超える vMotion はキューイングされ、先行する vMotion の完了を待って順次実行されます。

仮想マシンの要件

移行対象となる仮想マシン側にも、構成上の制約があります。以下の状態に該当すると vMotion がブロック、または失敗します。

ローカルデバイスの切断

ホストのローカルドライブにある CD/DVD-ROM の ISO イメージや、ホスト固有のローカルディスクが仮想マシンにマウントされている場合は、移行前に切断する必要があります。

CPU アフィニティの解除

仮想マシンを特定の物理 CPU コアに紐づける「CPU アフィニティ」が設定されていると vMotion は実行できません。

内部ネットワークへの非接続

物理 NIC（アップリンク）を持たない内部専用の仮想スイッチ（vSwitch）に接続されている仮想マシンは、原則として vMotion 対象外です。

RDM（Raw Device Mapping）のアクセス権

仮想マシンが RDM を使用している場合、移行先のホストからもその LUN（論理ボリューム）にアクセスでき、かつ 両ホスト間で LUN ID（NAA / EUI 識別子）が一致 している必要があります。

このセクションで列挙したものは代表的な制約です。これら以外にも、PCI パススルーや vGPU、vTPM、VM 構成バージョン非互換など、近年の構成では追加の制約があります。詳細は後述の「vMotion が失敗する典型的な制約と原因」で整理します。

CPU 互換性と EVC の運用ポイント

vMotion で発生するトラブルの中でも特に多いのが、CPU 互換性に起因する移行失敗です。世代の異なる ESXi ホストを混在させているクラスタでは、EVC（Enhanced vMotion Compatibility）の設計が運用品質を左右します。

EVC（Enhanced vMotion Compatibility）の役割

EVC は、クラスタ内のすべての ESXi ホストに対して 同一の CPU 機能セット（ベースライン）を仮想マシンに提示 することで、世代の異なる CPU 間でも vMotion を可能にする機能です。

参考: CPU Compatibility and vSphere Enhanced vMotion Compatibility – Broadcom TechDocs（vSphere 8.0）
“EVC ensures that all hosts in a cluster present the same CPU feature set to virtual machines, even if the actual CPUs on the hosts differ. Using EVC prevents migrations with vMotion from failing because of incompatible CPUs.”
（EVC は、クラスタ内のホストの実 CPU が異なる場合でも、すべてのホストが仮想マシンに対して同一の CPU 機能セットを提示することを保証します。EVC を使用することで、CPU 非互換による vMotion の失敗を防げます）
https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vcenter-and-host-management/migrating-virtual-machines-host-management/cpu-compatibility-and-evc-host-management.html

EVC は Intel の FlexMigration 技術および AMD-V Extended Migration 技術を利用して、新しい世代の CPU から特定の命令セットをマスクし、古い世代と同等の機能セットに揃えます。

EVC ベースラインの選び方

EVC ベースラインは、クラスタ内で最も古い世代の CPU が対応する範囲のうち、もっとも上位のレベル を選択するのが基本です。例えば、Intel Cascade Lake 世代と Sapphire Rapids 世代が混在するクラスタでは、ベースラインを Cascade Lake 世代に設定することで両世代間の vMotion が可能になります。

EVC ベースラインの設定方針	結果
最古世代より高いベースライン	古い世代のホストがクラスタに参加できない
最古世代と同等のベースライン	クラスタ内全ホストで vMotion 可能（推奨）
最古世代より低いベースライン	vMotion は可能だが、新しい CPU 機能を活用できない

EVC を有効化する際の注意点

EVC をクラスタに後付けで有効化する場合、以下の制約があります。

• 稼働中の VM には適用されない: 既存の電源オン状態の VM は、再起動するまで以前の CPU 機能セットを保持し続けます
• VM の電源サイクルが必要: EVC の効果を完全に反映させるには、対象 VM の電源オフ → オンが必要
• 新規クラスタでは初期から有効化を推奨: 後から有効化するとダウンタイムを伴う手順が必要になるため、新規構築時に有効化しておく方が運用負荷を抑えられます

参考: Enhanced vMotion Compatibility (EVC) Explained – VMware（Broadcom）
“The general recommendation is to have EVC enabled as it will help you in the future where you’ll be scaling your clusters with new hosts that might contain new CPU models.”
（新しい CPU モデルを搭載したホストでクラスタを拡張する際に役立つため、EVC は有効にしておくことが一般的な推奨事項です）
https://www.vmware.com/docs/enhanced-vmotion-compatibility-evc-explained

Per-VM EVC（仮想マシン単位の EVC）

vSphere 6.7 以降で利用可能になった Per-VM EVC は、クラスタ単位ではなく仮想マシン単位で EVC モードを設定できる機能です。

項目	クラスタ単位 EVC	Per-VM EVC
設定範囲	クラスタ内の全 VM	個別 VM
設定変更タイミング	クラスタ設定変更（既存 VM は再起動で反映）	VM 電源オフ時に変更可能
主な用途	同一クラスタ内の vMotion 互換性確保	クラスタを跨ぐ移行 / クラウド移行

Per-VM EVC の主な活用シーンは、異なる vCenter Server や異なる CPU 世代を持つクラスタ間で VM を移行するケース です。VM 自体に EVC モードが属性として保持されるため、電源サイクルでも EVC 設定がリセットされず、移行先の互換性チェックを安定してパスしやすくなります。

参考: Enhanced vMotion Compatibility as a Virtual Machine Attribute – Broadcom TechDocs（vSphere 8.0）
“With Per-VM EVC, the EVC mode becomes an attribute of the virtual machine. A power cycle does not affect the compatibility of the virtual machine with different processors.”
（Per-VM EVC では、EVC モードが仮想マシンの属性として保持されます。電源サイクルがあっても、異なるプロセッサとの互換性に影響しません）
https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/evc-as-a-virtual-machine-attribute.html

CPU 互換性に関するハマりポイント

実運用でつまずきやすい点として、以下が挙げられます。

Intel と AMD 間の vMotion はサポートされない

EVC を設定してもベンダ間の移行は不可

BIOS で必要機能が無効化されているとベースラインに加入できない

Intel の VT-x / AES-NI、AMD の NX などが BIOS でオフになっていると EVC 加入時にエラー

新しい CPU 世代の EVC ベースラインは vSphere バージョン依存

Intel Sapphire Rapids 世代の EVC ベースラインは vSphere 8.0 U1 以降でサポート

Per-VM EVC の変更は VM 電源オフ状態でのみ可能

稼働中の変更は不可

vMotion が失敗する典型的な制約と原因

vMotion は要件が複数レイヤにまたがるため、互換性チェックでブロックされるパターンが多く存在します。ここでは現場で遭遇しやすい原因をカテゴリ別に整理します。

CPU・ホスト起因の制約

原因	概要	対処方針
CPU ベンダ混在	Intel ⇔ AMD 間の vMotion は EVC を設定しても不可	クラスタを CPU ベンダで分離
EVC ベースライン非互換	移行先ホストが必要な CPU 機能を欠いている	EVC ベースラインを最古世代に揃える
ESXi バージョン非互換	新しい VM HW Version が古い ESXi で動作不可	移行先 ESXi をアップグレードするか、VM HW Version を移行先対応レベルに維持
BIOS で機能が無効	VT-x / AES-NI / NX などが BIOS で無効化	BIOS 設定で必要機能を有効化

VM 構成起因の制約

仮想マシン側の構成が原因で vMotion がブロックされるパターンです。

PCI パススルー / DirectPath I/O

ホストの物理 PCI デバイス（NIC、GPU、USB コントローラなど）を VM に直接マウントしている場合、その VM は vMotion 対象外 となります。GPU 仮想化が必要な場合は NVIDIA vGPU の利用を検討します（vGPU vMotion は vSphere 6.7 以降で条件付き対応）。

SR-IOV（Single Root I/O Virtualization）

SR-IOV により物理 NIC の VF（Virtual Function）を VM に割り当てている場合も、vMotion はブロックされます。

vGPU（NVIDIA Grid / AI Enterprise）

vGPU を有効化した VM は、移行元・移行先の両ホストで 同一の NVIDIA vGPU プロファイルが利用可能 であることが条件です。プロファイル不一致や GPU 容量不足の場合は失敗します。

vTPM（仮想 TPM）

vTPM を有効化している VM の Cross vCenter vMotion では、移行元と移行先の vCenter Server に同一のキープロバイダ（KMS）が登録 されている必要があります。これが不一致だと暗号化キーの引き継ぎに失敗します。

VM 構成バージョン（HW Version）

VM の HW Version（Hardware Compatibility）が、移行先 ESXi のサポート範囲を超えている場合は vMotion できません。例えば HW Version 21 の VM は ESXi 8.0 U2 以降が前提です。

スナップショットの状態

通常の vMotion ではスナップショットが存在しても移行可能ですが、スナップショットチェーンが極端に長い場合や、Storage vMotion を伴う場合は処理時間とディスク I/O 負荷が増大します。可能であればスナップショットを統合（コミット）してから vMotion を実行することをおすすめします。

ネットワーク・ストレージ起因の制約

原因	概要	対処方針
共有ストレージ非対応	移行先ホストがデータストアにアクセスできない	ストレージのマスキング / ゾーニング設定を確認
RDM の LUN ID 不一致	移行元・先で物理 LUN の識別子が異なる	LUN ID を全ホストで揃える
内部 vSwitch（アップリンクなし）	アップリンクを持たない vSwitch に接続された VM	アップリンク付き vSwitch / dvSwitch に再接続
ポートグループ名の不一致	移行先ホストで同一名のポートグループが存在しない	標準スイッチでは同一ラベルを揃えるか、dvSwitch を利用
vMotion 帯域不足	専用帯域が 250 Mbps を下回る、または輻輳	専用 NIC の割り当て、Jumbo Frame、TCP/IP スタック分離

トラブルシュート時の確認ポイント

vMotion が失敗した際の切り分けで参照する代表的なログ・ファイルです。

• vCenter のタスクとイベント: 失敗の最終原因が表示されるため、最初の確認先として有用
• ESXi の /var/log/vmkernel.log: vMotion ネットワーク関連のエラー（Connection timeout、TCP 関連など）
• ESXi の /var/log/hostd.log: vMotion の構成チェックや VM 状態に関するエラー
• vCenter の vpxd.log: 複数ホスト間の互換性チェック結果

互換性チェックでブロックされている場合、vSphere Client の vMotion ウィザード上に具体的な原因メッセージ が表示されます（例: 「The host’s CPU hardware does not support the cluster’s current Enhanced vMotion Compatibility mode」など）。このメッセージを最初に確認することで、原因切り分けの初動を短縮できます。

まとめ

本記事では、VMware vMotion の概要、4 種類の使い分け、実行要件、CPU 互換性、よくある失敗パターンまでを整理しました。

• vMotion は仮想マシンを稼働させたまま別ホストへ移行する技術で、最終段階に 1 秒未満のスタン（短時間停止）が発生する。
• 主要 4 種類は vMotion / Storage vMotion / Cross vCenter vMotion / Long Distance vMotion で、移行対象（コンピュート / ストレージ / vCenter）により使い分ける。
• ネットワーク要件は 同時セッションあたり 250 Mbps（公式必須）、1 GbE で 4 同時、10 GbE 以上で 8 同時が ESXi ホストあたりの上限
• CPU 互換性はベンダ（Intel / AMD）一致が前提で、世代差は EVC または Per-VM EVC で吸収する。」
• VM 側の制約として、CPU アフィニティ、PCI パススルー、vGPU、vTPM、RDM の LUN ID 不一致などが vMotion をブロックする典型要因

以上、最後までお読みいただきありがとうございました。