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

2026年9月16日水曜日

3 Tier Hyper-VクラスターをWindows Admin Center vModeに追加

WAC vMode PreviewにNetwork ATC設定済みのHyper-Vクラスターを追加したいその2

などで色々試して、その当時は3 Tier Hyper-VをWindows Admin Center vModeに追加できないんじゃと。しかし知人よりアドバイスいただき確認をやり直すことにしました。

結論から書くと、できました。確認の方法としては、Nested Hyper-Vですが、ストレージのインテントを工夫すれば大丈夫でした。

共有ディスクをiSCSI接続しているNested Hyper-V 3 tierクラスターを追加してみます。追加後に、3 tierクラスターであることがわかります。

インテントは下記のように設定しています。基本的には、RDMAを無効化しています。

仮想マシンの配置パスは、CSV配下にVirtual Machinesフォルダーを作る形です。

submitして追加です。

オンボード完了しました。

概要画面を表示してみました。ここで3 Tier Hyper-Vクラスターであることがわかります。

Storage Spaces Directの場合、概要画面は下記になります。

以上、物理サーバーではインテントを精査する必要はありますが、3 Tier Hyper-VクラスターをWindows Admin Center vModeに追加できますね。

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接続のロールバックに続く。

登録: 投稿 (Atom)