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

に適用されます

• clustered Data ONTAP 8 
• Data ONTAP 7 以前 
• FlexPod 

回答

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

VMFS の再署名はいつ許可する必要がありますか。また、どのような場合に回避する必要がありますか。

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

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

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

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

1. デフォルトアクション： LUN
   
   LVM.DisallowSnapshotLun=1
LVM.EnableResignature=0
   
   ESX は LUN を無視します。  VMFS ボリュームは/vmfs/volumes、または VirtualCenter の Configuration > Storage では表示されません。  LUN 自体（およびそのすべてのパス）は、該当する HBA の Configuration > Storage Adapters で表示されます。  エントリ/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.
2. 一時的な LUN の使用
   
   LVM.DisallowSnapshotLun=0
LVM.EnableResignature=0
   
   ： ESX は VMFS を変更せずにマウントします。  このオプションを使用すると、実際の LUN スナップショットを使用できなくなります。  このオプションを使用して LUN のスナップショットまたはクローンにアクセスし、元の LUN もマウントされている場合、 2 つの LUN は混乱し、破損する可能性があります。

3. 永続的な LUN またはスナップショット / クローンの使用（再署名あり）
   
   LVM.DisallowSnapshotLun=1 or 0 (setting is ignored)
LVM.EnableResignature=1
   
   ： LUN のプロパティと一致しないメタデータで VMFS が検出されると、 VMFS は再署名されます。 つまり、 LUN のプロパティに合わせてメタデータが更新され、新しい UUID が生成されます。  VMFS は/vmfs/volumes、新しい UUID と、「 NAP-00000001 - 」という形式のシンボリックリンクを使用してで表示されます。  シンボリックリンク名
   
   は、 VirtualCenter の [Configuration] > [Storage(SCSI 、 SAN 、 NFS)] にも表示されます。一般に、 LUN/VMFS アクセスまたはスナップショットの状態に関する問題は、 Filer 側の LUN プロパティを修正するか、再署名することで解決する必要があります。  前述のように、一時的に LUN を使用する場合、ネットアップストレージの使用例はほとんどありません。

再署名の意味

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 として登録されます。
  • cfmode の SSI
    への最適な変換：再署名。  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 のクローン（ FlexClone 、 LUN クローン、または SIS クローン）を作成すると、ミラーリング（ SnapMirror の場合は、 SnapMirror の場合は中断 / オンラインまたは SyncMirror の場合はスプリット）、またはコピー（ ndmpcopy 、 dd ）が Filer 内または Filer 間で実行されます。これは LUN の新しいコピーであり、再署名する必要があります。このような状況では、クローニングされた VM は新しいインスタンスであるため、登録が必要です（また、名前、 SID 、 IP アドレスなどの競合を回避するために再設定が必要になる場合もあります）。

再署名を回避するタイミング

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

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

SSI への移行

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

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

iSCSI から FCP への移行

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

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

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

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

1. スワップする前に、 LUN S/N を含む LUN のプロパティを lun show -v で収集します  （テイクオーバー中の場合は、パートナー LUN show -v を実行しますこのデータは AutoSupport でも使用できます）。
2. すべての ESX ホストで VMFS 再署名をオフにします。 
   コントローラまたは NVRAM カードを交換してください。
3. コントローラを起動しますが、 LUN を使用して ESX ホストを起動しないでください。
4. 各 LUN について、次の手順を実行
   • lun offline /vol/volname/lun_name
   • lun serial /vol/volname/lun_name old_serial_number
   • lun online /vol/volname/lun_name
5. lun show -v を使用して、 LUN の S/NS と ID を確認します
6. ESXを起動します。
   注
   ：その他のナレッジベースの記事では、コマンド LUN 属性リストと LUN 属性セットを参照しています。  これは、機能的には上記の方法と同じです。

LUNのリストア

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

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

仮想マシンの再登録方法

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

 代替（詳細）方式

1. 最初の ESX ホストをメンテナンスモードにするか、自動 DRS を無効にします。
2. 機能している VM を他のホストに移行します。
3. ESX サービスコンソールに SSH を接続します。
4. cd /vmfs/volumes
5. 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
6. アクセス不能な VM が稼働しているデータストアの新しい UUID を記録（またはコピー）します。  どの VM がどこにあるかを確認するには、 VMFS 自体を調べる必要があります。
7. cd /etc/vmware/hostd
8. cp vminventory.xml vminventory.xml ：保存します
9. vmInventory.xml アクセス不能な VM の UUID を編集し、データストアの正しい UUID に変更します。  （どの VM がどのデータストアにあるかが不明な場合は、各データストアを調べて、各 VM に適切な UUID があることを確認します）。
10. vmInventory.xml エディタを保存して終了します。
11. 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 ]
12. すべての VM に適切にアクセスできることを確認します。
13. ESX ホストをメンテナンスモードから解除するか、 DRS を元の設定に戻します。 vmInventory.xmlNFS および 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 を検出しないでください。  「ストレージの追加」ウィザードは、 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 ）

関連リンク：

VMware の記事 9453805 ：スナップショットではない VMFS3 ボリュームの再署名