ある名前空間フォルダから別の名前空間フォルダに vSAN VMDKS を移動しても、オブジェクトパス属性が更新されない

search cancel

ある名前空間フォルダから別の名前空間フォルダに vSAN VMDKS を移動しても、オブジェクトパス属性が更新されない

book

Article ID: 320833

calendar_today

Updated On:

Products

VMware vSAN

Issue/Introduction

免責事項：これは英文の記事「Moving vSAN VMDKS from one Namespace Folder to another does not update the Object Path Attribute (315539)」の日本語訳です。
記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。最新情報は英語版の記事で参照してください。

この記事の目的は、この動作が発生する方法の詳細な例と、ESXi の vSAN オブジェクトツール、または objtool を使用して実行可能な修正方法を提供することです。

Symptoms:
esxcli vsan debug object list の出力では名前空間間で移動された VMDKS が (Missing) になるため、実体なしまたは関連性なしのように見える。

例：

[root@vSAN-1:~] esxcli vsan debug object list
Object UUID: 19b10b5d-48fd-733d-a2f0-############
Version: 7
Health: healthy
Owner: vSAN-1.gsslabs.org
Size: 10.00 GB
Used: 0.01 GB
Policy:
CSN: 2
stripeWidth: 1
cacheReservation: 0
proportionalCapacity: 0
spbmProfileName: vSAN Default Storage Policy
forceProvisioning: 0
spbmProfileId: aa6d5a82-1c88-45da-85d3-############
hostFailuresToTolerate: 1
spbmProfileGenerationNumber: 0

Type: vdisk
Path: /vmfs/volumes/vsan:529e00851e70c3b9-215f############/10b10b5d-3071-b7cb-a2be-############/Virtual Machine 1.vmdk (Missing)
Group UUID: 10b10b5d-3071-b7cb-a2be-############
Directory Name: N/A

Environment

VMware vSAN (All Versions)

Cause

vSAN VMDK 記述子ファイルをある名前空間ディレクトリから別の名前空間ディレクトリに移動する場合、オブジェクトパス属性は自動的に更新されません。

デフォルトでは、vSAN は VMDK 記述子ファイルをある名前空間から別の名前空間に移動しません。

これは製品の予想される動作です。vSAN オブジェクトのオブジェクトパス属性は、現在使用可能な自動化された方法を使用せずに明示的に更新する必要があります。

Resolution

現在、vSAN は名前空間ディレクトリ間で VMDK 記述子ファイルを移動しないため、この動作を防ぐメカニズムはありません。ただし、名前空間間でファイルを移動する必要があるのは比較的まれなシナリオです。

Workaround:
「Additional Information」セクションの手順 5 を参照してください。

Additional Information

この動作は、vSphere Client ユーザーインターフェイスの Datastore Browser を使用して VMDK 記述子ファイルを手動で移動する場合、ESXi のコマンドラインインターフェイスで「mv」コマンドを使用する場合、および MoveDatastoreFile_Task などの vSphere API を使用して VMDKS を移動する場合に再現できます。

以下のシナリオ例では、2 台の仮想マシンの例を使用して、この動作を再現および修正するプロセスを説明します。仮想マシン 1 および 2 :

「仮想マシン 1」のパス：/vmfs/volumes/vsan:529e00851e70c3b9-215f############/10b10b5d-3071-b7cb-a2be-############

「仮想マシン 2」のパス：/vmfs/volumes/vsan:529e00851e70c3b9-215f############/6fb10b5d-5bd1-f2aa-219a-############

最初に、単に cat コマンドを実行して、VMDK 記述子ファイルを出力し「Virtual Machine 1.vmdk」のオブジェクト UUID を取得します -

[root@vSAN-1:~] grep RW "/vmfs/volumes/vsan:529e00851e70c3b9-215f############/10b10b5d-3071-b7cb-a2be-############/Virtual Machine 1.vmdk"
RW 20971520 VMFS "vsan://19b10b5d-48fd-733d-a2f0-############"
次に、「mv」コマンドを使用して「Virtual Machine 1.vmdk」を仮想マシン 2 のディレクトリに移動できます -

[root@vSAN-1:~] mv "/vmfs/volumes/vsanDatastore/10b10b5d-3071-b7cb-a2be-############/Virtual Machine 1.vmdk" "/vmfs/volumes/vsanDatastore/6fb10b5d-5bd1-f2aa-219a-############"
vSphere Client ユーザーインターフェイスを使用して、「Virtual Machine 1.vmdk」を仮想マシン 2 にアタッチできます:
esxcli vsan debug object list の出力を確認すると、実際には存在している VMDK 記述子が (Missing) として報告されていることがわかります:

[root@vSAN-1:~] esxcli vsan debug object list
Object UUID: 19b10b5d-48fd-733d-a2f0-############
Version: 7
Health: healthy
Owner: vSAN-1.gsslabs.org
Size: 10.00 GB
Used: 0.01 GB
Policy:
CSN: 2
stripeWidth: 1
cacheReservation: 0
proportionalCapacity: 0
spbmProfileName: vSAN Default Storage Policy
forceProvisioning: 0
spbmProfileId: aa6d5a82-1c88-45da-85d3-############
hostFailuresToTolerate: 1
spbmProfileGenerationNumber: 0

Type: vdisk
Path: /vmfs/volumes/vsan:529e00851e70c3b9-215f############/10b10b5d-3071-b7cb-a2be-############/Virtual Machine 1.vmdk (Missing)
Group UUID: 10b10b5d-3071-b7cb-a2be-############
Directory 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-############
Object Attributes --

UUID:19b10b5d-48fd-733d-a2f0-############

Object type:vsan

Object size:10737418240

User friendly name:(null)

HA metadata:(null)

Allocation type:Thin

Policy:((\"stripeWidth\" i1) (\"cacheReservation\" i0) (\"proportionalCapacity\" i0) (\"hostFailuresToTolerate\" i1) (\"forceProvisioning\" i0) (\"spbmProfileId\" \"aa6d5a82-1c88-45da-85d3-############\") (\"spbmProfileGenerationNumber\" l+0) (\"spbmProfileName\" \"vSAN Default Storage Policy\"))

Object class: vdisk

Object capabilities: NONE

Object path: /vmfs/volumes/vsan:529e00851e70c3b9-215f############/10b10b5d-3071-b7cb-a2be-############/Virtual Machine 1.vmdk

Group uuid: 10b10b5d-3071-b7cb-a2be-############

Container uuid: (null)
「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-############ -d "/vmfs/volumes/vsan:529e00851e70c3b9-215f67dee5e0391b/6fb10b5d-5bd1-f2aa-219a-############/Virtual Machine 1.vmdk"
Object set attribute succeeded

esxcli vsan debug object list を再実行すると、VMDK 記述子ファイルが (Missing) として報告されなくなったことがわかります --

[root@vSAN-1:~] esxcli vsan debug object list
Object UUID: 19b10b5d-48fd-733d-a2f0-############
Version: 7
Health: healthy
Owner: vSAN-1.gsslabs.org
Size: 10.00 GB
Used: 0.01 GB
Policy:
stripeWidth: 1
spbmProfileGenerationNumber: 0
cacheReservation: 0
spbmProfileName: vSAN Default Storage Policy
forceProvisioning: 0
proportionalCapacity: 0
spbmProfileId: aa6d5a82-1c88-45da-85d3-############
hostFailuresToTolerate: 1
CSN: 2

Type: vdisk
Path: /vmfs/volumes/vsan:529e00851e70c3b9-############/6fb10b5d-5bd1-f2aa-219a-############/Virtual Machine 1.vmdk (Exists)
Group UUID: 10b10b5d-3071-b7cb-a2be-############
Directory Name: N/A

注意：特定の vSAN バージョンで「esxcli vsan debug object list」を使用すると、100 オブジェクトしか表示されず、探しているオブジェクトが表示されないことがあります。
フラグ「--all」を追加する必要がありますが、これはホストの機能に影響を与える可能性があるため、コマンドを実行し、出力を txt ファイルに送信することをお勧めします。
ここでは、「esxcli vsan debug object list --all > /tmp/objects.txt 」とする。その後、特定のオブジェクトを検索するためにファイルを「less」することができます。
vSAN DOM オブジェクト UUID がわかっている場合は、次の構文を使用できます。
esxcli vsan debug object list -u <DOM Object UUID>

Feedback

thumb_up Yes

thumb_down No