株式会社ネットワールドのエンジニアがお届けする技術情報ブログです。
各製品のエキスパートたちが旬なトピックをご紹介します。

Azure MigrateでVMware仮想マシンをAzure Local に移行してみた:#2 移行元アプライアンス導入編

みなさん、こんにちは。ネットワールドでSA(ソリューションアーキテクト)として活動している後藤です。

「Azure MigrateでVMware仮想マシンをAzure Local に移行してみた」ということで、Microsoft Azureのサービスである「Azure Migrate」を使用して、VMware環境の仮想マシンをAzure Local環境に移行しよう! という記事の2回目になります。前回は以下の記事になります。

blogs.networld.co.jp

前回はAzureポータル上でAzure Migrateのプロジェクトを作成しました。

今回は移行元環境で使用する仮想アプライアンスを展開します。

1:最初に注意事項と免責事項

本記事で取り扱っているAzure MigrateベースのVMwareからAzure Localへの移行(Azure Migrate based VMware migration for Azure Local)は、執筆時点(2025/05末)でパブリックプレビューのサービスとなります。

執筆時点の情報になりますので、もしかしたら明日にはサービス仕様が変更されているかもしれません。最新の情報はMicrosoftの公式ドキュメントをご参照ください。

また、本記事に従って作業を行って発生した問題について、弊社は責任を負いかねますので、自己責任でお願いします。

2:移行環境概要

前回も紹介しましたが、移行作業を実施する環境は図1のような環境になります。

図1:概要構成図

3:移行環境構築および移行作業の手順

前回の再掲になりますが、移行環境構築と実際の移行作業は、おおよそ以下のようなステップになります。

 

1. 事前準備と環境整備(#1参照)

2. Azure Migrateのプロジェクト作成(Azureポータル)(#1参照)

3. 「Azure Migrate source appliance」の導入と設定(←ここから)

4. 「Azure Migrate target appliance」の導入と設定

5. 移行対象仮想マシンのレプリケート設定

6. 仮想マシンの移行作業

4:「Azure Migrate source appliance」の導入と設定

本作業を行うことで、図1に示す「Azure Migrate source appliance」がESXiホスト上にデプロイされ、Azure Migrateから移行対象の仮想マシンが見えるようになります。

作業としては、Azureポータル上の作業、vCenter Serverでの作業、仮想アプライアンス上の作業と、異なる作業場所での作業が必要になります。どこで作業しているかは、項のタイトルで示していきますので、ご確認ください。

4-1:Discover(検出設定)・Azureポータルからの作業

Azure Migrateの「Server,database and web apps」を選択、プロジェクトのページを表示します。ページを下にスクロールすると「Migration tools」という項目があります(図2)。

図2:Migration Toolsの検出設定

この項目から移行対象の検出(Discover)や次回紹介するレプリカ設定(Replicate)、実際の移行指示となる移行(Migrate)の各処理を実施することになります。

まず、移行元環境を検出できるようにするため、図2に示した「Discover」をクリックしてDiscover設定画面に遷移します。

「Where do you want to migrate to?」では移行先環境を指定しますので、今回は「Azure Local(formerly Azure Stack HCI)」を選択します。もう一つの選択肢はAzure IaaSに移行させる場合に選択します。

「Are you machines virtualized?」では移行元は仮想化環境か? を聞いていますので、今回は「Yes, with VMware vSphere Hypervisor」を選択します。

ちなみに、移行先としてAzure VMを選択した場合、環境選択には「Physical or Other(AWS, GCP, Xen, etc.)」という選択肢が表示されますが、Azure Localへの移行では物理ホストや他クラウドからの移行はサポートされていないため、当該選択肢は非表示になっています。念のため。

上記2つのプルダウンメニューの選択を行うと、VMware環境からAzure Localに移行する際に必要な設定がプルダウンメニューの下に表示されます(図3)。

図3:VMware環境の検知設定画面

まず、「Azure Migrate source appliance」をインストールするために必要なプロジェクトキーを作成します。

「Name your appliance」に「Azure Migrate source appliance」の識別名を入力します。名前は任意ですが3文字から14文字の範囲で指定する必要があります。また、複数のアプライアンスがある場合にはプロジェクト内で同じ名前は付与できません。

入力した名前の右側に緑のチェックが表示されたら命名に問題はないので、「Generate Key」をクリックします。

しばらく待つと図4のように「Project key」が表示されますので、これをコピーしてテキストとして保管します。こちらのプロジェクトキーは、後ほど「Azure Migrate source appliance」の設定で使用します。あとから参照もできますが、ここで保存するのが良いでしょう。

図4:移行元用プロジェクトキーの作成

プロジェクトキーを保存したら、次は「Azure Migrate source appliance」のダウンロードになります。

ダウンロード種別としては、OVA形式のインポート可能仮想マシンファイル(12GB)か、インストール用コンポーネントモジュール(500MB)の2つになります。

OVA形式のファイルは、ご存じの通りvCenter Serverから仮想マシンとしてデプロイすることが可能なので、ダウンロードファイルにはすでにWindows Server 2022(試用版)とAzure Migrate用のコンポーネントがインストールされています。

参考までに、仮想マシンをデプロイ後デスクトップにサインインすると、図5のように試用版であることが表示されています。

図5:OVA形式の仮想マシンをデプロイすると、OSには試用版ライセンスが適用されていることがわかる

従いまして、vCenter ServerからOVA形式の仮想マシンをデプロイするだけで移行元アプライアンスとして使用可能になります。その代わりファイルサイズは12GBと巨大です。

対してインストール用コンポーネントモジュールは500MBと軽量ですが、Windows Server 2022をインストールした仮想マシンが必要です。

今回はOVAファイルをダウンロードして、vCenter Serverで仮想マシンをデプロイします。

図4の画面で「.OVA file. 12GB」を選択して「Download」ボタンをクリックすると、「MicrosoftAzureMigrateStackHCI.ova」というファイルがダウンロードされますので、それをvCenter Serverにアクセス可能な端末にコピーします。

なお、OVAファイルをダウンロードしたらAzureポータル上の作業はいったん終了です。図4の画面で「Close」ボタンをクリックして終了してください。

4-2:仮想アプライアンスのデプロイ・vCenter Serverからの作業

vCenter ServerからOVAファイルをデプロイします(図6)。

図6:OVAファイルを使用して仮想マシンをデプロイ

OVAファイルのデプロイは、通常やられている作業かと思いますので、手順そのものは割愛してポイントだけ解説します。

ネットワークですが、必ずインターネットと移行先であるAzure LocalのクラスターIPに対して到達性のあるネットワークに接続してください。インターネットへの到達性はプロキシ経由でも問題ないです。

また、OVAファイルからデプロイした場合、仮想アプライアンスの設定は図6のようになっています。

図7:OVAファイルからデプロイした仮想アプライアンスの設定

CPUは8vCPUでメモリは16GBが最低要求のはずなので、スペックを調整します。

デプロイが完了した仮想アプライアンスの電源を投入すれば、vCenter Server上の作業は完了です。

4-3:仮想アプライアンスの設定・仮想マシン上の作業

電源を導入した仮想マシンにコンソール接続すると、Windows Serverのセットアップ画面が立ち上がっているはずです(図8)。

図8:仮想アプライアンス起動後の画面

ライセンス条項などをよく読み、ライセンス条項に同意できる場合は同意し、通常のWindows Serverのセットアップ作業を行って、Windows Serverにサインインします。

サインイン後、ブラウザが自動起動していると思いますが、そちらはそのままにしておき、最初の作業であるIPアドレスの設定を行います。DHCP環境の場合は不要ですが、静的IPアドレスが必要な場合には、IPアドレスの設定を実施します(図9)。

図9:仮想アプライアンスのIPアドレス設定

IPアドレスを設定したら、先ほどは無視した自動起動のブラウザ画面に戻ります。

自ホストの44368/TCPに対してアクセスしているのですが、これが仮想アプライアンスの設定用の画面になります。

最初に「Terms of use(利用規約)」が表示されますので、内容に問題がなければ「I agree」をクリックします(図10)。

図10:Terms of use画面

ここから「Azure Migrate source appliance」の設定となります。

万が一ブラウザを閉じてしまった場合は、デスクトップにある「Azure Migrate Appliance Configration Manager」をダブルクリックすることで、設定画面を開くことができます。

実際の設定ですが、最初にAzureへの疎通テストが行われます。プロキシ経由でないとインターネットにアクセスできない環境の場合は、この画面でエラーになるはずです。その場合は「Set up proxy」のトグルボタンをオンにしてプロキシの設定を行ってください。プロキシの設定画面は図11のような感じです。

図11:プロキシ設定画面

直接インターネットに接続できる環境で、疎通や時刻同期に問題ない場合は図12のようにグリーンマークで問題なし、と表示されます。

図12:Azureへの疎通テスト完了

続いてAzure Migrateのプロジェクトキーを登録します。

Azure Migrateのプロジェクトキーは「4-1:Discover(検出設定)・Azureポータルからの作業」の図4の作業で取得しています。テキストで保存していると思いますので、それを「Verification of Azure Migrate project key」に貼り付け、「Verify」ボタンをクリックします(図13)。

図13:Azure Migrateのプロジェクトキーの入力

プロジェクトキーの検証が成功すると、図14のように緑のチェックマークが表示されます。ここで赤のマークが表示されたら、内容を確認し、再度「Verify」ボタンをクリックしてください。

チェック成功に引き続いて、自動的にアプライアンスの自動更新が実施されます。確認とアップデートがあった場合の自動更新が実施されますので、5分から10分ほど(インターネット回線などの環境による)待機します。

図14:プロジェクトキーの検証成功とアプライアンスの自動更新の実行

執筆時点では更新ファイルがあり、アップデートが自動実行されました(図15)。

「Refresh」ボタンをクリックして画面を更新し、再表示された画面でこれまでの手順を繰り返します。

図15:アプライアンスの自動更新結果

自動更新実施後は、図16のように「過去にアップデート実施済み」と表示され緑のチェックマークが表示されます。後続タスクが実施可能となりますので、Azureへアプライアンスからサインインするため「Login」ボタンをクリックします。

図16:自動更新のステータス確認とAzure環境へのサインイン

デバイスコードが表示されますので、「Copy code & Login」ボタンをクリックして、いつものデバイスコードを使用したAzureへのサインインを行います(図17)。

図17:デバイスコードの表示とAzureへのサインイン実行

サインインが完了すると、サインインしているユーザー名が表示され、アプライアンスのAzureへの登録(レジストレーション)が自動実行されます(図18)。

図18:Azureへのサインイン完了と、アプライアンスのAzureへの登録

図18では「最大10分かかる」と表示されていますが、本記事の環境では1分程度で完了しました(図19)。環境によっては10分程度かかる場合もあるかもしれません。

図19:アプライアンスのAzureへの登録完了

次の作業になりますが、画面をスクロールするとすでに赤のマークが表示されています(図20)。

図20:後続タスクですでに赤のマークがつき、エラーが発生している

これは、VMware環境の移行に必要な「VMware Virtual Disk Development Kit」がアプライアンスにインストールされていない場合に表示されるエラーで、こちらはユーザー自身がアプライアンスに配置する必要があります。
こちらはBrodecomのサイトからダウンロードする必要があります。

developer.broadcom.com

デベロッパーポータルにログインするとダウンロードできます。アカウントがない場合はアカウント登録が必要になります。

適切なバージョンをダウンロード後、図20の指示通り「C:\Program Files\VMware\VMware Virtual Disk Deproiment Kit」のフォルダにダウンロードしたファイルを配置します(図21)。

指定フォルダは作成済みなので、解凍したファイルをフォルダごとコピーするだけでOKです。

図21:VMware VDDKのコピー

再度アプライアンスのセットアップ画面に戻り、「Verify」ボタンを押すことでVMware VDDKのチェックが行われ、コピー配置したVMware VDDKに問題がなければ図22のように緑のチェックマークがつきます。

図22:VMware VDDKの検証成功

次は、移行元であるVMware環境や移行先であるAzure Local環境へアクセスするための認証情報(クレデンシャル情報)を追加していきます。

最初にvCenter Serverへのアクセスに使用する認証情報を設定します。

「Step1: Provide vCenter Server credentials for discovery of VMware VMs」の項にある「Add credentials」をクリックします(図23)。

図23:vCenter Serverの認証情報の追加

認証情報を入力する画面(Add credential)に遷移するので、認証の識別名(あとで使います)、必要な権限を持ったユーザー名とパスワードを入力して「Save」をクリックします(図24)。

図24:vCenter Serverへのアクセス用認証情報の入力

元の画面に戻り、図25のように認証情報が保存されていることを確認して、下にスクロールします。

図25:認証情報が保存されていることを確認

「Step2: Provide vCenter Server details」の項では、実際にアクセスするvCenter Serverのアクセス先を設定します。「Add discovery source」をクリックします(図26)。

図26:アクセス先vCenter Serverの追加

「Add discovery source」のウィンドウにて、移行元となるvCenter Serverの接続先アドレス情報とvSphere Clientの接続ポート番号、並びに図24で設定した認証情報の識別名を選択して「Save」をクリックします(図27)。

図27:vCenter Serverの接続先情報を入力

元の画面に戻り、接続情報の検証が行われます。

vCenter Serverに正常に接続できた場合は、図28のように緑のチェックマークとともに「Validation successful」と表示されます。

図28:接続検証が成功した例

赤のマークがついた場合は、接続検証に失敗しているので、アドレスや認証情報を再度確認してください。

続いて「Step3: Provide server cledentials to platform software inventory,」の項では、ワークロードである仮想マシンの認証情報を入力します(図29)。仮想マシンにサインインできるようにすることで、SQL ServerやMySQLといったアプリケーション情報を取得することができます。

図29:仮想マシンの認証情報設定

本記事の作業においては、本設定は未実施としました。

このまま下にスクロールすると、設定した認証情報やvCenter Serverの設定情報を用いて移行元となるVMware環境の検出準備が完了したかが表示されます(図30)。

図30:VMware環境の検出準備結果表示

「Discovery status」や「Migration readiness status」が緑のチェックマークになっていれば問題ありません。

AzureポータルでAzure Migrateのページを参照すると、移行対象の仮想マシンが検出されていると思いますが、ここではアプライアンスの設定を先に進めます。

下にスクロールすると、最後のステップとして、「Onboard to Azure Local」という設定が表示されます。これは移行先であるAzure Localの認証情報を設定する項目になります(図31)。

図31:Azure Local認証情報設定

図31の「Add information」をクリックすると、認証設定画面が表示されますので、権限を持っているユーザーを指定します(図32)。

図32:Azure Localの認証情報を入力

「Username」にはユーザー名のみを入力します。Active Directoryのドメインユーザーだからと言って「ドメイン名¥ユーザー名」で入力するとエラーになりますので注意してください。

「Save」をクリックすることで保存、元の画面に戻ります。

元の画面に戻ると、Azure Localへのアクセスが試行され、資格情報の検証が行われます。問題がなければ緑のチェックマークがつき、検証完了となります(図33)。

図33:Azure Local認証情報の検証結果の表示

以上で「Azure Migrate source appliance」の導入は完了となります。

図33の下のほうに「Prepare VMs for migrating static IPs(Optional)」という一文が見えますが、こちらは仮想マシンが静的IP設定で、同一IPアドレスで移行したい場合の作業についての記述となります。実際にはアプライアンス上の作業ではなく、移行対象の仮想マシン上での作業となりますので、こちらについては移行設定の回で紹介します。

5:「Azure Migrate source appliance」の導入作業中に起こったこと

「4-3:仮想アプライアンスの設定・仮想マシン上の作業」の作業中に発生した事象ですが、アプライアンスの設定作業画面へのアクセスは、既定値では「https://ホスト名:44368」で行われますが、作業中に図34のようにアプライアンス設定画面からインターネットへのアクセスが確認できなくなりました。同じ画面のシステムトレイのネットワークアイコンは、インターネットアクセスが問題なくできていることを示しています。

図35:アプライアンス設定画面からインターネットアクセスが確認できなくなった

本事象は、設定画面へのアクセスを「https://ホスト名:44368」から「https://ホストIPアドレス:44368」へ変更したところ、問題が解消されました。

ただし、「https://ホスト名:44368」の時には現れなかった認証画面が表示されるようになります(図36)が、アプライアンスの管理者アカウントを入力することで通常通りアクセス/設定ができるようになりました。

図36:IPアドレスで設定画面にアクセスした場合の認証画面

同じような事象が発生した場合には、IPアドレスでのアクセスも検討してみてください。

なお、数日後に再度チェックしたら、ホスト名でも問題なくチェックが実施されました。そういう意味では一時的な事象の可能性も捨てきれませんが、そういった事象があったということを残しておきたいと思います。

6:まとめ

今回は、Azure Migrateの移行元となるVMware環境に、移行用アプライアンス「Azure Migrate source appliance」のデプロイと設定を紹介しました。

手順さえわかれば、そこまで苦労することもなく最後まで設定できるのではないかと思います。

次回は、移行先であるAzure Localの環境整備手順を紹介したいと思います。

書いた人:後藤 諭史(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)