Loading

×Sorry to interrupt
Uncaught ReferenceError: addCTracking is not defined
throws at https://kb.vmware.com/resource/KM_TealiumTrackingJS?v=0.5:100:1

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

Moving vSAN VMDKS from one Namespace Folder to another does not update the Object Path Attribute (70774)

Last Updated: 6/4/2023Categories: InformationalTotal Views: 13777Language:
Chinese (Simplified)JapaneseEnglish

4 like this article

Subscribe to get an email
newsletter with new updates

4 people found this helpful Please provide article feedback:

Symptoms

The output of esxcli vsan debug object list can give VMDKS that have been moved between Namespaces the appearance of being (Missing), thus making them seem Orphaned or Unassociated.

For example:

[root@vSAN-1:~] esxcli vsan debug object list
Object UUID: 19b10b5d-48fd-733d-a2f0-005056263753
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-3d74b91a5bad
hostFailuresToTolerate: 1
spbmProfileGenerationNumber: 0

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

Purpose

The purpose of this article is to provide a detailed example of how this behavior can occur, along with corrective measures available using ESXi's vSAN Object Tool, or objtool.

Cause

When moving vSAN VMDK Descriptor Files from one Namespace directory to a different Namespace directory, the Object Path Attribute is not automatically updated.

By default, vSAN does not move VMDK Descriptor Files from one Namespace to a different Namespace.

This is expected product behavior. The Object Path Attribute of vSAN Objects must be updated explicitly with no automated methods currently available.

Resolution

Currently there is no mechanism to prevent this behavior from happening as vSAN does not move VMDK Descriptor files between Namespace Directories. However, the need to move files between Namespaces should be a relatively rare scenario.

Workaround

See step 5 in the Related Information section.

Related Information

This behavior can be reproduced when VMDK Descriptor files are moved manually using the Datastore Browser in the vSphere Client UI, when using "mv" commands in ESXi's command line interface, and when VMDKS are moved using vSphere API's such as MoveDatastoreFile_Task.

In the example scenario below, we'll walk through the process of reproducing and correcting this behavior with two example Virtual Machines: "Virtual Machine 1" & "Virtual Machine 2":

"Virtual Machine 1" Path: /vmfs/volumes/vsan:529e00851e70c3b9-215f67dee5e0391b/10b10b5d-3071-b7cb-a2be-005056263753

"Virtual Machine 2" Path: /vmfs/volumes/vsan:529e00851e70c3b9-215f67dee5e0391b/6fb10b5d-5bd1-f2aa-219a-005056263753

1. First, we can obtain the Object UUID of "Virtual Machine 1.vmdk" by simply cat'ing the VMDK Descriptor file -

[root@vSAN-1:~] cat "/vmfs/volumes/vsan:529e00851e70c3b9-215f67dee5e0391b/10b10b5d-3071-b7cb-a2be-005056263753/Virtual Machine 1.vmdk"
# Disk DescriptorFile
version=4
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 20971520 VMFS "vsan://19b10b5d-48fd-733d-a2f0-005056263753"

# The Disk Data Base
#DDB

ddb.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. Next, we can move "Virtual Machine 1.vmdk" to Virtual Machine 2's Directory using a "mv" command:

[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. Using the vSphere Client UI, we can attach "Virtual Machine 1.vmdk" to Virtual Machine 2:

4. Reviewing the output of esxcli vsan debug object list, we can now see that the VMDK Descriptor is reported as (Missing), even though it still exists:

[root@vSAN-1:~] esxcli vsan debug object list
Object UUID: 19b10b5d-48fd-733d-a2f0-005056263753
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-3d74b91a5bad
hostFailuresToTolerate: 1
spbmProfileGenerationNumber: 0

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

This is because the Path Attribute for this Object still references the previous directory from Virtual Machine 1. This can be confirmed via an "objtool getAttr" (Object Tool Get Attribute) command:

* Command Syntax: /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-005056263753
Object Attributes --

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

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-3d74b91a5bad\") (\"spbmProfileGenerationNumber\" l+0) (\"spbmProfileName\" \"vSAN Default Storage Policy\"))

Object class: vdisk

Object capabilities: NONE

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

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

Container uuid: (null)

5. We must update the Path Attribute using an "objtool setAttr" (Object Tool Set Attribute) command.

* Command Syntax: /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 succeeded

Re-running esxcli vsan debug object list, we can now confirm the VMDK Descriptor File is no longer reported as (Missing):

[root@vSAN-1:~] esxcli vsan debug object list
Object UUID: 19b10b5d-48fd-733d-a2f0-005056263753
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-3d74b91a5bad
hostFailuresToTolerate: 1
CSN: 2

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

NOTE: When using  "esxcli vsan debug object list" in certain vSAN versions it shows only 100 Objects and it may happen that you don't see the one you are looking for. You will need to add the flag "--all" however, this could impact the host functionality so, it is recommended to run the command and send the output to a txt file. Here it is "esxcli vsan debug object list --all > /tmp/objects.txt". Then you can "less" the file to search for your specific object.
If the vSAN DOM Object UUID is known you can use the following syntax: esxcli vsan debug object list -u <DOM Object UUID>

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
Chinese (Simplified)JapaneseEnglish

Attachments

Additional Resources

KB
•
End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x) (2107518)

KB
•
Download and Install VMware Fusion (2014097)

Results 1-2 of 2

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware vSAN

Related Versions:

VMware vSAN 8.0.x

VMware vSAN 7.0.x

VMware vSAN 6.x

VMware vSAN 5.5.x

Take Our Survey

Support Assistant