SANボリュームを複数ホストに割り当てると中身が違って見える原因と対処法｜Hyper-VはCSVで解決

SANの同一LUNを複数のHyper-Vホストへ割り当てたら、同じD:なのに作成したVHDXやフォルダが他ホストから見えない――。これは権限ではなく“共有前提でないNTFS/ReFSを同時マウントした”ことが原因です。安全な構成と復旧手順をまとめます。

症状：容量は同じなのに、ホストごとに見える中身が違う

まず前提として、SANのボリューム（LUN）は「ブロックデバイス」です。OSからは“1台のPCに内蔵されたディスク”と同じように扱えます。ここにWindowsの通常ファイルシステム（NTFS/ReFS）を作り、3台の仮想ホスト（例：Hyper-Vホスト）へ同時にアタッチすると、見た目は同じでも中身の整合性が崩れます。

起きている現象	現場でよく見える兆候	この時点で疑うべきこと
Host2で作ったVHDXがHost1/Host3から見えない	Host2では存在するのに、他では未作成扱い。エクスプローラー更新でも出ない	NTFSメタデータ／キャッシュがホスト間で同期されていない
Host3で作ったフォルダが他ホストから見えない	フォルダの作成・削除がホスト間で反映されない／反映が遅い	ディレクトリエントリやMFT更新が整合しない（破損の前兆）
VMの移行（ライブ／クイック）が失敗する	移行先でVHDXが見つからない、または構成ファイルが一致しない	共有ストレージを“共有前提の方法”で使っていない

結論：NTFS/ReFSは「単独ホストが排他的に使う」前提。複数ホストで同時マウントすると破綻する

原因はアクセス権ではなく設計の前提違いです。NTFS/ReFSは、基本的に「そのボリュームをマウントしているOSが唯一の管理者である」前提で、メタデータ（ファイル一覧・属性・更新日時・割り当て情報など）を管理します。

一方、SANのLUNは“ブロック”しか提供しません。複数ホストが同じブロック領域へ好き勝手に書き込める状態を作ってしまうと、ファイルシステムの整合性を保つための排他制御（ロック）やキャッシュ無効化が機能しません。その結果として「ホストごとに中身が違って見える」「突然見える／消える」「最終的にはデータ破損」という流れに発展します。

観点	SANのLUN（ブロックストレージ）	SMB共有など（ファイル共有）
提供する単位	ブロック（ディスクのセクタ）	ファイル（オープン、ロック、属性）
複数ホスト同時アクセス時の整合性	基本的にアプリ／クラスタ側で制御が必要	サーバ側でロックと整合性を制御
Windowsで安全に共有する代表例	フェールオーバークラスタ＋CSV	SOFS（Scale-Out File Server）等のSMB 3.0共有

なぜ「中身が違って見える」のか：キャッシュとメタデータ更新がホスト間で共有されない

Windowsは性能のために、ディスクの読み書きをその都度“物理I/O”せず、ファイルシステムのメタデータやディレクトリ情報をメモリにキャッシュします。通常は「同じOS内の処理」しか想定しないため、別ホストが書いた変更を検知してキャッシュを無効化する仕組みがありません。

たとえばHost2がVHDXを作成した場合、Host2では以下のような更新が行われます。

MFT（Master File Table）に新しいファイルのレコードを作成
ディレクトリエントリ（一覧）を更新
空き領域管理・割り当て情報を更新
ログ（ジャーナル）を更新

しかしHost1/Host3は、同じボリュームを“自分専用”と思い込んでキャッシュを持っているため、Host2の更新を前提にディレクトリ一覧を再読み込みしません。その結果、エクスプローラーやHyper-Vマネージャからは「存在しない」ように見えます。

さらに悪いのは、見えないだけでなく、別ホストが同じ領域に追記・削除などの更新を重ねると、メタデータ同士が衝突してファイルシステムが壊れることです。壊れ方はさまざまで、次のような形で表面化します。

表面に出る症状	内部で起きがちなこと	現場への影響
作ったはずのファイル／フォルダが消える	MFTやディレクトリ更新の競合、古いキャッシュで上書き	VM構成が壊れて起動不可、移行不可
別ホストで突然「ファイルが壊れています」	割り当て情報の破損、断片化領域への誤書き込み	VHDX破損、チェックポイント統合失敗
chkdsk要求／ボリュームがRAWになる	ファイルシステム構造の致命的破損	長時間停止、復旧コスト増大

最初にやるべき切り分け：「本当に同じLUNを見ているか」を確認する

実務では、設計上は「同じLUNを割り当てたつもり」でも、SAN側でクローン／スナップショット／ホストグループの割り当てミスにより、実は別物のLUNを見ているケースもあります。症状が“きれいに分かれる（Host2だけにしかファイルがない等）”場合は、まずここを疑うと復旧が早くなります。

確認ポイント	Windows側での確認例	判断の目安
ディスクのUniqueId/Serialが一致しているか	`Get-Disk \| Select Number,FriendlyName,SerialNumber,UniqueId,Size`	3台で同一の値なら同じLUNの可能性が高い
ディスク署名（Disk Signature）が一致しているか	`diskpart` → `select disk n` → `uniqueid disk`	同一なのに複数Onlineは危険。通常はクラスタ以外では避ける
ボリュームGUIDが一致しているか	`mountvol` で一覧確認	一致していても同時マウントは不可。次項の対処へ
SAN側のマッピング（Host/InitiatorごとのLUN）	SAN管理画面でHost Group/LUN Mappingを確認	「同容量の別LUN」が割り当てられていないか要確認

応急処置：まず“同時書き込み”を止める（被害拡大を防ぐ）

中身が食い違って見えている時点で、すでに整合性が崩れている可能性があります。最優先は「これ以上書かせない」ことです。復旧を急ぐあまり、3台でオンラインのままコピーや移行を試すと、破損が進んで取り返しがつかなくなることがあります。

書き込みを止める：対象ボリューム上のVMを停止（可能なら全ホストで）。バックアップジョブやウイルススキャンなどのI/Oも止める。
“所有者”を1台に決める：一時的にHost1のみがそのLUNをオンラインで保持する、など運用を一本化する。
他ホストではディスクをオフライン：ディスクの管理、またはSet-Disk -Number n -IsOffline $trueでオフライン化し、誤操作を防ぐ。
バックアップ／退避：VHDXや構成ファイルを別ストレージへコピー（可能ならロボコピーで再試行付き）。
整合性チェック：所有者ホストでchkdskを実行（停止が必要な場合は計画停止で）。VHDXは可能ならコピー後に検証。
根本構成に移行：次の章のCSV（またはSMB共有）へ載せ替える。

やりがちな行動	なぜ危険か	代わりにやるべきこと
3台ともオンラインのまま「見える／見えない」を更新連打する	キャッシュが絡むため、状況が変わったように見えても根本は解決しない	必ず1台に集約してオフライン運用に切り替える
ホスト間で直接ファイルをコピーして揃えようとする	壊れたメタデータ上でコピーすると、破損をコピーすることがある	まず退避先へコピーし、整合性を確認してから戻す
アクセス権（ACL）だけを疑って時間を使う	ACLが正常でも、ファイル一覧そのものが壊れていることがある	設計（同時マウント可否）を最優先で見直す

根本解決：フェールオーバークラスタ＋CSV（Cluster Shared Volumes）で“共有前提”にする

複数Hyper-Vホストで同じボリューム内容を一貫して参照・更新し、ライブマイグレーションも成立させたいなら、Windowsフェールオーバークラスタ＋CSVが王道です。CSVは「複数ノードから同じNTFS/ReFSボリュームを同時に使う」ための仕組みで、ホスト間のメタデータ整合性をクラスタが制御します。

CSVにすると、ボリュームは各ノードで同じパス（例：C:\ClusterStorage\Volume1）としてマウントされ、Hyper-Vはその配下にVHDXや構成ファイルを置けます。“共有ストレージとして安全に使う”ための前提が揃うため、「ホストごとに中身が違う」問題は構造的に起きにくくなります。

項目	CSVで得られるもの	運用上のポイント
整合性	クラスタがメタデータ操作を調停し、同時アクセスでも破綻しにくい	CSVは“クラスタの中”で使う。単体運用のままでは意味がない
可用性	ノード障害時も他ノードへ役割移動して継続しやすい	クォーラム（Witness）設計とネットワーク冗長化が重要
Hyper-Vとの相性	ライブマイグレーション、クイックマイグレーションを実現しやすい	CSV配下にVMを置き、クラスタの役割としてVMを管理する

構成前に押さえる前提条件（チェックリスト）

チェック項目	目安／推奨	理由
OS/パッチレベル	同世代（例：Windows Server 2019/2022）で揃える	クラスタ検証の通りやすさと不具合回避
Active Directory参加	クラスタノードは同一ドメイン参加が一般的	クラスタ名オブジェクト（CNO）や認証のため
ネットワーク	管理/クライアント/ライブマイグレーション/ストレージを分離（可能なら）	輻輳や障害の影響範囲を限定する
MPIO	iSCSI/FCともにMPIOを有効化し冗長化	パス障害時のI/O停止を避ける
SANの対応	クラスタ用途（SCSI-3 PRなど）をサポート	クラスタがディスクアクセスを制御するため
バックアップ	復旧手段を用意してから移行作業を始める	既存ボリュームが破損している可能性がある

導入手順：共有ディスクをCSVとして使えるようにする

大まかな流れは「クラスタを作る → 共有ディスクをクラスタに追加 → CSVに変換」です。GUIでもPowerShellでも可能ですが、ここでは作業イメージが掴みやすいように要点を整理します。

手順	操作（例）	失敗しやすいポイント
役割/機能の追加	各ノードに「Hyper-V」「フェールオーバークラスタリング」をインストール	ノード間で機能差があると検証で落ちやすい
クラスタ検証	フェールオーバークラスターマネージャで「構成の検証」	ストレージ/ネットワークの警告を放置すると後で詰まる
クラスタ作成	ウィザードでクラスタ名とIPを設定して作成	DNS登録やAD権限（CNO作成権限）が不足しがち
共有ディスクの追加	クラスタの「記憶域」→「ディスク」→「ディスクの追加」	同じLUNが全ノードから見える状態が前提（SANマッピング要）
CSVに追加	追加したディスクを右クリック→「クラスタ共有ボリュームに追加」	CSVにするとドライブ文字運用ではなくパス運用が基本になる
配置場所の統一	`C:\ClusterStorage\VolumeX\`配下にVMフォルダを作成し、Hyper-Vの既定パスも揃える	ホストごとに保存先がズレると移行が失敗しやすい

CSV運用のコツ：Hyper-V移行が安定する置き場所と設定

VM関連はCSV配下に集約：VHDX、構成ファイル、チェックポイント（AVHDX）を同じCSV配下に置く。
ライブマイグレーション用ネットワークを用意：NICを分ける、またはQoSで帯域を確保し、混雑を避ける。
“クラスタの役割”としてVMを管理：単体Hyper-Vで登録するのではなく、クラスタマネージャからVMを追加・管理する。
バックアップはクラスタ／CSV対応製品で：CSV上のHyper-Vを想定したバックアップ（VSS）で運用する。

クラスタを組めない／組みたくない場合の代替案

要件や組織事情でフェールオーバークラスタを避けたい場合でも、「ブロックを複数ホストで同時にマウント」は避けるのが鉄則です。代替案は“共有をファイル共有に寄せる”か、“共有ストレージ自体を不要にする”方向になります。

代替案1：SMB 3.0共有（SOFSなど）でVHDXを置く（Hyper-V over SMB）

WindowsはSMB 3.0以降、Hyper-Vの仮想ディスクをSMB共有上に置く構成（Hyper-V over SMB）を正式にサポートしています。複数ホストから同じ共有にアクセスしても、ファイルサーバ側がロックと整合性を管理するため、“共有前提”のアーキテクチャになります。

項目	SOFS/SMB共有の特徴	向いているケース
共有の単位	ファイル（VHDX）単位でロック・整合性を担保	ストレージをファイルサーバに集約したい
高可用性	継続可用（Continuous Availability）などの仕組みを活用可能	ファイルサーバ側もクラスタで冗長化したい
性能	SMBマルチチャネル／RDMA（SMB Direct）で高速化しやすい	10GbE以上、RDMA対応NICが使える

注意点として、SMB共有の権限設計（共有権限とNTFS権限）はミスが起きやすい部分です。Hyper-Vホスト（コンピュータアカウント）がアクセスできるよう、必要最小限の権限で明示的に許可するのが基本です。

代替案2：共有ストレージなしで移行する（Shared Nothing Live Migration / Hyper-V Replica）

「そもそも同じストレージを共有しない」設計も選択肢です。Hyper-Vには共有ストレージがなくてもVMを移行する仕組み（Shared Nothing Live Migration）があり、また災害対策としてはHyper-V Replicaでレプリケーションも可能です。

方式	特徴	注意点
Shared Nothing Live Migration	移行時にVMのストレージをネットワーク経由でコピーして移行	初回コピーに時間がかかる。帯域設計が重要
Hyper-V Replica	別ホストへ定期的に複製し、障害時に切替	同期ではないためRPOが発生。用途を選ぶ

代替案3：「ゲスト内で共有ディスクが欲しい」だけなら別解がある

目的が“Hyper-Vホスト間でVHDXを共有したい”のではなく、ゲストOS同士で共有ディスクを使ってクラスタを組みたい（例：SQL Server Always Onの一部構成、従来型のWSFCなど）というケースもあります。その場合は、ホストに同じLUNを同時マウントするのではなく、目的に合った方法を選びます。

ゲストクラスタ用途：共有VHDX（Shared VHDX）やVHD Set、またはゲストiSCSIなど（環境要件により選択）
ホストクラスタ用途：本記事のCSV、またはSOFS/SMB共有

よくある質問（現場で詰まりやすいポイント）

アクセス権（Security）を見ても異常がないのに、なぜ見えないのですか？

ACLは「見えるファイルに対してアクセスを許可するか」を決める仕組みです。今回の本質はその前段階、つまりファイル一覧（ディレクトリやMFT）がホスト間で整合していないことにあります。権限が正常でも、一覧に出てこなければ“存在しない”ように見えます。

一度オフライン→オンライン、再起動すれば直りますか？

一時的に“見えるようになる”ことはありますが、根本は解決しません。むしろ、複数ホストでオンライン化を繰り返すと、破損の進行や復旧難易度が上がることがあります。再起動で直ったように見えても、あとでVHDXが壊れたり、チェックポイント統合で失敗することがあります。

ReFSなら複数ホストで同時にマウントしても大丈夫ですか？

いいえ。ReFSも“通常用途”では単独ホスト前提です。複数ホストから安全に使うには、ReFS/NTFSいずれでもCSVなどクラスタ対応の仕組みが必要です。

いまのLUNをそのままCSVにすれば復旧できますか？

状態によります。軽微な不整合なら移行できることもありますが、すでにファイルシステムが壊れている場合は、CSV化の前に退避・整合性チェック・再作成が必要です。実務では「退避→新規にCSV用ディスクを用意→戻す」が安全です。

判断を迷わないためのチェックリスト

やりたいこと	選ぶべき方式	避けるべき方式
複数Hyper-Vホストで同じVHDXを参照し、ライブマイグレーションしたい	フェールオーバークラスタ＋CSV（またはSOFS/SMB共有）	同一LUNを各ホストでD:として同時マウント
クラスタは組めないが、共有ストレージは使いたい	SMB 3.0共有（Hyper-V over SMB）	ブロックデバイスの“生共有”
ゲストOS同士で共有ディスクが必要	共有VHDX/VHD Set、ゲストiSCSI等	ホストOSで同じNTFSを複数マウント

まとめ：同一LUNの同時マウントは“見え方の違い”ではなく、設計上のNGサイン

SANのLUNはブロックデバイスであり、NTFS/ReFSを複数Windowsホストで同時にマウントすると整合性が崩れる。
「ホストごとに中身が違って見える」は、キャッシュやメタデータの不整合が疑われ、放置するとデータ破損につながる。
共有ストレージとして使うなら、フェールオーバークラスタ＋CSVに載せるのが基本。
クラスタが難しい場合は、SMB 3.0共有（SOFS）や共有なし移行（Shared Nothing Live Migration）へ設計を寄せる。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。