Azure Local 2510でデプロイウィザードの基本情報から進めません。

Azure Local 2510の公開が停止されたことと関連するかもしれません。

Azure Local 2510のArc登録自体は可能ですが、Azure Local 2510でデプロイウィザードの基本情報から進めません。サポートしないOSとのメッセージが出ますね。。。

2025/11/08追記　Azure Local 2510の再公開に伴い、この事象は解消しました。

Azure Local 2508をAzure Arc登録する途中で注釈が出ました。

2510が公開停止になってしまったようなので、最新は2509です。その一つ前の2508をArc登録している最中に注釈なのか推奨なのかが出ました。

拡大もしておきます。

Edge 141.0.3537.99 だと、Azure LocalデプロイウィザードのNetworkingから進まなくなるような。

Mac版Edgeで標記の現象に遭遇しました。NetworkingのValidateをクリックした画面です。

Mac版Chromeだと同じ設定でも先に進めます。上下で設定情報は違わない認識なんですけれどもなぜだろう。

Edgeの新しいバージョンで解消するかもしれませんが、こういう事象があったことを残しておきます。

2025/11/08追記　142.0.3595.65でも再現しています。が、同じMac機のChromeでも再現するようになってしまいました。よって、上記記事中にMac版である旨を追記いたしました。現在は、Windows版Edgeで続行しています。

Arc Gatewayを使ったAzure Local 2509のデプロイ完了です。

Azure Arc Gatewayを使ったArc登録にて、Arc Gatewayを使ってAzure Local 2509の登録ができました。

Azure Localのデプロイも無事に成功しました。Nested Azure Localとなりますが、デプロイの経過を貼っておきます。

デプロイ完了後、片方のノードにログオンしたところ、デプロイのPowerShellによるデプロも参考までに載せておきます。（PowerShell内の時刻表記は、UTCです）

Azure Arc Gatewayを使ったArc登録にて、netsh winhttpのProxy設定が入りました。

Proxy配下におけるAzure Arc Gatewayを使ったArc登録が使えますね。その場合。事前のProxy設定は特に必要無いです。

Azure Arc Gatewayを使ったArc登録にて、Proxyおよびバイパスリストの指定が太字部分としてあります。当該環境の場合は、下記を使いました（プロキシサーバーとバイパスリストのみ実際の設定値を表記します）。

$ProxyServer = "http://g2alma.sshzk2016.local:3128"

$ProxyBypassList = "localhost,127.0.0.1,*.sshzk2016.local,g2azl0301,g2azl0302,192.168.*.*,AzLFC03" 

Invoke-AzStackHciArcInitialization -TenantID $Tenant -SubscriptionID $Subscription -ResourceGroup $RG -Region $Region -Cloud "AzureCloud" -Proxy $ProxyServer -ArcGatewayID $ArcgwId -ProxyBypass $ProxyBypassList

これの実行前後で、設定値がどう変わっているのかをみました。

Azure Arc Gatewayを使ったArc登録前です。netsh winhttpのProxy設定は無しです。

Azure Arc Gatewayを使ったArc登録後です。netsh winhttpのProxy設定があります。

なお、PowerShellのHTTP_PROXY、HTTPS_PROXY、NO_PROXYは実行後も設定されていなかったので、画面キャプチャは無しとしました。

Azure MigrateによるVMwareからAzure Localへの移行 その1

Azure MigrateによるVMwareからAzure Localへの移行がGAしました。

今回は、準備として、Azure Migrateプロジェクトを作成するところまでを記載します。

本題の前に、前提条件のリージョン外で、Azure Migrateプロジェクトを作成するとどうなるか試します。

• Azure Migrate を使用した Azure Local への VMware VM 移行の要件を確認する
• Review requirements for VMware VM migration to Azure Local using Azure Migrate

に要件が記載されています。APJで使えるリージョンは、South East Asia, East Asiaだけで、日本は無いです。Azure Migrateプロジェクト自体は、日本のリージョンでも作成できますが、Azure Local向けのAzure Migrateプロジェクトが作成できないわけです。

では実際に、前提条件のリージョン外で、Azure Migrateプロジェクトを作成してみました。

移行先をAzure Localにしてみます。

リージョンの前提条件が満たされない旨、メッセージが表示されます。

というわけで、間違えてプロジェクトを作成してもメッセージが表示されるので、気づけます。

改めて、リージョンの前提条件を満たすようにリソースグループとプロジェクトを作りました。

プロジェクトができましたので、移行先をAzure Localにして次の画面がどうなるかを見ます。

今度は、前提条件を満たすようにプロジェクトを作成したので、移行のステップが表示されました。

この後、移行元、移行先の準備を行います。

Azure MigrateによるVMwareからAzure Localへの移行 その2

に続きます。

Azure Local 2508を2509へアップデートしました。

Azure Local 2508にアップデートが来ました。

アップデートは、Azure Portalベースですね。

ちなみにUpdate Managerからも該当のアップデート画面に辿り着きます。（後ほどアップデート完了後の画面を添付します）

更新を進めていくとまずは準備状況の確認画面が出ます。

準備状況を確認したら、更新プログラムを選択します。下記の例では、2509です。

下記の画面でインストールをクリックすれば、インストールが開始されます。

更新ステータスが処理中に変わりました。が、更新の所要時間で文字化けしている箇所あり。。。

画面表示を英語に切る変えたところ、Secondsだと判明。以降は、英語版で画面を載せます（今後、ローカライズの問題が解消すると良いですね）。

最初の処理は、累積更新のダウンロードです。2509に上げるためのサイズは11GBです。

ダウンロード完了。当方の環境でのここまでは10分弱です。（光回線1Gbsの契約）

2番目のValidate処理も完了しました。ダウンロード完了から、58分ほど経過していました。

累積更新のインストール処理が始まりました。

累積更新のインストール処理では、Validate処理での日時も記録されていました。

結果として、3時間37分ほどでアップデートが完了しました。全処理のステップも画面キャプチャしましたが、勉強会セッションで紹介するかもしれません。

さてアップデートをかけた環境は、Nested Azure Localの2ノードです。親となるHyper-VホストのドライブはNVMeを使っており、I/O性能は下記の通りです。

物理サーバーの場合、もっとノード数が多いこともありますので、完了時間がさらにかかる可能性はありますね。

VMware仮想マシンをHyper-Vに移行できるWAC拡張 1.8.0 その3

VMware仮想マシンをHyper-Vに移行できるWAC拡張 1.8.0  その2

に加えて、いくつかのパターンを試行しました。基本的には、英語版を主として、マルチホームの無し/有りを確認しています。

確認結果を記載する前に、確認した環境を遅まきながらまとめておきます。

Windows Admin Center 2410 2.4.2.1 on Windows Server 2025
VM Conversion (Preview) 1.8.0

From
ESXi-7.0U3n-21930508-standard
VMware vCenter Server 7.0.3.01600
To
Windows Server 2025 Hyper-V

当方の確認結果をざっくりとまとめます。あくまでも当方の環境でであり、うまくいく可能性もあるのではないかと。

• 当方の環境では、IPアドレスの移行はできませんでした。
• 移行直後ですでにIPアドレスの移行ができてない場合、移行直後はIPアドレスの移行ができているものの再起動するとDNSサーバーのみの設定となる場合、という2パターンが確認できました。
• また、マルチホームの場合は、確認した限りでは2番目のVNICのみ存在する感じででした。
• VMware Toolsのアンインストールに成功する場合は、Windows Server 2016から2022まででした。
• Windows Server 2025は、移行自体が43%で失敗しました。VMware ToolsおよびIPアドレスの移行できませんでした。

各パターンの詳細については、下記をご参照ください。

※フィードバックのため最初の画像は英文になっています。悪しからずご了承ください。

VMware仮想マシンをHyper-Vに移行できるWAC拡張 1.8.0 その2

VMware仮想マシンをHyper-Vに移行できるWAC拡張 1.8.0 その1 からの続き。

ESXi 7とvCenter 7上でWindows Server 2016仮想マシンを用意し、VMware Toolsをインストール済みとしていました。VMware仮想マシンをHyper-Vに移行できるWAC拡張 1.8.0 その1 に記載の通り、初期同期が完了しました。

移行の前に、「その他のオプション」見てみました。将来的には、Azure Arcへの登録もできますね。

続いて、仮想マシン移行を見ていきます。1.8.0プレビューでは、VMware Toolsのアンインストール、静的IPアドレスの移行がサポートされます。

全てのオプションを選択しました。いずれのオプションを選択しても、ローカル管理者権限のクレデンシャルが必要です。

事前チェックが開始。

事前チェックが完了。

差分同期の初期フェーズが完了して、。

静的IPアドレスの構成が完了しましたので、VMware Toolsのアンインストールが開始。

Mware Toolsのアンインストールが完了。

移行元仮想マシンの電源OFFされました。

合わせてvCenter側の状態を確認しました。

そうこうしているうちに移行が完了しました。

移行元の仮想マシンは、残っているので切り戻しが可能です。ただしVMware Toolsがアンインストール済みなので注意します。

では、オプションで指定したVMware Toolsのアンインストール、静的IPアドレスの構成がどうなったかを見ます。

仮想マシンコンソールより、OSにサインインしました。シャットダウンイベントの追跡ツールが表示されました。

IPアドレスの構成は移行できていました。

では、プロパティから確認したところ、DNSを残して消えました。

コミュニティメンバーに教えてもらったところ、静的IPアドレスの構成自体は下記のフォルダーにあります。

実際の設定情報は、JSONファイルに書かれています。

さてこの静的IPアドレス構成は、起動時にタスクスケジューラーで一度のみと聞きました。ため元で再起動してみましたが、すでに実行済みであり、静的IPアドレス構成は再反映されません。

この後、別の環境でリトライを繰り返したところ、移行前と移行後のNICに同じIPアドレスが付与されているからかもと考えています。移行前と移行後のNICに同じIPアドレスが付与されている旨のメッセージを別途キャプチャしたく考えています。

時間が前後しますが、VMware Toolsのアンインストールは確認済みです。

VMware仮想マシンをHyper-Vに移行できるWAC拡張 1.8.0 その3 へ続く。