高性能なNASをiSCSI接続し、Hyper-V 2022上で仮想マシンのディスクを運用していると、再起動後にVMのディスクが見つからなくなる問題に直面するケースがあります。ここでは、実際に遭遇したトラブルとその原因、そして解決策を詳しく紹介します。
Hyper-V 2022環境でのiSCSI接続とVM削除問題の背景
Hyper-V 2022では、NASやSANなどの外部ストレージをiSCSIで直接マウントすることができます。特にオールフラッシュNASをiSCSI接続して、高速かつ大容量のストレージを仮想マシン用のディスクとして活用するのは魅力的な手法です。しかし、ホストサーバーの再起動時などにiSCSIディスクが正しくオンラインにならず、仮想マシンのVHDXファイルが見当たらなくなる現象が報告されています。
この問題が発生すると、Hyper-Vマネージャー上では該当VMが「Off-Critical」状態となり、構成ファイルは残っているのにディスクだけが消失しているように見えるため、再起動するたびにVMが使えなくなってしまいます。原因の多くは、再起動時のiSCSIセッションの確立順序や、Hyper-Vサービスがディスクを認識するタイミングの不一致が影響していると考えられます。
iSCSIディスクをCluster Shared Volume(CSV)として構成するメリット
iSCSIディスクを単純にD:ドライブなどとして割り当てるのではなく、Cluster Shared Volume(CSV)として構成することでトラブルを回避できる可能性が高まります。特にフェイルオーバークラスター環境や複数ホストでのLive Migrationを念頭に置く場合は、CSVが推奨されることが多いです。
CSV化によるVMディスク保護
CSVとしてストレージを取り込むと、クラスターノード間でストレージを同時にマウントし、Hyper-Vがクラスターレイヤーを介して一元管理できるようになります。これにより、
- ホスト再起動時のオンライン・オフライン処理をクラスターサービスが制御してくれる
- ディスクの状態を一貫して管理できる
などの利点が生まれます。単一のホストに依存しないため、ディスクが見えなくなるリスクが格段に下がります。
CSVと通常のiSCSIマウントの違い
以下は簡単な比較表です。
| 項目 | 通常のiSCSIマウント | CSVとしてのiSCSIマウント |
|---|---|---|
| 管理方法 | 個別のホストでディスクを管理 | クラスター管理ツールを使用 |
| フェイルオーバー構成の容易さ | 手動設定が多く手間 | クラスターサービスにより容易 |
| 再起動時のディスク認識 | ホストの起動順序に依存 | クラスターが統合的に制御 |
| VMファイルアクセス | 各ホストごとにアクセスパスを定義 | クラスター名を介してアクセス可能 |
通常の単一ホスト運用では、「CSVなんてオーバースペックなのでは？」と思うかもしれません。しかし、再起動後にデータを見失ってしまうリスクを回避するうえでもCSV化は非常に有効な手段です。
フェイルオーバークラスターの構築例
もしクラスター環境を構成するのであれば、以下のような手順が一般的です。
- Windows Serverフェイルオーバークラスター機能をインストール
- クラスターを作成し、各ノード（Hyper-Vホスト）を参加させる
- iSCSIディスクをクラスターディスクとして追加
- ディスクをCSVに変換
- Hyper-V仮想マシンをCSV上に配置
こうすることで、各ノードからCSVに同時アクセスが可能となり、再起動やフェイルオーバーのタイミングでVMがオフラインになるリスクが最小限に抑えられます。
iSCSI接続の基本設定を見直す
Hyper-VホストがNAS側のiSCSIターゲットに正常に接続できているかを再確認することも大切です。ネットワーク設定やチャプター（イニシエーター）設定のミスがあると、再起動後にセッションが復元されない可能性があります。
iSCSIイニシエーターの設定
Windowsの「iSCSIイニシエーター」設定画面で、ターゲットポータルを正しく登録しているか、以下の点を確認しましょう。
- ターゲットポータルのIPアドレスとポート番号（通常3260）
- 認証方式（CHAPや別のセキュリティ設定など）
- 永続的に接続するように構成されているか
PowerShellを使って設定を確認・変更することも可能です。例えば、以下のようなコマンドでiSCSIターゲットの状況を確認できます。
# 現在のターゲットポータルを一覧表示
Get-IscsiTargetPortal
# iSCSIターゲット（IQNなど）を表示
Get-IscsiTargetターゲットとのセッションが正しく保持されているか、永続的な接続(“Enable Multi-Path”や“Persistent”の設定)がなされているかをチェックしてください。
NAS側のターゲット設定やアクセス許可
NASによっては、LUN単位でのアクセス制御が厳格に設定されている場合があります。以下のポイントを確認しましょう。
- IQNごとにアクセス可能なイニシエーターが登録されているか
- IPアドレスベースの制限がかかっていないか
- NASのファームウェアやiSCSIサービスが最新バージョンか
これらの設定に不備があると、再起動のたびにセッションが確立できず、ディスクが一時的に見えなくなるか、最悪の場合再接続されないままになってしまいます。
再起動手順の最適化
Hyper-Vホスト再起動のタイミングでiSCSIディスクが消えてしまう根本的な原因の一つとして、「ディスクがオンラインになる順序」と「Hyper-VサービスによるVMディスク参照のタイミング」が合っていないことが挙げられます。
サービス起動の依存関係
Windows Serverのサービス管理ツールを使って、iSCSI InitiatorサービスやマルチパスI/Oサービス（MPIO）がHyper-Vサービスより先に起動するように調整する方法があります。
services.mscから「Microsoft iSCSI Initiator Service」が自動起動になっていることを確認- Hyper-V仮想マシン管理サービスとの依存関係を明示的に設定する（ただし公式には推奨されない場合もある）
手動運用による回避策
CSVを使わずに通常のiSCSIドライブとしてマウントする場合、以下のような運用で回避することも考えられます。
- ホストが再起動したら、まずiSCSIディスクがオンラインになっているかを確認
- ディスクを認識・マウントした段階でHyper-Vサービスを再起動
- VMが正しくディスクを参照できる状態になってからVMを起動
この手動ステップは手間がかかりますが、ディスクの消失を防ぐための応急措置として有効です。大規模環境や自動化が求められる環境では、やはりCSV化やクラスター構成など、より堅牢な仕組みを導入したほうがよいでしょう。
ドライバ・ファームウェアの更新と検証
NASやサーバーのNIC、さらにはOSやドライバのバージョンが古いと、iSCSIセッションの安定性に悪影響を及ぼす可能性があります。Hyper-V 2022は新しいOSであるため、従来のドライバやファームウェアでは十分に最適化されていない場合もあります。
NICドライバとMPIO
iSCSI環境下では、ネットワークアダプター(NIC)のドライバがiSCSI Offload機能などをサポートしている場合があります。最新のドライバを適用することで、
- 帯域幅の向上
- 複数経路による冗長化(MPIO)の安定性向上
- 転送エラーの減少
といったメリットが得られます。
MPIOを利用する場合は、MPIO機能の有効化とターゲット登録（デバイス固有モジュールの有効化）も忘れずに行います。以下のコマンドでMPIO構成を確認できます。
# MPIOが有効になっているか確認
Get-WindowsFeature -Name MPIO
# 特定デバイスのMPIOポリシーを確認
mpclaim –s –d <対象デバイスID>NASのファームウェアアップデート
NASベンダーが提供するファームウェアには、iSCSIセッション安定化やバグ修正が含まれていることがあります。特にオールフラッシュNASは高性能な分、ファームウェアのアップデート頻度も高い場合がありますので、定期的な確認と適用が推奨されます。
アップデート前後には必ずリリースノートを確認し、どのような変更が行われているかを把握しておくとよいでしょう。
NASとネットワークの総合的な設定
iSCSIはTCP/IP上でストレージアクセスを行うため、ネットワークの構成によってパフォーマンスや安定性が大きく左右されます。特にNASとHyper-Vホストを直接10GbEや25GbE、あるいは100GbEで接続する場合は、スイッチやルーターなどの機器設定も含めて総合的にチューニングする必要があります。
ネットワークのVLANやQoS設定
- iSCSIトラフィック専用のVLANを切り分ける
- QoS（Quality of Service）を設定してiSCSIの帯域を最優先にする
- Jumbo Frame設定を導入して大きなフレームサイズでパフォーマンスを向上させる
などの調整が有効な場合があります。無闇に設定を変えるのではなく、ベンダー推奨のガイドラインや実績のある構成をもとに段階的に検証を進めましょう。
負荷テストと監視
ネットワークの安定性を確保するため、再起動前後だけでなく、負荷が高まる時間帯やバックアップジョブが走る際などにもテストを行うと安心です。以下のような監視ツールを活用するのがおすすめです。
- Windows Performance Monitor（PerfMon）
- SNMP対応のNAS監視ツール
- ネットワークトラフィック可視化ツール
これらを使って、CPU使用率、メモリ使用率、ディスクI/O、ネットワーク帯域などを総合的にチェックし、ボトルネックやエラーの兆候を早期発見できます。
CSVを使わずにiSCSIディスクを利用する場合の注意点
小規模環境や試験用として、わざわざクラスターを組まないでiSCSIディスクをシングルホストで利用したい場合もあるでしょう。そのようなケースでは以下の点に留意して運用しましょう。
自動起動順序の細かい制御
- BIOSおよびUEFIレベルでのネットワーク起動設定を確認
- Windows起動後のサービス依存関係を再調整
こういった作業を行わないと、再起動時にディスクが一時的にオフラインとなり、VMがディスクを見失ってしまうリスクが残ります。
バックアップの徹底
VMのディスクが行方不明になると、業務停止やデータ損失などのリスクが発生します。万が一に備え、オフラインバックアップ（エクスポートなど）やスナップショット、あるいはNAS側のボリュームスナップショット機能を活用し、定期的にバックアップを取得しておくことが欠かせません。
トラブルシューティングとログの活用
Hyper-VやiSCSI関連のログを入念にチェックすることで、問題の原因が特定しやすくなります。
イベントビューアの確認
Windows Serverの「イベントビューア」では、以下の項目に注目しましょう。
- System：ディスクのオンライン・オフラインやドライバ関連のエラー
- Application：iSCSIイニシエーターやNAS接続関連の警告
- FailoverClustering（クラスター環境の場合）：CSVディスクのオンライン・オフライン状況
これらのログに繰り返し発生しているエラーがあれば、そのコードやメッセージをもとに詳細を調べ、適切な対策を講じることが重要です。
NAS側のログと統合監視
NASにも独自のイベントログや監視機能があります。再起動のタイミングでNASがどのような状態だったか、ネットワーク的に切断があったか、LUNのオンラインステータスがどうだったかなど、NAS側のログとHyper-V側のログを付き合わせると正確な原因究明に近づけます。
統合監視ツールがある場合は、NASとHyper-Vホストのステータスを1つのダッシュボードで管理するようにし、インシデント発生時の全体像を素早く把握できる体制を整えましょう。
まとめ：安定したHyper-V運用を目指して
Hyper-V 2022環境でiSCSI接続された仮想マシンディスクが、ホスト再起動後に削除されてしまうという重大な問題を回避するためには、以下のポイントを押さえておくことが重要です。
- Cluster Shared Volume(CSV)の活用：クラスター機能によってディスク管理を一元化し、再起動やフェイルオーバーの影響を最小限に抑える。
- iSCSI接続設定の再確認：イニシエーター設定、NAS側のターゲット設定、ネットワーク設計を徹底的に見直す。
- 起動順序とサービス依存関係の最適化：手動運用やサービス設定を調整し、ディスクがオンラインになる前にVMが起動しないようにする。
- ドライバ・ファームウェアの最新化：NAS、NIC、サーバーOSのアップデートを適宜行い、パフォーマンスと安定性を高める。
- トラブルシューティングと監視体制の強化：イベントログやNASのログを連携し、問題発生時に迅速に対応する。
これらの対策を実施すれば、再起動後のディスク消失リスクが大幅に軽減されるだけでなく、Hyper-V環境全体の可用性やパフォーマンスの向上も期待できます。特にCSVへの移行は効果が大きく、多くの事例で「再起動後にも問題が発生しなくなった」という報告があります。自社環境や要件に合わせて慎重に検討し、より安定したHyper-V運用を実現しましょう。
コメント