みなさん、こんにちは。ネットワールドでSA（ソリューションアーキテクト）として活動している後藤です。
「Azure MigrateでVMware仮想マシンをAzure Local に移行してみた」ということで、Microsoft Azureのサービスである「Azure Migrate」を使用して、VMware環境の仮想マシンをAzure Local環境に移行しよう！ という記事の4回目になります。これまでの記事は以下の通りになります。
blogs.networld.co.jpblogs.networld.co.jp
前回までで移行元環境であるVMware環境と移行先環境であるAzure Local環境に、移行の際に使用する仮想アプライアンスを展開し、移行作業を行うための土台を作ってきました。
今回は、実際に「Azure Migrate」を使用してVMware環境の仮想マシンをAzure Local環境に移行してみたいと思います。
1：最初に注意事項と免責事項
本記事で取り扱っているAzure MigrateベースのVMwareからAzure Localへの移行（Azure Migrate based VMware migration for Azure Local）は、執筆時点（2025/05末）でパブリックプレビューのサービスとなります。
執筆時点の情報になりますので、もしかしたら明日にはサービス仕様が変更されているかもしれません。最新の情報はMicrosoftの公式ドキュメントをご参照ください。
また、本記事に従って作業を行って発生した問題について、弊社は責任を負いかねますので、自己責任でお願いします。
2：移行環境概要
前回も紹介しましたが、移行作業を実施する環境は図1のような環境になります。
3：移行環境構築および移行作業の手順
前回の再掲になりますが、移行環境構築と実際の移行作業は、おおよそ以下のようなステップになります。
1. 事前準備と環境整備（#1参照）
2. Azure Migrateのプロジェクト作成（Azureポータル）（#1参照）
3. 「Azure Migrate source appliance」の導入と設定（#2参照）
4. 「Azure Migrate target appliance」の導入と設定（#3参照）
5. 移行対象仮想マシンのレプリケート設定（←ここから）
6. 仮想マシンの移行作業
4：移行作業
移行作業は、前述の通りレプリケーションと実移行の2つのステップから成ります。
その2つの作業は、基本的にはAzureポータルから行うことになり、確認作業のために各基盤にアクセスする、という形になります。
基本的には、と記述したのは、第2回の「4-3：仮想アプライアンスの設定・仮想マシン上の作業」図33のところで触れたとおり、静的IP設定の仮想マシンを移行する場合には、移行対象仮想マシン上での作業が必要になるためです。DHCPでIPアドレスを取得する場合には、移行対象仮想マシン上の作業は必要ありません。
4-1：Repricate（レプリカ設定）・Azureポータルからの作業
本作業を行うことで、移行作業の前作業としての、移行元仮想マシンの仮想ハードディスクを移行先環境に継続的レプリケーションを行う設定が完了し、実際の初期レプリカ作業が実施されます。
早速作業を始めましょう。
AzureポータルからAzure Migrateのページに遷移し、図2のページから「Repricate」をクリックします。
前回も参照したレプリケーション設定の画面に遷移します。
設定値は前回の表1と同じ設定を行い、「Continue」をクリックします（図3）。
レプリケート設定画面に遷移します。
最初の「基本情報」では、移行先環境の設定を行います。
サブスクリプションやリソースグループには移行先となるAzure Local環境があるサブスクリプションやリソースグループを選択し、「Target system」は移行先のAzure Localクラスターを指定します。
移行先として問題ない指定であれば、緑のチェックマークとともに「Successfully validated system properties.」のメッセージが表示されます（図4）。
問題ないようでしたら「次へ」をクリックします。
ターゲットアプライアンスの指定になりますので、前回の「4-1：Replicate（レプリカ設定）・Azureポータルからの作業」の図5で指定したターゲットアプライアンス名を選択します。
移行先として問題ない指定であれば、緑のチェックマークとともにターゲットアプライアンスに接続されている旨、メッセージが表示されます（図5）。
問題ないようでしたら「次へ」をクリックします。
続いて移行する仮想マシンの設定画面になります。
今回の移行対象は「ESXi-VM01」ですので、当該仮想マシンのチェックボックスにチェックを入れ、「次へ」をクリックします（図6）。
ここで仮想マシンのIPアドレスが「192.168.100.111」に設定されていることを覚えておいてください。
ちなみに、移行対象の仮想マシンの起動していない（電源オンの状態）でない場合、移行対象として選択できません（図7）。起動して（Azureポータルに情報がアップデートされてから）再度移行設定を行います。
また、VMware Toolsがインストールされていない仮想マシンも、同様に移行対象として選択できません（図8）。VMware Toolsをインストールして（Azureポータルに情報がアップデートされてから）再度移行設定を行います。
続いて移行先の詳細設定画面になります（図9）。
キャッシュ用のストレージアカウントと移行する仮想マシンのAzure Arc VMとしてのリソースを作成するリソースグループを指定します。
キャッシュ用のストレージアカウントといっても、実データが置かれることはなく、メタデータのみとなります。
既存のストレージアカウントがない場合は、図9のように新規作成されます。基本的には新規作成でよいでしょう。
移行する仮想マシンのAzure Arcのリソースは、移行先Azure Local環境のリソースグループと同一のリソースグループでなくても問題ありませんが、ここでは同一のリソースグループを指定します。
論理ネットワークとストレージーパスは、移行先のAzure Local環境で作成済みの論理ネットワークとストレージパスを指定します。
指定に問題がなければ「次へ」をクリックします。
コンピューティングの設定では、移行する仮想マシンのVMサイズやOSディスクのパスを指定します（図10）。
今回ディスクが1本しかついていないので選択肢は「scsi0:0」のみですが、複数のディスクが接続されている場合は、OSがインストールされているディスクパスをプルダウンメニューから指定します。
また、「ソースVMサイズ」にはVMware環境上の仮想マシンのサイズが表示されており、既定値として同じvCPU数、メモリサイズがターゲットのVMサイズとして設定されています。
OSディスクのパスは明示的に指定が必要なので、今回はOSディスクのパスのみ指定し、他は既定値で「次へ」をクリックします。
ディスクの設定では、レプリケートの際にディスクの形式やセクターサイズの変換を行うことができます（図11）。
こちらも既定値で「次へ」をクリックします。
今まで設定してきたレプリケート設定の内容が表示されますので、問題がなければ「レプリケート」をクリックします（図12）。
レプリケートジョブが作成され、レプリケーションが実行されます。
図13のようにメッセージが表示されますので、自動的に画面が遷移するまで待機します。
図13が自動的にクローズされ、Azure Migrateのページに戻ってきたら、図14の「Overview」をクリックし、概要ページに遷移します。
「Azure Local Migration」のツリーの「Replications」に、現在設定されているレプリカ設定の一覧が表示されます。図15のように「初期レプリケーション」というステータスになっていれば、初期レプリカが実行中となります。
この画面は閉じても問題ないですし、このままステータスの遷移を確認しても問題ありません。初期レプリカが完了するまで待機します。
レプリケーションジョブが実行され、VMware環境からAzure Local環境への仮想ディスクのレプリケーションが実施されます。
どうやってレプリケーションしているのか？ ですが、「Azure Migrate source appliance」がVMware環境の仮想ディスクを参照し、図11で指定した仮想ディスク形式（今回はVHDX形式）にコンバートしながら、Azure Local環境のクラスターIPの隠し共有である「ClusterStorage$」に対してWindowsファイル共有を使用して仮想ディスクを書き込んでいます（図16）。
移行元のVMDK側の処理はどうしているのか？ というと、図14のように、移行対象の仮想マシンのスナップショットを作成していることがわかります。
このように、移行元仮想マシンが稼働中でも問題ないようにスナップショットを取得し、最終的にはスナップショットを結合する、という処理が行われています。
初期レプリカが完了して移行可能な状態に遷移すると、図18のように移行状態が「移行の準備ができました」との表示に変わります。
この状態で移行を行うことなく放置していた場合、Azure Migrateは定期的にVMware環境からAzure Local環境に仮想ハードディスクのレプリケートを実施します。
レプリカの間隔は1時間強のようで、vCenter側にはスナップショットのログが約1時間ごとに記録されています。Azure Migrateのページの最終同期時刻も、スナップショット取得の時間となっていました。
レプリケーションを定期的に実施することで、差分同期を行っているということですね。
4-2：仮想マシンの移行作業・Azureポータルからの作業
これから実際の移行を行うわけですが、Azure Migrateには「テスト移行」というテスト的に別サブネットに移行を行い、正常に移行ができるかを確認する機能があります。
移行準備が完了している仮想マシンが存在する状態で「Overview」画面の「Test Migration」をクリックすることでテスト移行の設定と実行ができるのですが、この環境では「Test Migration」のページに仮想マシンが表示されません（図20）。
Azure Localへの移行については、現段階ではテスト移行がサポートされていないようです。そのため、このまま移行作業を実施します。
移行作業を行うために、図21のページの「移行」をクリックします。
「移行」のページにて移行する仮想マシンの状態を確認します（図22）。
同期が正常に完了していることを確認し、移行作業を行う際の移行元仮想マシンの状態を選択します。
データ欠損と静止点確保のため、仮想マシンはシャットダウンすることをお勧めします。今回はシャットダウンを選択し、「移行」をクリックします。
移行作業が開始されるので、完了まで待機します（図23）。
この間、実作業としてどのようなことが行われているかというと、まずVMware環境ではスナップショットが取得されます（図24）。
そののちに、ターゲットアプライアンスが直接Azure Localの隠し共有フォルダにアクセスし、仮想ディスクに対して作業を行っていることが確認できます（図25）。
すべての処理が終わって移行が完了すると、図26のように「移行の状態」が完了になります。
この状態で、仮想マシンはAzure Local上で稼働しており、クライアントからもアクセスが可能になっています。「移行作業」という意味においては作業完了となっていますが、後始末が残っていますので、移行完了作業を実施します。
なお、本作業はMicrosoftの公式ドキュメントで「実施しないと予期せぬ動作が発生する可能性」が示唆されていますので、必ず実施してください。
図26の仮想マシン名のリンクをクリックすると、移行を実施した仮想マシンの詳細な情報が表示されます（図27）。
移行作業は完了しているものの、レプリカジョブなど移行作業に必要な設定が残っている状態となるため、最後の処理（後片付け）を行うために「移行の完了」をクリックします。
「移行の完了」として、レプリカジョブの削除のみが行われ、移行済みVMには影響がない旨表示されるので、「はい」をクリックします（図28）。
レプリカジョブが削除され、VMware環境からの仮想マシンのレプリケーションが停止して、移行作業完了となります。
単にレプリカジョブが削除されているだけかと思いきや、裏ではレプリカを取っていた仮想ディスクが削除されているようです。
図29は移行作業完了時点のボリュームのファイル一覧ですが、「ESXi-VM01」という仮想マシン名が含まれた仮想ハードディスクファイルが2つ存在することがわかります。両者の違いは「seed」という文字列が入っているかどうかですね。
図30は後処理を実施した後のものになります。
「seed」の文字列が入った仮想ハードディスクファイルが削除されていることがわかります。
このようにレプリカジョブが削除されるだけではなく、不要なファイル群も削除されるため、当該作業は必須作業として覚えておいてください。
以上で、仮想マシンの移行は完了し、図31のようにHyper-Vマネージャー上でも仮想マシンとして動作していることが確認できます。
図31を見て、お気づきの方がいるかもしれません。
ESXi-VM01は、VMware環境では「192.168.100.111」の静的IPアドレスが採番されていたはずです。本記事の図6を参照ください。
にもかかわらず、移行先のAzure Local上では「169.254.28.95」といわゆるリンクローカルアドレスになっています。ということは、ESXi-VM01はDHCP設定にインターフェース設定が変更されている、ということになります。
Azure Localの論理ネットワークではIPアドレスを配布できるように設定されているのですが、本作業では論理ネットワークを指定して移行をしています。そのため、Azure Arc VMとしてみた場合には、IPアドレスの採番が行われているはずです。
Azure PortalからAzure Arcリソースを参照してみます。
図32はAzure Arc VMとしてのESXi-VM01になります。
Azure Arc VMとしては、論理ネットワークからアドレスが払い出されていて、「192.168.100.151」を割り当てている状況です。
論理ネットワークの設定では192.168.100.151から192.168.100.199までをAzure Arc VMに割り当てるよう設定されており、そもそもプール範囲から外れているので元の静的IPアドレスは採番不可となっていました。
であれば、仮想マシンに192.168.100.151が設定されるの筋かと思いきや、現時点では論理ネットワークの別の静的IPアドレスを仮想マシンに割り当てることは、挙動を見る限りではサポートされていないようです。
ですので、DHCPに設定変更されてしまい、DHCPサーバーからIPアドレスをもらうことができず、リンクローカルアドレスが設定されてしまった、という動きと考えられます。
VMware環境上の仮想マシンの静的IPアドレス設定をAzure Local環境に持ち込めないのか？ という話ですが、本記事冒頭でも触れましたが、「Azure MigrateでVMware仮想マシンをAzure Local に移行してみた：#2 移行元アプライアンス導入編」の図33でちょっと触れた「Prepare VMs for migrating static IPs(Optional)」という作業を、移行作業を行う前に移行対象の仮想マシン上で実施する必要があります。こちらの作業については、次回解説したいと思います。
5：まとめ
今回は、Azure Migrateによる実際の移行作業を紹介しました。
非常に簡単に移行できることがお分かりいただけたと思います。
また、テスト移行ができないなど、GAの際には改善してほしい項目もありますが、概ね移行ツールとしては必要最低限の機能は備えているかと思います。
次回は、静的IP移行などの移行の際のTipsを紹介したいと思います。
書いた人：後藤 諭史（Satoshi GOTO）
ソリューションアーキテクト部所属。
専門はWindows Server Hyper-VやAzure LocalといったMicrosoft仮想化技術。Microsoft SDN（Hyper-V Network Virtualization）などのWindows Server ネットワーク技術も。
Microsoft オンプレ技術以外にも、エンタープライズネットワークとかMicrosoft Azureとか、運用とか。
ネットワークやハードウェアといった物理層に近いところが大好きな、昔ながらのインフラ屋さん。得意技はケーブル整線。
Microsoft MVP for Cloud and Datacenter Management（2012-2026）
Microsoft MVP for Microsoft Azure（2024-2026）
