NFSv3 データストア上の仮想マシンがバックアップ中のスナップショット統合が失敗することにより停止する可能性がある

Products

• VMware vSphere ESXi
• VMware vSphere ESXi 8.0

Issue/Introduction

免責事項：これは英文の記事「Virtual machines on NFSv3 datastores might fail due to a failed snapshot consolidation during backup. (402937)」の日本語訳です。記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。最新情報は英語版の記事で参照してください。

この問題は、サードパーティ製バックアップソフトウェアが1つ以上のディスクをアクティブに開いたまま（オープン状態）保持している間に、スナップショット統合が要求された場合に発生します。

ホスト管理エージェントのログ（/var/run/log/hostd.log）には、これに関連するイベントが記録されます。

Hostd[<WORLD_ID>]: [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/<NFS_VOLUME_UUID>/<VM_HOME_FOLDER>/<VM_NAME>.vmx] Handling vmx message nnnnnn: Locking conflict for file "/vmfs/volumes/<NFS_VOLUME_UUID>/<VM_HOME_FOLDER>/<VM_NAME>-000001-delta.vmdk". Kernel open flags are 0x8. Owner process on this host is world ID nnnnnn with world name vmx-vcpu-0:VM_NAME.
Hostd[<WORLD_ID>]: --> Failed to lock the file
Hostd[<WORLD_ID>]: --> Cannot open the disk '/vmfs/volumes/<NFS_VOLUME_UUID>/<VM_HOME_FOLDER>/<VM_NAME>-flat.vmdk' or one of the snapshot disks it depends on.
Hostd[<WORLD_ID>]: --> An operation required the virtual machine to quiesce and the virtual machine was unable to continue running.
Hostd[<WORLD_ID>]: [Originator@6876 sub=Vimsvc.ha-eventmgr] Event nnnn : Error message on VM_NAME on ESX_SERVER_FQDN in ha-datacenter: An operation required the virtual machine to quiesce and the virtual machine was unable to continue running.
Hostd[<WORLD_ID>] [Originator@6876 sub=Vimsvc.ha-eventmgr] Event nnnn : Virtual machine VM_NAME disks consolidation failed on ESX_SERVER_FQDN in cluster CLUSTER_NAME in ha-datacenter.

VM が HA（High Availability）によって再起動された場合、/var/run/log/fdm.log に以下のようなログが確認されることがあります。

[YYYY-MM-DDTHH:MM:SS] Db(167) Fdm[2107401] [Originator@6876 sub=Invt opID=WorkQueue-######] Vm /vmfs/volumes/###############/######/######.vmx changed  guestHB=red
[YYYY-MM-DDTHH:MM:SS] In(166) Fdm[2107406] [Originator@6876 sub=Invt opID=WorkQueue-######] Vm /vmfs/volumes/###############/######/######.vmx curPwrState=powered on curPowerOnCount=1 newPwrState=powered off clnPwrOff=false hostReporting=__localhost__
[YYYY-MM-DDTHH:MM:SS] Db(167) Fdm[2107406] [Originator@6876 sub=Invt opID=WorkQueue-######] Vm /vmfs/volumes/###############/######/######.vmx localhost: local power state=powered off; global power state=powered off
[YYYY-MM-DDTHH:MM:SS] Db(167) Fdm[2107406] [Originator@6876 sub=Invt opID=WorkQueue-######] vm /vmfs/volumes/###############/######/######.vmx from __localhost__ changed inventory  cleanPwrOff=0
[YYYY-MM-DDTHH:MM:SS] Db(167) Fdm[2107406] [Originator@6876 sub=Invt opID=WorkQueue-######] Vm /vmfs/volumes/###############/######/######.vmx changed  guestHB=gray
[YYYY-MM-DDTHH:MM:SS] Db(167) Fdm[2107403] [Originator@6876 sub=Execution opID=host-######:##:########-#] Failing over vm /vmfs/volumes/###############/######/######.vmx (isRegistered=true)
[YYYY-MM-DDTHH:MM:SS] Db(167) Fdm[2107403] [Originator@6876 sub=Execution opID=host-######:##:########-#] Registering vm done (vmid=/vmfs/volumes/###############/######/######.vmx, hostdVmId=)
[YYYY-MM-DDTHH:MM:SS] Db(167) Fdm[2107403] [Originator@6876 sub=Execution opID=host-######:##:########-#] Reconfiguring vm
[YYYY-MM-DDTHH:MM:SS] Db(167) Fdm[2107567] [Originator@6876 sub=Invt opID=WorkQueue-######] GuestKernelCrashed is false for VM 38
[YYYY-MM-DDTHH:MM:SS] Db(167) Fdm[2107567] [Originator@6876 sub=Invt opID=WorkQueue-######] VM 38: Updated GuestKernelCrashed!

 

Cause

• バックアップソフトウェアが、VMが現在書き込みを行っているデルタディスク（差分ディスク）の親ディスクに対して読み取り専用アクセスを保持したまま、スナップショットの削除/統合を要求している。
• 親ディスクであるデルタディスクが依然としてオープン状態であるため、排他的アクセスができず、統合が失敗する。
  • 子のデルタディスクがオープンされている間、親ディスクは読み取り専用のままとなる。
• この失敗が発生している間、バックアップソフトウェアからのNFCオープンによって保持されていた親ディスクの「読み取り専用ロック」が、意図せずアップグレード（排他ロックへ変更）されてしまい、その後のあらゆるオープン処理が失敗する。
• バックアッププロキシが親ディスクをクローズするまで、VMのパワーオンは失敗し続ける。

 

Resolution

失敗したVMのパワーオン方法

VMをパワーオンできるようにするには、オープン状態を強制的にクローズして、親ディスクのロックを解放させる必要があります。これには以下のいずれかの操作を行います。

• バックアッププロキシ/サーバー上で、該当VMの保留中（ペンディング）のバックアップジョブを停止、または強制終了する。
  
  もしくは: 
  
  
• 稼働中の他の VM を移行させた後、失敗時に VM が実行されていたESXiサーバーを再起動する。

恒久対策: VMの失敗を回避するには、ESXiサーバーを ESXi 8.0 Update 3e にパッチ適用してください。このリリースで修正されています。

回避策:
この問題の原因となっている「NFSロックのアップグレード機能」を無効化するための、VM 単位およびホスト単位の回避策があります。

VM 単位の対応:
NFSロックアップグレード機能を無効にするには、VMの構成パラメータ consolidate.upgradeNFS3Locks を "FALSE" に設定します。具体的には、VMの構成ファイル（.vmx）に以下を設定します。

consolidate.upgradeNFS3Locks = "FALSE"

※この設定を反映させるには、VMを一度パワーオフし、設定後に再度パワーオンする必要があります。設定変更の手順については、Tips for editing a .vmx file を参照してください。

ホスト単位の対応:
ホスト全体の設定をメンテナンスモード中に行えば、VMがそのホストに戻った際に自動的に適用されます。推奨される手順は以下の通りです。

-ホストをメンテナンスモードにする。
-ホストにSSHでログインし、/etc/vmware/config を編集して以下の行を追加する。
  consolidate.upgradeNFS3Locks = "FALSE"
-メンテナンスモードを終了する。これ以降、VMがこのホストへ移行してくると、ホストレベルの設定が読み込まれます。