Operational Defect Database
BugZero updated this defect 57 days ago.
Data sources
All data on this page is proprietary to BugZero® or gathered from public sources
VMware | 97137
ある名前空間フォルダから別の名前空間フォルダに vSAN VMDKS を移動しても、オブジェクト パス属性が更新されない
Last update date:
3/24/2024
Affected products:
vSAN
Affected releases:
7.08.06.x5.5
Fixed releases:
No fixed releases provided.
Description:
Symptoms
esxcli vsan debug object list の出力では名前空間間で移動された VMDKS が (Missing) になるため、実体なしまたは関連性なしのように見える。例：[root@vSAN-1:~] esxcli vsan debug object listObject UUID: 19b10b5d-48fd-733d-a2f0-005056263753Version: 7Health: healthyOwner: vSAN-1.gsslabs.orgSize: 10.00 GBUsed: 0.01 GBPolicy:CSN: 2stripeWidth: 1cacheReservation: 0proportionalCapacity: 0spbmProfileName: vSAN Default Storage PolicyforceProvisioning: 0spbmProfileId: aa6d5a82-1c88-45da-85d3-3d74b91a5badhostFailuresToTolerate: 1spbmProfileGenerationNumber: 0Type: vdiskPath: /vmfs/volumes/vsan:529e00851e70c3b9-215f67dee5e0391b/10b10b5d-3071-b7cb-a2be-005056263753/Virtual Machine 1.vmdk (Missing)Group UUID: 10b10b5d-3071-b7cb-a2be-005056263753Directory Name: N/A
Purpose
この記事の目的は、この動作が発生する方法の詳細な例と、ESXi の vSAN オブジェクト ツール、または objtool を使用して実行可能な修正方法を提供することです。
Cause
vSAN VMDK 記述子ファイルをある名前空間ディレクトリから別の名前空間ディレクトリに移動する場合、オブジェクト パス属性は自動的に更新されません。デフォルトでは、vSAN は VMDK 記述子ファイルをある名前空間から別の名前空間に移動しません。これは製品の予想される動作です。vSAN オブジェクトの オブジェクト パス属性は、現在使用可能な自動化された方法を使用せずに明示的に更新する必要があります。
Resolution
現在、vSAN は名前空間ディレクトリ間で VMDK 記述子ファイルを移動しないため、この動作を防ぐメカニズムはありません。ただし、名前空間間でファイルを移動する必要があるのは比較的まれなシナリオです。
Workaround
「Related Information」の章の手順 5 を参照してください。
Related Information
この動作は、vSphere Client ユーザー インターフェイスの Datastore Browser を使用して VMDK 記述子ファイルを手動で移動する場合、ESXi のコマンド ライン インターフェイスで「mv」コマンドを使用する場合、および MoveDatastoreFile_Task などの vSphere API を使用して VMDKS を移動する場合に再現できます。以下のシナリオ例では、2 台の仮想マシンの例を使用して、この動作を再現および修正するプロセスを説明します。仮想マシン 1 および 2 -「仮想マシン 1」のパス：/vmfs/volumes/vsan:529e00851e70c3b9-215f67dee5e0391b/10b10b5d-3071-b7cb-a2be-005056263753「仮想マシン 2」のパス：/vmfs/volumes/vsan:529e00851e70c3b9-215f67dee5e0391b/6fb10b5d-5bd1-f2aa-219a-0050562637531.最初に、単に cat コマンドを実行して、VMDK 記述子ファイルを出力し「Virtual Machine 1.vmdk」のオブジェクト UUID を取得します - [root@vSAN-1:~] cat "/vmfs/volumes/vsan:529e00851e70c3b9-215f67dee5e0391b/6fb10b5d-5bd1-f2aa-219a-005056263753/Virtual Machine 1.vmdk"# ディスクの記述子ファイルversion=4encoding="UTF-8"CID=fffffffeparentCID=ffffffffcreateType="vmfs"# エクステントの記述RW 20971520 VMFS "vsan://19b10b5d-48fd-733d-a2f0-005056263753"# ディスク データベース#DDBddb.adapterType = "lsilogic"ddb.geometry.cylinders = "1305"ddb.geometry.heads = "255"ddb.geometry.sectors = "63"ddb.longContentID = "0046fa2bcb13ce19e6ba05cffffffffe"ddb.thinProvisioned = "1"ddb.uuid = "60 00 C2 92 46 38 6d 04-ae 07 eb 8b a2 fe af 7a"ddb.virtualHWVersion = "14"2.次に、「mv」コマンドを使用して「Virtual Machine 1.vmdk」を仮想マシン 2 のディレクトリに移動できます - [root@vSAN-1:~] mv "/vmfs/volumes/vsanDatastore/10b10b5d-3071-b7cb-a2be-005056263753/Virtual Machine 1.vmdk" "/vmfs/volumes/vsanDatastore/6fb10b5d-5bd1-f2aa-219a-005056263753"3.vSphere Client ユーザー インターフェイスを使用して、「Virtual Machine 1.vmdk」を仮想マシン 2 にアタッチできます - 4.esxcli vsan debug object list の出力を確認すると、実際には存在している VMDK 記述子が (Missing) として報告されていることがわかります - [root@vSAN-1:~] esxcli vsan debug object listObject UUID: 19b10b5d-48fd-733d-a2f0-005056263753Version: 7Health: healthyOwner: vSAN-1.gsslabs.orgSize: 10.00 GBUsed: 0.01 GBPolicy:CSN: 2stripeWidth: 1cacheReservation: 0proportionalCapacity: 0spbmProfileName: vSAN Default Storage PolicyforceProvisioning: 0spbmProfileId: aa6d5a82-1c88-45da-85d3-3d74b91a5badhostFailuresToTolerate: 1spbmProfileGenerationNumber: 0Type: vdiskPath: /vmfs/volumes/vsan:529e00851e70c3b9-215f67dee5e0391b/10b10b5d-3071-b7cb-a2be-005056263753/Virtual Machine 1.vmdk (Missing)Group UUID: 10b10b5d-3071-b7cb-a2be-005056263753Directory Name: N/Aこれは、このオブジェクトのパス属性がまだ仮想マシン 1 の以前のディレクトリを参照しているためです。これは、「objtool getAttr」（オブジェクト ツールの属性取得）コマンドで確認できます - * コマンドの構文：/usr/lib/vmware/osfs/bin/objtool getAttr -u <Object UUID>[root@vSAN-1:~] /usr/lib/vmware/osfs/bin/objtool getAttr -u 19b10b5d-48fd-733d-a2f0-005056263753Object Attributes --UUID:19b10b5d-48fd-733d-a2f0-005056263753Object type:vsanObject size:10737418240User friendly name:(null)HA metadata:(null)Allocation type:ThinPolicy:((\"stripeWidth\" i1) (\"cacheReservation\" i0) (\"proportionalCapacity\" i0) (\"hostFailuresToTolerate\" i1) (\"forceProvisioning\" i0) (\"spbmProfileId\" \"aa6d5a82-1c88-45da-85d3-3d74b91a5bad\") (\"spbmProfileGenerationNumber\" l+0) (\"spbmProfileName\" \"vSAN Default Storage Policy\"))Object class: vdiskObject capabilities: NONEObject path: /vmfs/volumes/vsan:529e00851e70c3b9-215f67dee5e0391b/10b10b5d-3071-b7cb-a2be-005056263753/Virtual Machine 1.vmdkGroup uuid: 10b10b5d-3071-b7cb-a2be-005056263753Container uuid: (null)5.「objtool setAttr」（オブジェクト ツールの属性設定）コマンドを使用して、パス属性を更新する必要があります。* コマンドの構文：/usr/lib/vmware/osfs/bin/objtool setAttr -u <Object UUID> -d <Path to VMDK>[root@vSAN-1:~] /usr/lib/vmware/osfs/bin/objtool setAttr -u 19b10b5d-48fd-733d-a2f0-005056263753 -d "/vmfs/volumes/vsan:529e00851e70c3b9-215f67dee5e0391b/6fb10b5d-5bd1-f2aa-219a-005056263753/Virtual Machine 1.vmdk"Object set attribute succeededesxcli vsan debug object list を再実行すると、VMDK 記述子ファイルが (Missing) として報告されなくなったことがわかります -- [root@vSAN-1:~] esxcli vsan debug object listObject UUID: 19b10b5d-48fd-733d-a2f0-005056263753Version: 7Health: healthyOwner: vSAN-1.gsslabs.orgSize: 10.00 GBUsed: 0.01 GBPolicy:stripeWidth: 1spbmProfileGenerationNumber: 0cacheReservation: 0spbmProfileName: vSAN Default Storage PolicyforceProvisioning: 0proportionalCapacity: 0spbmProfileId: aa6d5a82-1c88-45da-85d3-3d74b91a5badhostFailuresToTolerate: 1CSN: 2Type: vdiskPath: /vmfs/volumes/vsan:529e00851e70c3b9-215f67dee5e0391b/6fb10b5d-5bd1-f2aa-219a-005056263753/Virtual Machine 1.vmdk (Exists)Group UUID: 10b10b5d-3071-b7cb-a2be-005056263753Directory Name: N/A
