ラベル Hyper-V の投稿を表示しています。 すべての投稿を表示
ラベル Hyper-V の投稿を表示しています。 すべての投稿を表示

2025年11月22日土曜日

Azure Local 2511によるRack aware cluster

Azure Local 2510からプレビューになっているRack aware clusterです。

2510からのプレビューと気かず、Ignite 2025のまとめ記事「Ignite 2025 のタイミングでアナウンスされた Windows Server / Hybrid Cloud に関連するアップデート」から Announcing the preview of Azure Local rack aware cluster を拝見しました。

Requirements and supported configurations for rack aware clusters (Preview) に記載の要件をチェックしないで、4ノードクラスターで構成しました。最小クラスターノード数は、各ゾーンに1台ずつの合計2台です。

手元の2ノードクラスターAzure Local 2510は、(Rack aware clusterではない)通常のクラスターです。今回のRack aware clusterは4ノードと構成です。よって設定も構成も、不一致です。この条件下で、当方のNested Azure Local環境における参考所要時間を記載します。なお参考所要時間比は、1.34ぐらいです。

  • 通常の2ノードクラスターは、3時間53分
  • Rack awareな4ノードクラスターは、4時間59分

ということで、デプロイメントの結果を貼ります。

クラスターの概要では、クラスタータイプがRack aware clusterです。
各ゾーンに2台ずつノードがあることもわかります。


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

Prerequisites for VMware migration to Azure Local using Azure Migrate

に記載がある前提条件を確認します。

  1. Open required VMware firewall ports.
    →制約は入れていませんが別途確認します。
  2. Open required Hyper-V firewall ports.
    →制約は入れていません別途確認します。
  3. Allow required URLs
    →Outboundの制約は入れていません。
  4. Configure SAN/disks policy on VMs.
    →制約は入れていません。
  5. Install Hyper-V Linux Integration Services on Linux VMs
    →今回はWindows VMで確認する想定です。
  6. Disable BitLocker on Windows VMs.
    →未使用とする想定です。実際、移行元のVMでは未使用です。
  7. Encrypted disks/volumes are not supported.
    →未使用です。
  8. Shared disks are not supported.
    →未使用です。
  9. Deploy, configure, and register an Azure Local instance.
    →別記事の通り、デプロイ済みです。
  10. Verify a successful deployment.
    →別記事の通り、デプロイ済みです。
  11. Verify and make a note of the custom location created during deployment on the Azure Local system.
    →デプロイ時にカスタムロケーションを指定済みです。
  12. Create a custom storage path for the Azure Arc resource bridge for storing VM configuration and OS disks.
    →この後、設定を掲載します。
  13. Create a logical network for the Azure Arc resource bridge for VMs to use.
    →この後、設定を掲載します。
  14. Enable contributor and user administrator access on the subscription for the Azure Migrate project.
    →この後、設定を掲載します。
  15. Create an Azure Migrate project
    →別記事「Azure MigrateによるVMwareからAzure Localへの移行 その1」の通り作成済みです。
該当しない場合があるかもしれませんが、前提条件は上記の通りです。個々の前提条件に関して、コメントを入れました。

Create a custom storage path for the Azure Arc resource bridge for storing VM configuration and OS disks.

デプロイ済みのストレージパス以外に作成が必要でした。具体的な作成方法は、
に手順があります。ストレージパスの画面は、下記のとおりです。
C:\ClusterStorage\UserStorage_1 配下に作ることとし、パスをコピーしておきます。
ストレージパスを下記のように入力しました。名前はストレージパスの最下なフォルダー名が自動的に入ります。
本環境の場合は、30秒ほどで作成完了。
概要を確認しておきます。

Create a logical network for the Azure Arc resource bridge for VMs to use.

論理ネットワークを作成しました。具体的な作成方法は、
に手順があります。

最初の画面では、仮想スイッチと論理ネットワークの関連付けを行いました。その中には、リージョンとカスタムロケーションの指定もあります。
次の画面は、論理ネットワークで指定可能なNW情報を指定してします。
必要であればタグを指定します。
論理ネットワーク作成のサマリーを確認したら、作成します。
作成完了したので、情報を確認します。
Azure Local側から見るとこのようになっていました。

Enable contributor and user administrator access on the subscription for the Azure Migrate project.

具体的な作成方法は、
に手順があります。
Contributorとuser access administratorロールを割り当てました。(リソースグループでも良いはずですが、サブスクリプションに割り当てています)

※以降の記事では、移行先対象とするクラスターを変える場合がありますので、ご承知おきください。


Azure Local 2509からのアップデートが進まない感じ その2

Azure Local 2509からのアップデートが進まない感じ

からの続き。

※本環境は、24/365で稼働していませんのでご承知おきください。

6時間経ってもダウンロードのところから進まなかったので、放置していました。その間、Azure Localクラスターノードは、時々起動したり、停止していました。

さてどうなったかと、本日、画面を見たところ失敗していました。

結果的に失敗でタイムアウトすることがわかりました。ここまでは想定内だったのですが、先日設定したはずの論理ネットワークとストレージパスが見えなくなりました。
アップデートをリトライすべきとも思いますが、これはどうしましょうかね。。。
こちらは検証環境なので、セーフではあるものの。
と思ったら、リソースブリッジVMが落ちてました。。。
リソースブリッジVMを起動しました。
しばらくすると、論理ネットワークとストレージパスが見えました。
リソースブリッジVMの重要さを再確認できました。
アップデートをリトライするかは、考えます。




2025年11月16日日曜日

Azure Local 2509からのアップデートが進まない感じ

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

ワンタイムのアップデートを実行します。
アップデートが始まりました。が、6時間超でもダウンロードが終わらない。。。
Azure Arc GatewayがGAしました。 、Arc Gatewayを使ったAzure Local 2509のデプロイ完了です。でデプロイした環境なので、Proxyのログを見ているのですが、疎通している感じなんですね。Proxyを再起動しましたが、その後はaccess.logにアクセスが残っている。まだアップデート実行中なので、このまま放置してエラーになるのか様子を見ます。その後、別日にリトライですかね。。。

Azure Local 2510がデプロイできましたが

 Azure Local 2510がデプロイできました。

しかしながら3箇所ほど引っかかる感じでした。デプロイ成功まで3回費やした結果より、当方のNested Azure Local環境で起きたことを書いておきます。

一つ目はResolve requirementが終わらない。これについては、知人もつぶやいていらしたのですが、サインインするまで該当の処理が止まったような感じでした。サインイン直後の画面と、所要時間の画面キャプチャを載せておきます。

2回目以降のデプロイでは、当方はクラスターノード1にサインインしておくと回避できました。

二つ目は、Deploy Arc infrastructure componentsが終わらない。

これも初回のデプロイで発生しました。サインインしても事象が改善する感じでもなく。2回目以降では遭遇せず。

三つ目は、Finalize securityが終わらない。これは2回目のデプロイで発生しました。画像を見ていただくと2時間以上終わらないことを確認いただけます。

デプロイユーザーでサインインしてみなしたがも事象が改善する感じでもなく。3回目では遭遇せず。

デプロイの再試行に関しては、Nested Azure LocalということでDNS、Azureリソース、ADオブジェクト、Nested Azure Localの仮想マシン自体を削除しています。物理サーバーでは、リトライするしか無いのかなとも。。。

2025年10月31日金曜日

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

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

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

本題の前に、前提条件のリージョン外で、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

に続きます。

2025年10月19日日曜日

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アドレスの移行できませんでした。
各パターンの詳細については、下記をご参照ください。
※フィードバックのため最初の画像は英文になっています。悪しからずご了承ください。




2025年10月8日水曜日

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 へ続く。