Azure Localの新しいVMConnect (Preview)を試してみた

本記事について

Azure Localの2601からAzure CLIで利用できるVMConnect機能がプレビュー提供されました。
そもそもなぜ必要なのか何が嬉しいのかを整理して、試してみた結果を紹介します。

先に結果を載せておくと、私の環境では最終的にはVMConnect自体はできたのものの、ドキュメント通りに動作しておらず、無理やり動かせはしたもののエラーも出ている状況でした。

Azure CLIで使うVMConnect機能の概要

Azure LocalにおけるVM作成方法と接続方法

まず、Azure Local上のVMへの接続方法を確認しておきたいのですが、VMの作成方法とも合わせておさらいしておきましょう。

従来のオンプレツールでVMを構築する場合

1つ目のVMの作成方法はWindows Server Hyper-VのVM (Hyper-V VM)と同様にWindows Admin Centerやフェールオーバークラスターマネージャー等、従来からあるオンプレのツールで作成する方法です。
この方法では、VMの作成時にOSイメージをマウントしてOSイメージから起動していきます（vhdのインポートも可能ですがここはISOのイメージからを想定して説明します）。
そのため、当然VMにはIPアドレスも割り当てられておらずRDP/SSHも許可されていないためVMConnectによるコンソール接続が必須です。
VMConnectはWACやフェールオーバークラスターマネージャー、Hyper-V Managerから起動できました。
もちろんOSのインストールをおこなって、VMにIPを割り当ててRDP/SSHを許可してしまえば、mstsc.exeでリモートデスクトップ接続したり、TeraTerm等でSSH接続ができます。

クラウド (Azure)からVMを構築する場合

一方で、もう1つのVM作成方法はAzure Localのクラウド管理の仕組みを使ったAzure経由 (ARM経由)で作成する方法です。
AzureポータルのGUIからはもちろん、ARMテンプレートからのデプロイなどAzureリソースと同様に扱うことができるのが特徴です。
この方法では事前に用意したvhdファイルを元に、指定したVMのIPアドレス設定を反映し、WindowsであればRDPも許可された状態でVMが作成されます。
そのため、VM構築後に即mstsc.exeでリモートデスクトップ接続ができました。

また、どちらの方法で作成したVMであってもAzure Arcでクラウドに接続してしまえばAzure Arcのしくみを使ったSSH接続 (RDP over SSHも可)でAzureの仕組みを使って接続することもできます。
MS Learn | az ssh

Azure CLIで使うVMConnect機能がなぜ必要なのか？

そもそものVMConnect機能がなにかというと、Hyper-Vのホストを介してホスト上で動作するVMに接続する機能です。
オンプレツールで作成したVMのOSインストール作業で説明した初期セットアップに加えて、VMのネットワークトラブル、起動トラブルの際などに利用します。
MS Learn | Hyper-V仮想マシン接続

2601以前もオンプレツールを使ってVMConnectをおこなうことはできたわけですが、Azure CLIで使うVMConnectの価値は以下にあると思います。
それぞれの背景はこの後の動作を確認した後で補足したいと思います。

1. 従来のオンプレツールを利用しないAzure管理のみで運用するAzure LocalにおけるVMConnectツールとして利用できる
2. VMConnectに必要な情報をAzureを介して取得できる
3. デフォルトではVMConnectも許可せず、必要なときにのみVMConnectを許可できる

前提・制限

機能の詳細と手順はこちらのドキュメントにまとめられています。
MS Learn | VM Connect (プレビュー) を使用して Azure ローカル VM に接続する

前提や制限事項で主要なものを抜粋するとこちらのとおりです。
Azureの仕組みを使う接続ではありますが、あくまでVMConnectはHyper-Vホスト (Azure Localのノード)経由でVMに接続しますので、Azure Localのノードに通信できる環境ではないと接続できません。Azure ArcのSSH接続とは異なる仕組みであることには注意しましょう。

• Azure Localのソリューションバージョンは2601以降であること
• 接続元端末ではAzure CLIおよび拡張機能のstack-hci-vm拡張機能を利用すること (現状AzureポータルやAzure PowerShellでの接続は不可)
• 対象のAzure Local VMとAzure Local等に対してAzure Stack HCI管理者以上のロールを持っているユーザーであること (※接続できるのはAzureで作成したVMのみ)
• また、対象のAzure Local VMはAzure Localのリソースと同一のリソースグループにあること (現状の制限)
• 接続元端末からはAzure Localのホストに対して接続できるネットワークに存在すること

VMConnect機能を試してみる

今回はAzureから構築したWindows Server 2025のVMに対してVMConnectを試しました。
冒頭記載の通りドキュメントの手順ではうまく動作できず、2箇所ハマりどころがありました。また、ハマりどころを回避しても挙動に問題はあるためそちらの状況も紹介します。

以下の手順ではAzure CLIの実行ファイルを編集しています。
サポートされるものではありませんので、試される際は自己責任でお願いします。

動作の問題は私の環境依存かもしれませんが、今後の改善の際に確認できるように環境のAzure CLIバージョンを記載しておきます。
なお、2026/1/25と2026/3/14の2つのタイミングで試していますので、それぞれのバージョンを併記します。後述しますが、1/25時点では接続成功に至りませんでした。

• Azure CLI (azure-cli, azure-cli-core): 2.83.0 / 2.84.0
• stack-hci-vm extension: 1.11.9 / 1.12.3

ハマりどころ① リソースロックとの競合

VMConnectを開始する以下のコマンドを実行すると、まず既存のVMConnectの作成(Provision)/削除(Remove)の"Job"を削除してから、新たに今回の接続用に"Provision Job"を作る動きをしています。
この"Provision Job"ですが/subscriptions/<Subsrciption ID>/resourceGroups/<RG name>/providers/Microsoft.AzureStackHCI/clusters/<Cluster name>/jobs/VmConnectProvisionで定義されていまして、Azure Localのクラスターを示すAzureリソース配下のURIに対する削除操作をおこなっているようです。

Azure Localをデプロイすると既定で誤削除を避けるためにAzure Localのクラスターを含む複数のAzureリソースに対してリソースロックが設定され、リソースロック自体を削除しないとリソースの削除ができない状態になっています。
よって、VMConnect開始のコマンドがリソースロックに阻害されて失敗してしまいます。
エラーメッセージにもその旨が明示されていました。

そのため、Azure Localのクラスターのリソースのリソースロックを削除してからVMConnectを使う必要がありました。

ハマりどころ② APIバージョンの指定誤り？

リソースロックの問題を解決すると処理が進むようになるのですが、次のエラーが発生します。
リソースプロバイダーが指定のリージョンとAPIバージョンでは見つからないというエラーメッセージが出てきます。
1/25実施時と3/14実施時で結果が若干異なるので、それぞれ参考に載せておきます。

• 1/25時点のエラーメッセージ
  
• 3/14時点のエラーメッセージ
  

エラーメッセージではサポートされるリージョンとAPIバージョンの問題が示されており、許可されるリージョンとAPIバージョンがリストされていました。
しかし、今回指定しているAzure Local VMもAzure Localもjapaneastリージョンであり、リージョンは問題なさそうでした。
一方でAPIバージョンは実行ログから2023-12-01-previewが使われており、エラーメッセージ記載のサポートされるAPIバージョンに含まれていません。また、1/25と3/14時点でエラーメッセージで提示されているサポートされるAPIバージョンは異なっていますね。

• 1/25時点のサポートAPIバージョンのリスト: 2025-12-01-preview, 2025-10-01, ・・・
• 3/14時点のサポートAPIバージョンのリスト: 2026-03-01-preview, 2026-02-15-preview

さて、ここからがトラブルシューティングになるのですが、az cliコマンドに"--debug"オプションをつけて実行し、問題のスクリプトを確認すると以下のスクリプトがエラー発生箇所になっていました。
Azure CLIのインストール環境によって異なりますが、stack-hci-vm extensionのcustom.pyというファイルでエラーが起きています。
C:¥Users¥<user名>¥.azure¥cliextensions¥stack-hci-vm¥azext_stack_hci_vm¥generated¥custom.py

このスクリプトファイルを確認すると、VMConnectでは以下の関数が呼ばれていて、この関数内でAPIバージョンが明示的に"2023-12-01-preview"と指定されていました。
Azure Resource Manager側なのか、スクリプトの指定なのか、なんらかAPIバージョンの想定に不整合があるように見受けられました。

• stackhcivm_virtualmachine_vmconnect_enable
• stackhcivm_virtualmachine_vmconnect_disable
• wait_for_cluster_job_deletion

そのため、custom.pyを直接編集してAPIバージョンを書き換えて実行してみました。
1/25時点では1つ処理が進むようになりましたが、別のスクリプトの中で、また別のAPIバージョンの不整合が起きたエラーメッセージが表示されまして、この時点ではいったんフィードバックフォームに状況報告して諦めました。
一方で、3/14時点でAPIバージョンを書き換えて実行したところ、処理が実行されてVMConnectに必要なRDPファイルが生成されました。

3/14時点のAPIバージョン書き換え後のVMConnectの挙動

RDPファイルが生成されるようにスクリプトの書き換えができたものの、その際の挙動には問題も見られまして"Provision Job"のステータスが"Failed"としてAzureのアクティビティログに記録されて、Azure CLIはタイムアウトで次の処理に進んだというような状況でした。
もう少し詳細にVMConnect開始時の挙動をログから分かる情報で整理すると以下のようです。

1. 既存のProvision Jobがあれば削除を開始
2. 既存のProvision Jobの削除完了を待つ
3. 新しくProvision Jobの作成を開始
4. Provision Jobの作成成功を待つ
5. 10分待って作成成功していない場合はProvision JobがFailedとしてAzureアクティビティログに記録
6. RDPファイルをローカルに作成して終了

私の環境では何度試しても5番の処理でFailedが発生していたのですが、生成されたRDPファイルは正しく作成されており、それを使って実際にVMConnectも成功しました。
そんな状況のため、具体的に何がFailedなのかはわかりませんでしたが単純にスクリプトのAPIバージョンが誤っていたということでもないように見受けられます。

Azure CLIのエラーメッセージはこんな感じです。

Azure Localのクラスターリソースのアクティビティログに記録されたエラーはこちら。

VMConnectはドキュメントによるとデフォルトでは8時間ホスト側でVMConnectの受信トラフィックを許可するという記載があります。
明示的にAzure CLIでクローズすることもできるようなのですが、クローズのコマンドも類似の挙動を取りまして、Remove Jobが実行されるのですがやはりタイムアウトでFailedとなりました（こちらは100sでタイムアウト）。

明示的なクローズのコマンドを実行したり、VMConnect開始のコマンド実行後8時間放置したりしても、ホストノードのポート2179はオープンのままでした。
クローズコマンドはFailedで正しく実行完了できていないのかもしれず、また、そもそもフェールオーバークラスターマネージャー等でVMConnectを利用していた環境ですので恒久的にファイアウォールが開いてしまっており、そこまでは手を入れてくれないのかもしれませんが、このあたりはProvision JobのFailedと関係しているかもしれません。
ちなみに、ファイアウォールにそれらしいルールが一時的に追加されていないかも確認しましたが見つけられませんでした。

VMConnectによるRDPとRDPファイルの編集 (拡張セッションモードの有効化)

生成されたRDPファイルの中身はこのようになっていました。
通常のRDPではなくVMConnectで接続するためホストのIPアドレスやポート情報、接続対象のVMのVM IDが記されており、こちらを開くことでmstsc.exeがAzure Localホストへの接続をおこない、ホストの管理者情報で認証してVMのログイン画面にたどり着くことができます。

pcb:s:<接続対象で指定したVMのVM ID>;
    EnhancedMode=0
    full address:s:<接続対象で指定したVMが稼働するAzure LocalのホストノードのIPアドレス>
    server port:i:2179
    negotiate security layer:i:0
    keyboardhook:i:1

VMConnectのオプションで拡張セッションモードはオフになっていますが、手動でファイルを更新することで拡張セッションモードをオンにすることができました。
ただ、ファイルを編集する際にpcbの行のオプションとして、以下のように記載してあげないと反映されませんのでご注意ください。

pcb:s:<接続対象で指定したVMのVM ID>;EnhancedMode=1
    full address:s:<接続対象で指定したVMが稼働するAzure LocalのホストノードのIPアドレス>
    server port:i:2179
    negotiate security layer:i:0
    keyboardhook:i:1

わかりづらいですが、拡張セッションモードが有効になり画面最大化できている図。

まとめ

前半で述べたこの機能の価値についてはこのように捉えています。

1. 従来のオンプレツールを利用しないAzure管理のみで運用するAzure LocalにおけるVMConnectツールとして利用できる
   →　Azure LocalのVM管理、クラスター管理はAzureからの管理に移ろいつつあるので、従来のオンプレツールに頼らない代替手段としての利用
2. VMConnectに必要な情報をAzureを介して取得できる
   →　VMの実行ノードやVM IDを自分で用意してRDPファイルを手動で作ることもできるが、それをコマンド1つで動的に情報収集して用意してくれる
3. デフォルトではVMConnectも許可せず、必要なときにのみVMConnectを許可できる
   →　今回はエラーもありそれらしい挙動が確認できなかったが、VMConnectへのJust In Timeアクセスによるセキュリティの強化

まだ問題があるのか、私の環境ではドキュメント通りに動作しなかったものの試行錯誤を記録しておきました。
今後プレビューが外れたらまた確認したいと思います。