ESX VMFSが「消失」する原因は何ですか。

最後の更新
PDFとして保存

Views:: 1,398

Visibility:: Public

Votes:: 1

Category:: data-ontap-8

Specialty:: 7dot

Last Updated:

すべてのとおり

環境

ONTAP
Data ONTAP 7以前
FlexPod

回答

VMFS再署名イベントをトリガーするものは何ですか。

VMFSの再署名を許可するのはどのような場合ですか。また、許可しないのはどのような場合ですか。

Virtual Machine File System（VMFS）にはUniversally Unique Identifier（UUID）とメタデータがあり、LUNのプロパティによって決まります。 VMFSを含むLUNが検出されると、VMFS内のメタデータがLUNのプロパティと比較されます。このチェックの目的は、LUNへの有効なパス（マルチパスに追加のパスが使用される可能性がある）とLUNのコピーを区別することです。プロパティが一致すると、LUNがLUNへの有効なパスであると判断されます。プロパティが一致しない場合、LUNは元のLUNではなく、LUNのスナップショットまたはクローンであると判断されます。

LUN/VMFSが認識されておらず、メタデータが一致する場合、新しいVMFSがマウントされてアクセス可能になります。

パスがマウントされた既存のVMFSへの追加パスである場合、そのパスはマルチパス用に追加パスとして追加されます。パスは esxcfg-mpath -l.

メタデータがLUNのプロパティと一致しない場合、ESXはLUNをスナップショットまたはクローンと判断します。（VMwareでは、これをVMFSのスナップショットと呼びます。 NetApp用語では、スナップショットが読み取り専用であるため、スナップショットLUNのクローンを作成して書き込み可能にする必要があります）。 ESXは、2つのLVMオプションの設定に応じて、3つのアクションのいずれかを実行します。

デフォルトの操作：LUN

LVM.DisallowSnapshotLun=1 LVM.EnableResignature=0

ESXはLUNを無視します。 VMFS ボリュームは、 /vmfs/volumes またはVirtualCenterの[Configuration]>[Storage]では表示されません。 LUN自体（およびそのすべてのパス）は、該当するHBAの[設定]>[ストレージアダプタ]に表示されますが、エントリは /var/log/vmkernel、ESXホストの物理コンソールと同様にログインします。

Sep 10 12:59:49 esx1 vmkernel: 0:02:55:05.943 cpu1:1031)LVM: 5777: Device vmhba1:0:0:1 is a snapshot: Sep 10 12:59:49 esx1 vmkernel: 0:02:55:05.943 cpu1:1031)LVM: 5783: disk ID: len 22, lun 0, devType 0, scsi 5, h(id) 286614107086019105> Sep 10 12:59:49 esx1 vmkernel: 0:02:55:05.943 cpu1:1031)LVM: 5785: m/d disk ID: len 22, lun 0, devType 0, scsi 5, h(id) 4520976606442506935> Sep 10 12:59:49 esx1 vmkernel: 0:02:55:05.953 cpu1:1031)LVM: 5777: Device vmhba1:0:0:1 is a snapshot: Sep 10 12:59:49 esx1 vmkernel: 0:02:55:05.953 cpu1:1031)LVM: 5783: disk ID: len 22, lun 0, devType 0, scsi 5, h(id) 286614107086019105> Sep 10 12:59:49 esx1 vmkernel: 0:02:55:05.953 cpu1:1031)LVM: 5785: m/d disk ID: len 22, lun 0, devType 0, scsi 5, h(id) 4520976606442506935> Sep 10 12:59:49 esx1 vmkernel: 0:02:55:05.958 cpu1:1031)ALERT: LVM: 4941: vmhba1:0:0:1 may be snapshot: disabling access. See resignaturing section in SAN config guide.
一時的なLUNの使用：

LVM.DisallowSnapshotLun=0 LVM.EnableResignature=0

ESXは変更せずにVMFSをマウントします。このオプションを使用すると、実際のLUN Snapshotを使用できなくなります。このオプションを使用してLUNのスナップショットまたはクローンにアクセスし、元のLUNもマウントされている場合、この2つは混乱し、破損する可能性があります。

警告：
元のLUNも同じESXホストからアクセスされている場合は、このオプションを使用してLUNの実際のスナップショットまたはクローンにアクセスしないでください。結果は予測不可能であり、腐敗が発生する可能性があります。

LUNまたはスナップショット/クローンの永続的な使用（再署名あり）：

LVM.DisallowSnapshotLun=1 or 0 (setting is ignored) LVM.EnableResignature=1

LUNのプロパティと一致しないメタデータでVMFSが検出されると、VMFSが再署名されます。つまり、LUNのプロパティに一致するようにメタデータが更新され、新しいUUIDが生成されます。 VMFSは、 /vmfs/volumes 新しいUUIDと「Snap-00000001-」形式のシンボリックリンクでに表示されます。シンボリックリンク名はVirtualCenterの [構成（Configuration）]>[ストレージ （SCSI、SAN、およびNFS）]にも表示され

ます。一般に、LUN/VMFSアクセスまたはスナップショットの状態に関する問題は、Filer側のLUNプロパティを修正するか、再署名することで解決する必要があります。前述のようにLUNを一時的に使用する場合、NetAppストレージでのユースケースはほとんどありません。

注意：
LUNの再署名を実行する場合は、1つのホストからのみ実行する必要があります。また、別のホストからの再署名を避けるために、再署名の直後に設定を変更する必要があります。

辞任の意味合い

LUNプロパティが変更されてVMFSが再署名された場合、VMFSに登録されていたVMはVirtualCenterで「アクセス不能」になります。これは、VM（特にその .vmx ファイル）がを使用して登録されるためです /vmfs/volumes/<UUID> path。 VMFSが再署名された場合は、VMを再登録するか、既存の登録を修正する必要があります（下記を参照）。

原因VMFSメタデータとLUNプロパティが一致しない可能性があるイベント

LUN IDの変更
原因：
- 管理エラー（LUNのマッピングを解除して誤ったIDにマッピングされたか、異なるLUN IDで複数のESXホストにマッピングされたLUN）。
  対処方法： 可能であれば正しいLUN IDを使用してマッピングを解除し、再マッピングしてください。
- 新しいLUNへのクローンまたはミラーリング
  ベストアクション：再署名。クローン内のすべてのVMが新しいVMとして登録されます。
- SSIへのcfmodeの変換
  ベストアクション：再署名。 VMの再登録または修正 vmInventory.xml （以下を参照）

LUNノシリアルハンコウノヘンコウ
- 原因：NVRAMカードが（単独で、またはヘッド/コントローラの交換またはアップグレードの一環として）交換されると、FilerはすべてのLUNに新しいシリアル番号を割り当てます。バグ 255243を参照してください。
  fas3070a> lun show -v /vol/failtest/lun 100g (107374182400) (r/w, online, mapped) Serial#: HnSsd4DgUiAW Share: none Space Reservation: enabled Multiprotocol Type: vmware Maps: esx1=13 esx2=13

再署名を許可するタイミング

VMFSを含むLUNが、Filer内またはFiler間でクローニングされた場合（FlexClone、LUNクローン、またはSISクローン）、ミラーリングされた場合（SnapMirror後にbreak/onlineまたはSyncMirrorスプリット）、またはコピーされた場合（ndmpcopy、dd）。これはLUNの新しいコピーであり、再署名が必要です。このような場合、クローニングされたVMは新しいインスタンスであり、登録（名前、SID、IPアドレスなどの競合を避けるために再設定）する必要があります。

辞任を回避するタイミング

ハードウェアの変更によってLUNプロパティが変更され、VMFS上に有効なVMが存在する場合は、ESXホストを起動したり、ストレージまたはLUNに接続したりする前に、Filer上のLUNプロパティを修正して、可能であればLUNの再署名を防止します。

いずれの場合も、LVMオプションを設定するか、Filer側の問題を修正してから、ESXで再スキャンします。1つのESXホストを最初に再スキャンします。再署名は1回だけ行う必要があるため、最初のホストでVMFSが認識されて安定したら、他のESXホストで再スキャンします。

SSIへの移行

SSI（Single System Image）という用語は、他のcfmodeとは異なり、SSIでは両方のコントローラ/ヘッドのワールドワイドノード名（WWNまたはWWNN）が同じであることに由来します。両方のヘッドの各FCPポートには、共通のWWNに基づいて一意のWorld Wide PortName（WWPN）が割り当てられます。VMwareに影響する問題は、スタンバイモードやパートナーモードとは異なり、SSIでは、各コントローラのLUNを同じLUN IDで同じイニシエータにマッピングできないことです。スタンバイモードまたはパートナーモードで、両方のヘッドで同じイニシエータに同じLUN IDでマッピングされたLUNがある場合は、競合する各ペアの1つのLUNを未使用のLUN IDに再マッピングする必要があります。つまり、LUN IDがVMFSメタデータと一致しないため、再署名が必要になります。

これは、多数のLUNペアで発生する可能性があります。これらのLUN上のVMFS内のVMはすべて「アクセスできない」状態になり、再登録が必要になります。影響を最小限に抑えるには、競合する1つのVMFSに含まれるVMの数が少ないかどうかを確認するために環境を調べ、そのLUNを再マッピングして再登録するVMの数を最小限に抑えることをお勧めします。

iSCSIからFCPへの移行

iSCSIからFCPに移行する場合は、可能であれば、FCPで使用したLUN IDと同じLUN IDをFCPに使用する必要があります。FCP cfmodeがSSIで、各コントローラ/ヘッドの一部のiSCSI LUNが同じIDの同じイニシエータにマッピングされている場合は、この処理が常に可能であるとは限りません。これは、上記のSSIへの移行と同じ手順で解決する必要があります。この状況を回避するには、両方のコントローラのLUNを同じLUN IDで同じイニシエータにマッピングしないでください。一方のヘッドで最初の20個のLUN IDともう一方のヘッドで2番目のLUN ID、偶数/奇数の割り当てなどのスキームを使用します。一方のコントローラがVMwareに使用され、もう一方が他のアプリケーションに使用されている場合、これらの競合は発生しません。多くの場合、ユーザーは事前にこれについて知らないでしょう。

FCPからiSCSIへの移行で競合が発生することはありません。LUN IDはFCPの場合と同じにします。

コントローラまたはNVRAMの手順のスワップまたはアップグレード

コントローラまたはNVRAMカードの交換後、新しいNVRAM IDに基づいてシリアル番号がLUNに反映されるように変更されることがあります。これにより不要な再署名イベントが原因され、次のように回避する必要があります。

スワップの前に、lun show -vを使用してLUNのS/NなどのLUNプロパティを収集します。（テイクオーバー中の場合は、partner lun show -vを実行します。このデータはAutoSupportでも使用できます）。
すべてのESXホストでVMFSの再署名をオフにします。
コントローラまたはNVRAMカードを交換してください。
コントローラを起動しますが、LUNを使用してESXホストを起動しないでください。
LUNごとに：
- lun offline /vol/volname/lun_name
- lun serial /vol/volname/lun_name old_serial_number
- lun online /vol/volname/lun_name
lun show -vコマンドを使用して、LUNのS / NSとIDを確認します。
ESXを起動します。
注：
その他の技術情報アーティクルでは、lun attribute listコマンドとLUN attribute setコマンドを参照しています。これは機能的には上記の方法と同じです。

LUNのリストア

（SnapRestore、テープからのリストア、SnapVaultなど）

元のLUNの代わりにLUNをリストアする場合は、以前と同じプロパティを使用してLUNをリストアする必要があります。 ESXホストを起動または接続する前に、LUN IDとS/Nを確認してください。
LUNを別の場所にリストアしていて、元のLUNがまだ存在していてESXで使用されている場合は、リストアしたLUNのLUN IDとシリアル番号が異なる必要があり、リストアしたLUNのVMFSを再署名する必要があります。

仮想マシンを再登録する方法

VMFSがすべてのESXホストから認識できることを確認します。
「アクセスできない」VMを削除します。
データストアを参照します（ ESX host --> Summary --> データストアを右クリックします）。
データストア内を参照して各VMの .vmx ファイルを探します。
vmxを右クリックし、[Add to inventory]を選択します。
「アクセスできない」VMごとに手順2～5を繰り返します。

代替（詳細）方式

最初のESXホストをメンテナンスモードにするか、自動DRSを無効にします。
機能しているVMを他のホストに移行します。
ESXサービスコンソールにSSH接続します。
cd /vmfs/volumes
ls -l
[root@esx1 volumes]# ls â??l drwxrwxrwt 1 root 1260 Nov 27 11:58 474c4a74-b4cc8c53-6e29-000423c3e840 drwxrwxrwt 1 root 980 Nov 27 08:49 474c4aa2-772bdc66-e441-000423c3e840 drwxrwxrwt 1 root 1260 Nov 27 11:58 474c955b-527b5a13-1417-000423c3e840 lrwxr-xr-x 1 root 35 Nov 29 13:36 snap-00000002-VMFS11 -> 474c955b-527b5a13-1417-000423c3e840 lrwxr-xr-x 1 root 35 Nov 29 13:36 VMFS11 -> 474c4a74-b4cc8c53-6e29-000423c3e840 lrwxr-xr-x 1 root 35 Nov 29 13:36 VMFS13 -> 474c4aa2-772bdc66-e441-000423c3e840
アクセスできないVMが存在するデータストアの新しいUUIDをメモ（またはコピー）します。 VMFS自体を調べて、どのVMがどこに配置されているかを確認する必要がある場合があります。
cd /etc/vmware/hostd
cp vmInventory.xml vmInventory.xml - save
vmInventory.xml アクセスできないVMのUUIDを編集し、データストアの正しいUUIDに変更します。（どのVMがどのデータストアに含まれているかが不明な場合は、各データストアを調べて、各VMに適切なUUIDがあることを確認します）。
保存し vmInventory.xml てエディタを終了します。
ESXを再度読み取るには vmInventory.xml、次の手順を実行します。
[root@esx1 hostd]# service mgmt-vmware restart Stopping VMware ESX Server Management services: VMware ESX Server Host Agent Watchdog [ OK ] VMware ESX Server Host Agent [ OK ] Starting VMware ESX Server Management services: VMware ESX Server Host Agent (background) [ OK ] Availability report startup (background) [ OK ]
すべてのVMに適切にアクセスできることを確認します。
ESXホストのメンテナンスモードを解除するか、DRSを元の設定に戻します。 vmInventory.xml NFSデータストアおよびVMFSデータストア内のVMのUUIDパスを含むサンプルファイル：
[root@esx1 hostd]# more vmInventory.xml <ConfigRoot> <ConfigEntry id="0006"> <objID>112objID> <vmxCfgPath>/vmfs/volumes/9f801592-14465f39/WinNFS8/WinNFS8.vmxvmxCfgPath> ConfigEntry> <ConfigEntry id="0027"> <objID>608objID> <vmxCfgPath>/vmfs/volumes/46e5a3bf-2d233fa0-1546-0014220f1381/houwin2003sp2-8/houwin2003sp2-8.vmxvmxCfgPath> ConfigEntry> ConfigRoot>

追加情報

ESXホスト上のVMFSへの最初の接続、追加パス、またはスナップショット/クローンのいずれであっても、既存のVMFSの検出に[ストレージの追加]ウィザードを使用しないでください。 [Add Storage]ウィザードは、LUNを新しいVMFSでフォーマットするためのウィザードです。

警告：LUNをフォーマットすると、既存のVMFS とその内容が破棄されます。

すでに「アクセスできない」VMがないか、またはその他の問題（VMDKまたはRDM LUNがない）があることを確認します。すべてのESXホストでvmware-cmd -lの出力をキャプチャすると便利です。 VMotionでは、VMが表示されるESXホストは変更される可能性がありますが、VMXパスは一定である必要があります。
すべてのVMFSが想定どおりに認識されることを確認します。名前とUUIDをメモします。（ls -l /vmfs/volumes)
各LUNへのパスが想定どおりであることを確認します。
Filerから次の情報を取得します。この情報は、最新のAutoSupportにも記載されています。
- lun show -v
- igroup show
- fcp show initiators（FCPを使用している場合）
- iscsi show initiators（iSCSIを使用している場合）
ONTAP 7.2.4より前のバージョンでは、次のようにしてLUNのシリアル番号が変更されていました。
- ヘッド交換（NVRAM）
- ONTAPのアップグレード
- CFODisaster（MetroCluster）