さっしーの試してみるか3

2026年9月14日月曜日

Windows Server ＆ Cloud User Group Japan 第52回勉強会セッション動画「WAC 2606の変更点、WAC vMode PreviewのPowerShell概要」

2026年9月6日日曜日

Windows Admin Center VM Conversion PreviewとAzure Migrateに影響しそう

Windows Server ＆ Cloud User Group Japan 第52回勉強会セッション資料「WAC 2606の変更点、WAC vMode PreviewのPowerShell概要」にも書いたのですが、VDDKがダウンロードできなくなっています。

下記の情報が出ています。

Migrate virtual machines using the VM Conversion Extension in Windows Admin Center (Preview)

では、VDDK 8.0.3が必要です。また、Azure Migrateのソースアプライアンスでも8.0.0〜8.0.2が必要です。

Discover and replicate VMware VMs for migration to Azure Local using Azure Migrate
Configure the source appliance and discover VMs

Azure Migrateの場合は、エージェントレス移行からエージェント移行に切り替えれば良さそうです。

Windows Admin Center VM Conversion Previewは、今後の注視が必要ですね。

2026/09/10追記

Discover and replicate VMware VMs for migration to Azure Local using Azure Migrate
Configure the source appliance and discover VMs にVDDKが使えない場合は、3rd Partyによる移行オプションを使うよう、コメントが入りましたね。

Windows Server ＆ Cloud User Group Japan 第52回勉強会セッション資料「WAC 2606の変更点、WAC vMode PreviewのPowerShell概要」

WAC 2606の変更点、WAC vModeのPowerShell by @sshzk

2026年8月16日日曜日

Azure Local 2606でiSCSI接続その2

New-IscsiTargetPortalQNAPで共有ディスクを作り直しました。接続は、

外部ストレージアレイを Azure Local に接続する

を参照しています。ただし再度実行する必要がないところは省略しました。

外部ストレージアレイを Azure Local に接続する

に則ります。

「手順 1: Windows機能とサービスを有効にする」は、実行済みなのでスキップ。
「手順 2: MPIO にベンダーを登録し、設定を構成する」は、記載されているベンダーデバイスではないゆえ、スキップ。
「手順 3: iSCSI ネットワークを構成する (iSCSI のみ)」は、スキップ。
「手順 4: ストレージアレイを構成し、LUN を提示する」は、QNAP側で設定しました。
「手順 5: iSCSI ターゲットに接続する (iSCSI のみ)」を再実行しました。

もう片系も同じように設定します。New-IscsiTargetPortalを間違えて2回実行してますが。。。

「手順 6: 構成を確認して再起動する」を再実行しました。

「手順 7: SAN ディスクを確認する」を再実行しました。
ここで以前のディスクが残っていることに気づき、別稿の通り対応しました。
別稿の通り対応した結果、QNAPのSANディスク二つのみになりました。
「手順 8: ディスクを初期化してフォーマットする」を再実行しました。
ドライブレターは念のため外してみました。
SANディスクが両ノードから見えていることを確認しました。
次回、再デプロイしてみます。

2026年8月15日土曜日

Azure LocalでiSCSI接続をロールバック

接続が永続的なのに、いきなりDisconnect-IscsiTargetを実行してはまりました。

外部ストレージアレイを Azure Local に接続するの手順 7: SAN ディスクを確認するからのロールバックを開始しました。

手順 5: iSCSI ターゲットに接続する (iSCSI のみ) だからDisconnect-IscsiTargetでよいだろうと、2ノードともに実施しました。

別のiSCSIターゲットからディスクを追加したところ、Disconnect-IscsiTargetで切断したはずのディスクも見えます。

PowerShellでPersistent接続にしたディスクを解除する方法が見当たらない（正確には切断の手順誤りで、Unregister-IscsiSessionを実施すべきと後からわかりました）。

生成AIを駆使してみたところ、Unregister-IscsiSessionを実施すべきと出たので実施したものの後の祭り。

その後も生成AIを使いながら、試行錯誤しました。該当のiSCSIターゲットに絞ってセッションを改めて特定。

途中で、4と5が該当ディスクでしたので、改めてGet-Diskにて情報を採取しました。

各々のディスクからパーティション情報を取得したところ、ここでドライブレターがあることを認識しました。

MPIO周りの情報を見ておきます。

各々のディスクをオフラインにします。

再度iSCSIセッション情報を取得します。

iscsicli ListPersistentTargetsにて、Persistent Targetを確認します。

iscsicli RemovePersistentTarget ROOT\ISCSIPRT\0000_0 "iqn.1991-05.com.microsoft:pet440-pet440-iscsitarget-target" 12 192.168.3.8 3260

にてiSCSIターゲットとの永続的な接続を切りました。

確認したところもう一つのほうがあります。

これも同じように削除しておきます。

iscsicli RemovePersistentTarget ROOT\ISCSIPRT\0000_0 "iqn.1991-05.com.microsoft:pet440-pet440-iscsitarget-target" 13 192.168.3.8 3260

全iSCSIセッション情報を取得します。

各セッションをセッションをLogoutします。

ということで、同じ手順でもう片系ノードもロールバックを実施しました。。。

Azure Local 2606でiSCSI接続

都合により今回は、Azure Local 2606でiSCSI接続を確認します。

結論を先に書くと、Microsoft iSCSI Targetではダメかもしれません。別途QNAPでも確認します（これもサポート対象と書かれていないのですが、使えそうな機器はこれしかない）。

以下、

外部ストレージアレイを Azure Local に接続する

に基づき、Microsoft iSCSI Targetの接続していた例です。今回はNested Azure Localかつサポート対象ではない機器故、一部の手順を省略しています。ご了承ください。

手順 1: Windows機能とサービスを有効にする

マルチパス I/Oの有効化、iSCSI イニシエーターサービスを有効化

マルチパスI/O（Multipath I/O）の有効化とベリファイ、iSCSI イニシエーターサービスを有効化とベリファイを連続して実施しました。下記は、片系ノードの画面キャプチャです。もう片系ノードも同様に実施しました。

イニシエーター識別子を収集

下記は、片系ノードの画面キャプチャです。もう片系ノードも同様に収集します。

外部ストレージアレイを Azure Local に接続するに載っていませんが、iSCSIターゲットに古たー識別子を登録しました。

手順 2: MPIO にベンダーを登録し、設定を構成する

負荷分散ポリシーを設定

iSCSI 自動要求を有効

IPアドレスなどを設定

手順 5: iSCSI ターゲットに接続

手順 6: 構成を確認して再起動する

手順 7: SAN ディスクを確認する

手順 8: ディスクを初期化してフォーマット

スクリプトをよく見るとドライブレターが割り当てられています。これが影響している可能性もあるかもしれませんね。
準備が終わったのでデプロイしていこうとしました。しかしBasicのMachine Validationがエラーになりました。
iSCSI接続のロールバックに続く。

Azure Local deployment local identity with key vault その2

Azure Local deployment local identity with key vault その1

からの続き。今回は、実際にデプロイを進めます。

Basicです。こちらの下記画面は、通常通り設定しており、S2Dのままです。

Identity Providerは、local identity with key vaultを選びます。それ以外は、通常通り設定しています。

Configurationです。新規構成として、通常通り設定しています。

Networkingです。Nested Hyper-V構成ゆえ仮想スイッチ経由となるため、ストレージ通信はNWスイッチ経由を選択しています。

仮想NICを6ポート用意し、Management、Compute、Storageの描くインテントに割り当てられるようカスタム構成を選びます。

各インテントごとに仮想NICを選択しつつ、RDMAは無効化します。

クラスターで使用するIPアドレス情報、DNSゾーンを指定します。

DNSサーバーを指定し、サブネットを検証します。

Managementです。カスタムロケーションとして、当方はクラスター名を流用しています。Witnessで使用するストレージアカウントを作成しています。

ADレスであるため、各ノードで共通するローカル管理者アカウントのみを指定します。

Securityです。推奨値のままとします。

Advancedです。CSVなどのボリュームは推奨構成のままとします。

Tagsです。後々トライする可能性も鑑みて、設定しています。

Validationです。Nestedゆえかはわかりませんが、1時間弱かかってます。

サマリーを確認ののち、デプロイします。

3時間かからずに完了しました。

デプロイのウィンドウが1号機に残っていました。

デプロイ完了後、Azure Localのサマリーを確認しました。Local with key vaultになっています。

ストレージパスは下記の通りです。

Key Vaultは下記のようになっています。ローカル管理者のクレデンシャルが含まれています。

最後に、各ノードのOpen sshdです。

前提条件でsshアクセスを有効化していましたが、各ノードのsshdは自動起動していないです。

登録: 投稿 (Atom)