メインコンテンツまでスキップ

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

  1. 最後の更新
  2. PDFとして保存
Views:
865
Visibility:
Public
Votes:
0
Category:
data-ontap-8
Specialty:
virt
Last Updated:

すべてのとおり  

環境

  • ONTAP
  • Data ONTAP 7 以前 
  • FlexPod 

回答

VMFS再署名イベントをトリガーする理由は何ですか？

VMFSの再署名を許可する必要があるのはいつですか。また、いつできますか。

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

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

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

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

  1. デフォルトの操作：LUN

    LVM.DisallowSnapshotLun=1
    LVM.EnableResignature=0

    ESXはLUNを無視します。  VMFSボリューム /vmfs/volumesは、VirtualCenterでは、Configuration > Storageの下に表示されません。  LUN自体 （およびそのすべてのパス）は、[Configuration]>[Storage Adapters]で適切な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.
  2. 一時的なLUNの使用：

    LVM.DisallowSnapshotLun=0
    LVM.EnableResignature=0

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

 

警告：
元のLUNが同じESXホストからもアクセスされている場合は、このオプションを使用してLUNの実際のSnapshotまたはクローンにアクセスしないでください。  結果は予測不能であり、破損が発生する可能性があります。
  1. 永続的な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アクセスまたはスナップショットの状態に関する問題は、ストレージシステム側でLUNプロパティを修正するか、再署名によって解決する必要があります。  上記で詳述する一時的なLUNの使用には、ネットアップストレージでの使用事例がほとんどありません。
注意
：LUNの再署名を実行する場合は、1つのホストからのみ実行する必要があり、再署名の直後に設定を変更して、別のホストからのLUNの再署名を回避する必要があります。

 

辞職の影響

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

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

  • LUN IDの変更
  • 原因：
    • 管理エラー（LUNのマッピングが解除されて間違ったIDにマッピングされるか、LUNが異なるLUN IDの複数のESXホストにマッピングされる）。
      最適な対処方法 ：可能であれば、正しい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クローン）されると、Filer内またはFiler間で、ミラー（SnapMirrorの場合はオンラインまたはSyncMirror スプリット）されるか、コピー（ndmpcopy、dd）されます。これはLUNの新しいコピーであり、再署名する必要があります。このような場合、クローニングされたVMは新しいインスタンスであり、名前、SID、IPアドレスなどの競合を回避するために登録（場合によっては再設定）が必要になります。

再署名を避けるべき時期

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

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

SSIへの移行

SSI（Single System Image）という用語は、他のcfmodeとは異なり、SSIを使用すると、両方のコントローラまたはヘッドに同じワールドワイドノード名（WWNまたはWWNN）が設定されるという事実から由来しています。両方のヘッドの各FCPポートは、共通のWWNに基づいて一意のワールドワイドポート名（WWPN）を持ちます。VMwareに影響する問題 は、スタンバイモードやパートナーモードとは異なり、各コントローラのSSIでは、同じ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への移行では、可能であればiSCSIに使用したのと同じLUN IDをFCPに使用する必要があります。FCP cfmodeがSSIで、各コントローラ/ヘッドの一部のiSCSI LUNが同じIDの同じイニシエータにマッピングされている場合は、この構成は常に可能ではありません。上記のSSIへの移行と同じ手順 で解決する必要があります。このシナリオでは、両方のコントローラのLUNを同じLUN IDの同じイニシエータにマッピングしないようにします。一方のヘッドで最初の20個のLUN IDを、もう一方で2個目のLUN IDを指定する、奇数または偶数個の割り当てを指定するなどの方式を使用します。1台のコントローラがVMwareに使用され、もう1台のコントローラが他のアプリケーションに使用されている場合、これらの競合は発生しません。  多くの場合、ユーザーはこのことを事前に知ることはできません。

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

コントローラまたはNVRAMがスワップするか、手順 をアップグレードしてください 

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

  1. スワップする前に、lun show -vを使用してLUN S/NなどのLUNプロパティを収集します  （テイクオーバー中の場合は、partner 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を起動します。
    注
    ：その他のKnowledgeBaseの記事では'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をメモ（またはコピー）します。  VMFS自体を参照して、稼働しているVMを確認しなければならない場合があります。
  7. cd /etc/vmware/hostd
  8. CP vmInventory.xml vmInventory.xml -save
  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.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を検出しないでください。  「ストレージの追加」ウィザードは、新しいVMFSでLUNをフォーマットするためのウィザードです。 
警告：LUNをフォーマットすると、既存のVMFSとその内容が破棄されます。
  •  すでに「アクセス不能」なVMがないこと、またはVMDK LUNまたはRDM LUNがないことなどの問題が発生しているVMがないことを確認します。  すべての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 -「Resignaturing VMFS3 Volumes that are not Snapshots」(スナップショットではないVMFS3ボリュームを再署名する

 

Scan to view the article on your device