VMware vMotion（ホットマイグレーション）とは？vSphere環境での仕組み・要件・HA/FTとの違いを徹底解説

2026年6月17日 2026年6月14日

frenchfly

VMware vSphere（ESXi）環境を運用するインフラエンジニアにとって、物理ハードウェアのメンテナンスやリソースの負荷分散は避けて通れない重要なミッションです。「物理サーバーのファームウェアを更新したいが、その上で動いている重要な業務システム（仮想マシン）は絶対に停止させられない」

「一部のホストに負荷が集中しているため、業務時間中に安全に分散させたい」

このような現場のインフラ管理者が抱えるジレンマを劇的に解決する中核技術が、VMwareの「vMotion（ホットマイグレーション）」です。
しかし、vMotionはボタン一つで魔法のように移動できるわけではありません。ネットワーク・共有ストレージ・CPUの厳格な要件を満たさなければ、移行の失敗や予期せぬシステムのネットワーク切断を引き起こすリスクが伴います。

この記事では、vMotionの基本的な仕組みから、コールドマイグレーションやStorage vMotionとの違い、絶対に失敗しないための必須要件を解説します。さらに、混同されやすい「vSphere HA」や「vSphere FT」との明確な違い、そしてE-E-A-T（専門性・信頼性）に基づくプロレベルのトラブルシューティングまで、実務で直面する疑問を網羅的に紐解きます。

1. vMotion（ホットマイグレーション）の基礎知識と最大のメリット

仮想マシンを無停止（ゼロダウンタイム）で移行する画期的技術

vMotion（ブイモーション）とは、VMwareが提供する「ライブマイグレーション（ホットマイグレーション）」機能の固有名称です。

最大のメリットは、稼働中の仮想マシンのOSやアプリケーションを一切停止させることなく（ゼロダウンタイムで）、ある物理サーバー（ESXiホスト）から別の物理サーバーへ移動させることができる点にあります。

※補足：ESXiホストとは、VMware vSphere環境において仮想マシンを直接動かすための物理サーバー（ハイパーバイザ）のことです。

エンドユーザーから見れば、アクセスしているサーバーが物理的に別のハードウェアへ移動したことにすら気づきません。この機能により、インフラ管理者は「深夜や休日の計画停止（ダウンタイム）」を待つことなく、平日の日中であっても物理サーバーのメンテナンスを安全に実行できるようになります。

【比較表】コールドマイグレーションとの明確な違い

仮想マシンの移行方法には、マシンの電源状態によって以下の2つの呼称と手法が存在します。

移行方式	状態	特徴とメリット・デメリット	ダウンタイム
ホットマイグレーション（vMotion）	パワーオン（起動中）	システムを稼働させたまま移行する。後述するCPUやネットワークの要件が非常に厳しい。	ほぼゼロ（Ping欠落 0〜1回程度）
コールドマイグレーション	パワーオフ（停止中）	仮想マシンを完全にシャットダウンしてから移行する。CPU世代などの互換性要件が緩く、確実に移行できる。	発生する（停止〜再起動までの時間）

「どうしてもvMotionの要件を満たせない環境」や「異なるCPUベンダー（IntelからAMDなど）への移行」の場合は、業務時間外にコールドマイグレーションを実施するのが基本となります。

Storage vMotion（ストレージの移行）との違い

vMotionと並んで頻繁に使用される用語に「Storage vMotion」があります。この2つは「何を移行するのか」というターゲットが異なります。

vMotion（コンピューティングの移行）： 仮想マシンを動かしている「CPUとメモリ」の処理状態を、別のESXiホストへ移動します。データの保存場所（データストア）は変わりません。
Storage vMotion（ストレージの移行）： 仮想マシンの「データ実体（VMDKファイル）」を、別のデータストア（ストレージ）へ稼働したまま移動します。

※補足：VMDKファイルとは、仮想マシンにおけるハードディスクの役割を果たす仮想ディスクファイルのことです。

※実務の現場では、サーバーの老朽化によるリプレース時などに、これら2つを同時に実行する「Cross-vCenter vMotion（Shared-Nothing vMotion）」という高度な全移行手法も活用されています。

2. 【重要】「vSphere HA」「vSphere FT」とvMotionの違い

VMware vSphereには「システムを止めない」ための機能が複数用意されています。インフラ担当者として、それぞれの機能の「目的」を正しく理解し、使い分けることが不可欠です。

vMotionは「計画的」なメンテナンス向け

ここまで解説した通り、vMotionは「管理者が意図して実行する（またはDRSによって負荷分散のために自動実行される）」ための技術です。物理サーバーが突然クラッシュ（故障）した場合には、vMotionは間に合いません。

vSphere HA（High Availability）は「予期せぬ障害」からの自動復旧

vSphere HAは、物理ホストに予期せぬハードウェア障害が発生した際、そのホスト上で動いていた仮想マシンを、生き残っている別のホスト上で「自動的に再起動」させる機能です。

目的： 突然の障害に対する可用性の担保。
ダウンタイム： 数分程度発生します（OSがクラッシュして再起動するのと同じ状態になるため）。

vSphere FT（Fault Tolerance）は「完全無停止」の冗長化

vSphere FTは、非常にクリティカルなシステム向けの機能です。本番の仮想マシンと全く同じ動きをする「シャドウ仮想マシン」を別のホスト上に常に同期・稼働させておきます。

目的： ハードウェア障害時でも「ダウンタイムゼロ」で業務を継続させること。
ダウンタイム： 完全ゼロ（障害発生の瞬間、シームレスにシャドウ側へ処理が切り替わります）。
ただし、リソースの消費が激しく、構成できるvCPU数に制限があるため、全システムに適用するものではありません。

【結論】 計画的な移動はvMotion、予期せぬ障害への備えはvSphere HA（超重要システムはvSphere FT）と覚えておきましょう。

3. なぜOSが落ちない？vMotionの裏側の仕組み（プレコピー技術）

「数十GBもあるメモリ上のデータを別のサーバーに移動しているのに、なぜOSは落ちず、通信も切れないのか？」

この魔法のような無停止移行は、「プレコピー（Pre-copy）」というVMwareの高度なメモリ転送メカニズムによって実現されています。

初期コピーの開始： 移行元のESXiホストが、対象となる仮想マシンの現在のメモリ状態（例：16GB分）を、移行先のESXiホストへバックグラウンドでコピーし始めます。この間も仮想マシンは通常通り稼働しています。
差分（Dirty Page）の反復転送： 初期コピーを行っている間にも、稼働中のOSのメモリは次々と書き換えられます。vMotionはこの書き換えられた差分データ（Dirty Page）をリアルタイムに追跡し、再度移行先へ転送します。これを差分がごく僅かになるまで超高速で反復します。
瞬時のスイッチオーバー（静止と切り替え）： 差分が極小になった瞬間に、移行元の仮想マシンを「一瞬だけ静止（Quiesce）」させ、最後の差分メモリとCPUのレジスタ（処理の現在地）を転送します。
ネットワークの再開： 移行先のホストで仮想マシンが即座に処理を再開します。同時に、ネットワークスイッチに対してRARPパケットを送信し、「私がここに移動しました」とMACアドレスの学習を更新させます。

※補足：RARPパケットとは、ネットワーク機器（スイッチ等）に対して、MACアドレスと接続ポートの紐付けを強制的に更新させるための通信信号です。

この「静止時間」は通常数ミリ秒〜数十ミリ秒の世界であるため、TCPコネクション（通信セッション）がタイムアウトして切断されることはなく、無停止での移行が成立するのです。

4. 失敗しないために！vMotionの「3大必須要件」

vMotionを実行するためには、VMwareが定めるインフラの前提要件を確実にクリアしている必要があります。ここでは、設定漏れでエラーになりやすい3つの要件を解説します。

【要件1】ネットワーク要件（専用VMkernelポートと10Gbps帯域）

メモリデータを物理サーバー間で転送するため、堅牢かつ広帯域なネットワーク設計が必須です。

vMotion用 VMkernelポートの作成： 管理用のネットワーク（Management Network）とは別に、各ESXiホストにvMotionのトラフィック専用となる「VMkernelネットワークアダプタ（vmk）」を作成し、プロパティで「vMotion」サービスにチェックを入れる必要があります。
ネットワーク帯域： 公式の最低要件は1Gbpsですが、実運用において数十GBのメモリを持つVMを移行する場合、10Gbps以上の専用ネットワークを構成することが強く推奨されます。帯域が細いと、後述するタイムアウトエラーの原因になります。

【要件2】ストレージ要件（共有ストレージの必要性）

標準的なvMotionを行う場合、移行元と移行先の両方のESXiホストが、同じ「共有ストレージ（FC SAN, iSCSI, NFSなど）」にアクセスできる状態でなければなりません。

データの実体（VMDK）が共有ストレージ上にあれば、ネットワーク越しに巨大なディスクデータを移動させる必要がなく、ホスト間で「メモリとCPUの処理の主導権」を渡すだけで済むからです。

【要件3】CPU要件と「EVC」による世代間互換性の確保

移行元と移行先で、CPUのベンダー（Intel と AMD）が異なる場合、アーキテクチャの根本的な違いによりvMotionは実行できません。

また、同じIntel製であっても「世代（例：Broadwell と Ice Lake）」が異なると、提供されるCPUの拡張命令セットが異なるため、vMotionウィザードで互換性エラーとして弾かれます。

これをスマートに解決するのが「EVC（Enhanced vMotion Compatibility）」機能です。

クラスタ単位でEVCを有効にし、古いCPU世代のベースライン（基準）に合わせることで、新しいCPU特有の命令を意図的にマスク（隠蔽）します。これにより、世代の異なる物理サーバー間でも安全にvMotionを行えるようになります。ハードウェアの段階的リプレース時には絶対に欠かせない設定です。

5. 【実践手順】vSphere ClientからvMotionを実行する方法

要件を満たした環境での実行手順は、vSphere ClientのGUIから直感的かつシンプルに行えます。

vSphere Clientにログインし、インベントリから対象の仮想マシンを右クリックします。
メニューから「移行」を選択し、移行ウィザードを起動します。
移行タイプの選択で「コンピューティングリソースのみを変更します（vMotion）」を選択し、次へ進みます。
移行先の「ESXiホスト」または「クラスタ」を選択します。（※ここでシステムによる互換性チェックが自動的に走り、CPUやネットワークに問題があれば警告が表示されます）。
移行先の「ネットワーク（ポートグループ）」を選択します（通常は移行前と同じ業務ネットワークを選択します）。
vMotionの優先順位（通常は「優先度の高いvMotionをスケジュール（推奨）」）を選択し、「終了」をクリックします。

画面下の「最近のタスク」ペインで進捗バーが進み、環境により数秒〜数十秒で100%になり完了すれば大成功です。

6. プロが教えるトラブルシューティング：vMotionが失敗・停止する場合

実運用の現場でインフラエンジニアが直面しやすい「vMotionの失敗パターン」と、その具体的な解決策を解説します。

10%〜20%付近で失敗する原因：ネットワークの疎通エラー

【症状】 vMotionを開始した直後、10%台でタスクが失敗し、「ホストに接続できません」といったエラーが出る。

【主な原因】 ホスト間のvMotion用ネットワークの疎通が取れていません。

【対策のアクション】

ESXiホストにSSHでログインし、vmkping コマンドを使用して、移行先のvMotion用IPアドレスと正しく通信できるか確認してください。
特に、MTUサイズ（ジャンボフレームの設定）がホストと物理スイッチ間で一致していないことが原因でパケットが破棄されているケースが多発します。

70%〜99%でスタック（停止）する原因：メモリの変更量が多すぎる

【症状】 進捗が70%や99%でピタリと止まり、数分後にタイムアウトで失敗（元のホストで稼働を継続）する。

【主な原因】 仮想マシンのメモリの書き換え（Dirty Pageの発生）スピードが、vMotionのネットワーク転送速度を上回っている状態です。いつまで経っても最終的な「静止」フェーズに入れず、諦めてロールバックされます。

【対策のアクション】

高負荷なデータベースサーバーなど、メモリ更新が極端に激しいVMで発生します。業務のピークタイムを避けて夜間に実行するか、vMotion用ネットワークの物理帯域（10Gbps/25Gbpsなど）を拡張設計する必要があります。

7. まとめ：vMotionとvSphereの機能を活用して強靭なインフラを

VMwareのvMotion（ホットマイグレーション）は、現代の仮想化インフラにおいて「ダウンタイムゼロの計画メンテナンス」を実現するための不可欠な中核技術です。

仕組みとしては非常に高度ですが、以下の重要ポイントを押さえて設計・運用することで、安全にその恩恵を受けることができます。

「vSphere HA（障害対応）」や「vSphere FT（完全無停止）」との目的の違いを正しく理解し、適材適所で使い分ける。
安定移行のために、10Gbps以上の広帯域な専用VMkernelネットワークを準備する。
異なるCPU世代が混在するクラスタ環境では、必ず「EVC」を有効化する。

これらの要件とトラブルシューティングの知識を武器にして、障害に強く、かつメンテナンスが容易な柔軟なVMware環境の運用を実現してください。

8. 関連するよくある質問（Q&A）

以下に、vMotionの実務運用において現場からよく寄せられる疑問とその回答を5つまとめました。

Q1. vMotionの実行中に、ユーザー側でPingの欠落やネットワークの瞬断は発生しますか？

A1. はい、ごく僅かに発生する可能性があります。vMotionの最終フェーズで仮想マシンが一瞬静止して切り替わる瞬間、およびネットワークスイッチのMACアドレステーブルが更新されるタイミングで、通常0回〜1回程度のPingロス（数ミリ秒の遅延）が発生することがあります。ただし、一般的なTCP通信のタイムアウト値よりはるかに短いため、業務アプリケーションやWebセッションが切断されることは通常ありません。

Q2. 異なるCPUベンダー（IntelのサーバーからAMDのサーバーへ）間でvMotionを実行することは可能ですか？

A2. いいえ、不可能です。IntelプロセッサとAMDプロセッサでは根本的なハードウェアアーキテクチャと命令セットが異なるため、EVC（Enhanced vMotion Compatibility）機能を使用してもベンダー間のvMotionはサポートされていません。異なるベンダー間で移行する場合は、仮想マシンを一度シャットダウンし、コールドマイグレーションを行う必要があります。

Q3. vCenter Server自体がダウンしている状態でも、vMotionは機能しますか？

A3. いいえ、機能しません。vMotionの移行プロセス（ホスト間のリソース調整、要件の互換性チェック、タスクの実行管理）はすべてvCenter Serverが司令塔として司っています。したがって、vCenter Serverが停止している間は手動でvMotionを開始することはできず、vSphere HAやDRS（自動負荷分散）による自動移行も動作しなくなります。

Q4. vMotionの実行には、実際にどのくらいの時間がかかりますか？

A4. 仮想マシンに割り当てられているメモリ容量（アクティブに使用されているメモリ量）と、vMotion専用ネットワークの帯域幅に完全に依存します。例えば、メモリ数GBのVMを10Gbpsのネットワークで移行する場合、数秒〜十数秒で完了します。一方、数十GBのメモリを持つDBサーバーを1Gbpsの細いネットワークで移行すると、数分以上かかる場合があります。

Q5. 共有ストレージがない環境（各サーバーにローカルディスクしかない環境）でも、ホットマイグレーションは可能ですか？

A5. はい、vSphere 5.1以降のバージョンであれば「Shared-Nothing vMotion」という機能を利用することで可能です。これは、コンピューティングリソース（vMotion）とストレージリソース（Storage vMotion）を同時に移行する技術です。ただし、ディスクデータ（VMDK）の全量をネットワーク経由でコピーするため、通常のvMotionと比較して非常に長い時間がかかり、ネットワーク帯域を大きく消費する点に注意が必要です。