みなさん、こんにちは。ネットワールドでSA（ソリューションアーキテクト）として活動している後藤です。
仮想化基盤（ハイパーバイザー）を移行しよう！ となった場合、まず何を考えるか。それは「今使っている仮想マシンを、新しい仮想化基盤に安全に移行できるのか？」ではないでしょうか。
仮想化基盤を更新すればコスト削減が見込めたとしても、削減額を上回る移行コストの発生が見込まれると、移行のモチベーションは下がってしまいます。結果として「ちょっと高くなっても、バージョンアップはするにしても今のハイパーバイザーを使い続けようかな」になってしまう恐れもあります。
したがって、基盤更改とセットで移行を考える必要がありますが、異なるハイパーバイザー間の仮想マシンの移行は、ハードルが高いことは否定できません。
各社から異なるハイパーバイザー間の仮想マシン移行ソリューションが提供されており、選択肢は増えていると思いますし、いろいろなところで移行ソリューションが語られています。
例えば、弊ネットワールドらぼでも、以下のような記事がありますのでご参照ください。
本記事では、最近注目を集めているMicrosoftのHCIソリューション「Microsoft Azure Local」を移行先と想定し、Microsoftが提供する移行ソリューション「Azure Migrate」を使用した移行手順を紹介したいと思います。
移行元は、昨今の事情も鑑みると、多くの場合がVMware vSphereではないかとおもいますので、VMware vSphereとします。
なお、環境構築から実際の移行作業までを紹介する都合上、記事が複数回に分かれることをご了承ください。初回となる今回は、Azure Migrateによる移行環境概要、事前準備、Azure Migrateの初期設定手順（プロジェクト作成手順）を紹介します。
- 1：最初に注意事項と免責事項
- 2：「Azure Migrate」とは？
- 3：移行環境概要
- 4：移行環境構築および移行作業の手順
- 5：事前準備と環境整備
- 6：Azure Migrateのプロジェクト作成（Azureポータル）
- 7：まとめ
1：最初に注意事項と免責事項
本記事で取り扱っているAzure MigrateベースのVMwareからAzure Localへの移行（Azure Migrate based VMware migration for Azure Local）は、執筆時点（2025/05末）でパブリックプレビューのサービスとなります。
執筆時点の情報になりますので、もしかしたら明日にはサービス仕様が変更されているかもしれません。最新の情報はMicrosoftの公式ドキュメントをご参照ください。
また、本記事に従って作業を行って発生した問題について、弊社は責任を負いかねますので、自己責任でお願いします。
2：「Azure Migrate」とは？
そもそも「Azure Migrate」ってなんだっけ？ というお話ですが、Azure MigrateはMicrosoftが提供する「オンプレミスのワークロードをMicrosoft Azureに移行するためのサービス」になります。
Azure Migrateで提供される「Azure Migrateアプライアンス」と呼ばれる軽量の仮想アプライアンスをオンプレミス環境に導入し、オンプレミスにあるワークロード（主に仮想マシン）を検出、一定期間パフォーマンスデータの収集を行い、Azureに移行する場合の仮想マシンサイズの提案を行い、仮想マシンの仮想ディスクをAzureにレプリケーションして、実行者の指示に基づいてAzure仮想マシンとしてAzureに移行してくれるという、とてもとても便利なサービスになっています。
Azure Migrateは、仮想マシンのIaaS移行をターゲットにしていると思われがちですが、Azure MigrateにはAzure Database Migration ServiceやAzure App Service移行アシスタントといったツールが統合されているので、SQL ServerやWebアプリケーションなどの移行にも威力を発揮します。
このAzure Migrateが機能拡張され、移行先がAzureだけではなくAzure Localも選択できるようになり、元々Azureへの移行がサポートされていたVMware環境からも、Azure Localがサポートされた、という形になります。
Azure Migrateが提供される前までは、Azure Localへの仮想マシン移行はサードパーティ製品やMicrosoftの管理製品であるSystem Centerを使用して移行を行っていましたが、クラウドサービスとしてファーストパーティ製品で移行が行えるというのは、移行コストやサポートの面からみても安心につながると考えます。
本記事で取り扱うAzure MigrateベースのVMwareからAzure Localへの移行に関するMicrosoftの公式ドキュメントは以下のものになります。
3：移行環境概要
移行作業を実施する環境として、図1のような環境を用意しました。
こちらの環境を展開するソフトウェアは以下の通りです。
移行元ハイパーバイザー：VMware vSphere 8.0U2
移行先ハイパーバイザー：Azure Stack HCI OSは最新版のAzure Local 12.2504
ハイパーバイザー以外にも、Active Directoryドメインコントローラー（DNS含む）やvCenter Serverも準備しています。vCenter Serverは必須ですので準備してください。
また、Azure MigrateはAzureのサービスなので、Azureに接続できる必要があります。
Azure Migrate自体はインターネット経由のアクセスとAzure Private Linkを使用したプライベートネットワーク経由のアクセスの両方に対応しています。
今回は検証環境ということでインターネット経由でのアクセスとしますので、インターネット回線を準備しました。
なお、図中の「Azure Migrate source appliance」と「Azure Migrate target appliance」は、記述の通り環境構築中にデプロイする仮想マシンですので、事前準備は不要です。
4：移行環境構築および移行作業の手順
移行環境構築と実際の移行作業は、おおよそ以下のようなステップになります。
1. 事前準備と環境整備
2. Azure Migrateのプロジェクト作成（Azureポータル）
3. 「Azure Migrate source appliance」の導入と設定
4. 「Azure Migrate target appliance」の導入と設定
5. 移行対象仮想マシンのレプリケート設定
6. 仮想マシンの移行作業
5：事前準備と環境整備
最初の実施項目は、移行環境の確認と、必要な通信経路や通信ポートの確保です。
サポート対象のVMware vSphereのバージョン等は以下のドキュメントを参照してください。
日本語訳が機械翻訳すぎてちょっと戸惑います。適宜英語のドキュメントを参照していただいたほうが良いかと思いますが、かなり戸惑うのが「元の機器」と「対象機器」という項目ですね。
英語のドキュメントをみると一目瞭然なのですが、「元の機器」は「Source appliance」、「対象機器」は「Target appliance」となっており、なにかというと図1にもある「Azure Migrate source appliance」と「Azure Migrate target appliance」のOSの事を指しています。
両方とも仮想アプライアンスとして用意されていますが、インポート可能な仮想マシンイメージの他、ソフトウェアのみダウンロードして、ユーザー側で用意した仮想マシンにインストールすることもできるようになっています。
その場合の仮想マシンのOSとして、Windows Server 2022が対応しています、という意味になります。わかりにくいですね。
この「Azure Migrate source appliance」がどのくらいのリソースを要求するかは、次のドキュメントに書いてあります。
「最低 16 GB のメモリ、80 GB のディスク、8 個の vCPU」ですね。
また、同じドキュメントにESXiホストの要求仕様も、別ページへのリンクですが記述されています。必要なvCenterの権限もそちらに記述されていますので確認してみてください。
こちらからもリンクを張っておきます。
続いて通信ポートです。
ドキュメントとしては、以下のドキュメントを参照してください。
ESXiホストとAzure Localのファイヤーウォールポリシーや必要なURLが記述されていますので、そちらの要件を充足しているかを確認してください。
また、このドキュメントには書いていないのですが、「Azure Migrate source appliance」と「Azure Migrate target appliance」が直接Azure Localのクラスター名配下の隠し共有に対してアクセスします。
Azure Local的にはデフォルトで許可されているポリシーではありますが、Azure LocalのクラスターIPに対して（仮想ディスクのコピー処理などで）SMB接続が発生することを頭の片隅に置いておいてください。
また、「Azure Migrate source appliance」と「Azure Migrate target appliance」がAzure Migrateサービスにアクセスします。これはインターネット経由になりますので、ファイアウォールで前述のドキュメントに記載のあるURLに対する、両アプライアンスからのアクセスを許可してください。なお、プロキシ経由でもOKですが、アプライアンス導入時に設定が必要になります。
これからの環境チェックや事前設定が完了したら、いよいよAzure Migrateの設定になります。
6：Azure Migrateのプロジェクト作成（Azureポータル）
Azureポータルから、「Azure Migrate」と検索する等でAzure Migrateのページを開きます。
ポータルの言語設定は日本語なのですが、図2のような英語のページが表示されます。ローカライズの問題でしょうか。
そこまで難しい英語ではないので問題にはならないかと思います。
図2のGet Startedページにて「Discover,assess and migrate」ボタンをクリックします。
そうすると「Server,database and web apps」のページに遷移します（図3）。
Azure Migrateの移行プロジェクトがある場合には、このページにそのプロジェクトが表示され、評価や移行作業設定、実際の移行作業ができるようになります。
この時点ではプロジェクトが存在しないので、何も表示されていません。
「Create proj…」（「Create project」とすべて表示されていない）をクリックして移行プロジェクトを作成します。
ここからプロジェクト作成画面です（図4）。
プロジェクトを作成するサブスクリプションとリソースグループを指定します。
今回はリソースグループは新規作成し「AzureMigrateRGs」としています。
プロジェクトの詳細で設定するプロジェクト名を「VMware-to-AzureLocal」としました。
次の「Geography」ですが、Azure Migrateの関連リソースを作成するリージョン指定と思いきや、プルダウンメニューを開くと「Asia Pacific」などリージョンでは見かけない名前が並びます。「Japan」もあるものの、見慣れた「Japan East」などはありません。
なるほど、ここはAzureのリージョン一覧でよく見かける「Geography」を選択するんですね。
実際のリソースは、ここで選択したGeographyに属するリージョンにデプロイされる、ということですね。
では「Japan」を選択すればいいのかというと、VMwareからAzure LocalへのAzure Migrateの場合、利用可能なGeographyが限定されています。
これも前項で紹介した、機械翻訳っぽい日本語な感じのページに書いてあります。
このページも英語版のほうを参照していただいたほうが直感的にわかると思いますが、「サポートされている地域（Supported geographies）」という項に表があります。
この表の「地理（Geography）」がプロジェクトの「Geography」で設定する値、その値に設定されているリージョンが「メタデータ ストレージの場所（Metadata storage locations）」になります。
利用可能なGeographyとして挙げられているのが「アジア太平洋 （Asia-Pacific）」「ヨーロッパ（Europe）」「米国（United States）」なので、今回は「Asia Pacific」を選択します。
「Asia Pacific」を選択した場合は、Azureのリージョン一覧にもある通り「東南アジア（South East Asia）」リージョンもしくは「東アジア（East Asia）」にデプロイされます。
先のリージョン一覧を確認すると、東南アジアリージョンはシンガポール、東アジアリージョンは香港特別行政区にあることがわかります。
このリージョンに置かれるリソースやデータは、あくまでもAzure Migrateのメタデータやプロジェクトリソース、Azure Migrate用のキーコンテナーとなっており、実際のデータは置かれません。
とはいえ、GAまでには日本地域も対応してほしいですね。
設定として残っている「Advanced」ではAzure Migrateへのネットワーク接続設定を実施します（図5）。
今回はインターネット経由でAzure Migrateを利用するため、既定値の「Public endpoint」のままにします。Azure Private Linkを使用したプライベートネットワーク経由の場合は「Private endpoint」を選択してください。
以上でプロジェクトの設定が完了するので、「Create」をクリックします。
プロジェクトの作成が完了すると、「Server,database and web apps」のページが更新され、プロジェクトが表示されます（図6）。実際の設定作業はすべてこのページから実施することになります。
なお、今回のAzure Migrateのリソースは東南アジアリージョンに展開されていました。
どちらのリージョンが使われるかは、その時のリソースの空き状況次第ではないかと感じられますが、確定的な情報はありませんでした。
7：まとめ
今回は、Azure Migrateの概要と構成、および事前準備を紹介し、最初のステップとなるAzure Migrateのプロジェクトの作成手順を紹介しました。
そんなに難しい手順ではなかったかと思います。
次回は、プロジェクトページから移行元環境としてVMware基盤を認識させる手順と移行先であるAzure Local環境をAzure Migrateに認識される手順を紹介したいと思います。
書いた人：後藤 諭史（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）
