ESX VMFSが「消失」する原因は何ですか。
すべてのとおり
環境
- 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のマッピングを解除して誤ったIDにマッピングされたか、異なるLUN IDで複数のESXホストにマッピングされたLUN)。
- 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
- 原因:NVRAMカードが(単独で、またはヘッド/コントローラの交換またはアップグレードの一環として)交換されると、FilerはすべてのLUNに新しいシリアル番号を割り当てます。バグ 255243を参照してください。
再署名を許可するタイミング
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)
関連リンク:
VMware の記事 9453805 - Resignaturing VMFS3 Volumes that are not Snapshots