I've checked my "Other" objects under "Virtual Objects" and I see a multiple orphans objects, I guess these are "DOM" objects in the vSAN database.
I followed https://www.virtuallyghetto.com/2017/11/translating-vsan-vm-object-ids-uuid-to-vm-and-vm-to-uuid.htm... and run the Python health check script. I was able to identify the following entries and the UUID and paths:
Object: ad1a7259-6765-a6e1-f342-246e963c74a8 - Type: vdisk
Path: /vmfs/volumes/vsan:5208d5c6f81944d9-8520459c09710020/aa1a7259-b4f2-55c6-ecf2-246e963c74a8/8a949a26-5e95-4ce1-b358-92ae23b138a7-dh-vhost00.******-0.vmdk
Object: ad1a7259-1a3d-c1f9-2cbf-246e963e72f0 - Type: vdisk
Path: /vmfs/volumes/vsan:5208d5c6f81944d9-8520459c09710020/ab1a7259-3c21-e8ce-5a61-246e963e72f0/8a949a26-5e95-4ce1-b358-92ae23b138a7-dh-vhost01.******-0.vmdk
bject: ad1a7259-6765-a6e1-f342-246e963c74a8 - Type: vdisk
Path: /vmfs/volumes/vsan:5208d5c6f81944d9-8520459c09710020/aa1a7259-b4f2-55c6-ecf2-246e963c74a8/8a949a26-5e95-4ce1-b358-92ae23b138a7-dh-vhost00.******-0.vmdk
dh-vhost***** -> host names
I checked the datastore, none of these files exist. I think it is some sort of leftover in the DB....? How can I clean it up? Is this anything to worry about?
Hello Mario,
+----------------------------------------------------------------------------------------------------------+---------+---------------------------+
| Unassociated objects | | |
| d6107259-8e9b-9dc1-9e10-246e963c74a8 < valid vSAN StatsDB | | 3/3 |
| aa1a7259-b4f2-55c6-ecf2-246e963c74a8 < namespace AKA vsan-loadtest-debug-8a949a26-5e95-4ce1-b358-92ae23b138a7-dh-vhost00***** | 3/3 |
| ad1a7259-6765-a6e1-f342-246e963c74a8 < vmdk AKA vmdk '8a949a26-5e95-4ce1-b358-92ae23b138a7-dh-vhost00*****-0.vmdk' | 11/11 |
| ad1a7259-1a3d-c1f9-2cbf-246e963e72f0 < vmdk AKA 8a949a26-5e95-4ce1-b358-92ae23b138a7-dh-vhost01*****-0.vmdk | 11/11 |
| 2c1f6a5a-6799-bcfb-19d4-246e963c74a8 < valid VM - .vswp file | | 3/3 |
+----------------------------------------------------------------------------------------------------------+---------+---------------------------+
As I was saying - you can likely fully remove 'ad1a7259-6765-a6e1-f342-246e963c74a8' AKA '8a949a26-5e95-4ce1-b358-92ae23b138a7-dh-vhost00*****-0.vmdk' by using delete in the datastore browser and the namespace Object (aa1a7259-b4f2-55c6-ecf2-246e963c74a) also, do this after removing the vmdk Object.
It is possible to delete any using Objects using Objtool delete, including 'vdisk' Objects that exist on vsandatastore but are not (currently) associated with a .vmdk descriptor nor namespace (perhaps this was removed before the vdisk was fully removed) - this is of course permanent and irreversible so make sure you are using the correct Object UUIDs (ad1a7259-1a3d-c1f9-2cbf-246e963e72f0 here).
Bob
Hello marnow,
Just for clarity: a DOM-Object refers to any vSAN Object e.g. those stored as Objects on vSAN - .vmdk (or snapshot .vmdk), .vswp or Namespace-Object (the VM 'folder') and less typically a few special Objects that I won't go into here.
You will notice that all of these Objects you list are not stored directly under vSAN namespace Object but in sub-directories of these.
e.g. a normal vSAN .vmdk Object would be stored as so:
/vmfs/volumes/vsan:5208d5c6f81944d9-8520459c09710020/aa1a7259-b4f2-55c6-ecf2-246e963c74a8/NameOfVM.vmdk
These are in sub-directories:
/vmfs/volumes/vsan:5208d5c6f81944d9-8520459c09710020/aa1a7259-b4f2-55c6-ecf2-246e963c74a8/8a949a26-5e95-4ce1-b358-92ae23b138a7-dh-vhost00.******-0.vmdk
Where aa1a7259-b4f2-55c6-ecf2-246e963c74a8 is the UUID of the vSAN Namespace-object - you will notice if you change directory into the 'name-of-VM' folder in the vsandatastore that this is actually just a symlink and the directory is actually 'aa1a7259-b4f2-55c6-ecf2-246e963c74a8' not 'NameOfVM' (use pwd for example).
This comes in handy when using things like the vsan-health-status.pyc, cmmds-tools or vsan.object_info (in RVC) to correlate for example all disks and Objects associated with a particular VM - they will a) have the namespace UUID in their path and b) have the corresponding namespace listed as their 'GroupUUID'.
Anyway, Objects that are not stored directly in the namespace Objects but in sub-directories (as you have here) often can not be detected by vSAN as being correlated with the vSAN namespace as they are not stored directly in this and thus Storage Polices may not be applied to them correctly - I have noted this previously with Objects from XenDesktop and (some older IIRC) View implementations where Objects are deployed in sub-directories.
"I checked the datastore, none of these files exist. I think it is some sort of leftover in the DB....? How can I clean it up? Is this anything to worry about?"
The first step should be to find out where these are located by looking at the namespace Objects these are placed in (but 1 level down), this may make more sense of the situation as you can see what other files are there and figure out what created these (as something surely did!).
e.g.:
# /usr/lib/vmware/osfs/bin/objtool getAttr -u aa1a7259-b4f2-55c6-ecf2-246e963c74a8
or via RVC:
#vsan.object_info -u aa1a7259-b4f2-55c6-ecf2-246e963c74a8 <Path_To_Cluster>
At first I thought they might have been Objects created during VM-Creation or Performance testing but I don't think the naming syntax matches.
Happy Object hunting :smileygrin:
Bob
Bob,
First, Thank you for the explanation and help! After all the hunt, everything points me to the leftover after load testing in last year.....I have directory
vsan-loadtest-debug-8a949a26-5e95-4ce1-b358-92ae23b138a7-dh-vhost00.*****.edu
with these objects inside
drwxr-xr-t 1 root root 1540 Jul 21 2017 .
drwxr-xr-x 1 root root 512 Jan 26 15:28 ..
-rw------- 1 root root 0 Jul 21 2017 .ad1a7259-6765-a6e1-f342-246e963c74a8.lck
-r-------- 1 root root 1441792 Jul 21 2017 .fbb.sf
-r-------- 1 root root 267026432 Jul 21 2017 .fdc.sf
-r-------- 1 root root 1179648 Jul 21 2017 .pb2.sf
-r-------- 1 root root 268435456 Jul 21 2017 .pbc.sf
-r-------- 1 root root 262733824 Jul 21 2017 .sbc.sf
drwx------ 1 root root 280 Jul 21 2017 .sdd.sf
-r-------- 1 root root 4194304 Jul 21 2017 .vh.sf
-rw------- 1 root root 525 Jul 21 2017 8a949a26-5e95-4ce1-b358-92ae23b138a7-dh-vhost00.sys.oakland.edu-0.vmdk
so all the entries refers through different namespaces to it....the question is, can I just delete the directory to clean it up or I have to do something else to remove the references?
***********************************************
Below all queries and outputs:
> vsan.obj_status_report /localhost/OU-*****-VSAN/computers/*****-VSAN-Prod -t
+----------------------------------------------------------------------------------------------------------+---------+---------------------------+
| Unassociated objects | | |
| d6107259-8e9b-9dc1-9e10-246e963c74a8 < valid vSAN StatsDB | | 3/3 |
| aa1a7259-b4f2-55c6-ecf2-246e963c74a8 | | 3/3 |
| ad1a7259-6765-a6e1-f342-246e963c74a8 | | 11/11 |
| ad1a7259-1a3d-c1f9-2cbf-246e963e72f0 | | 11/11 |
| 2c1f6a5a-6799-bcfb-19d4-246e963c74a8 < valid VM - .vsap file | | 3/3 |
+----------------------------------------------------------------------------------------------------------+---------+---------------------------+
-------------------------
/localhost/OU-*****-VSAN/computers> vsan.object_info 1 aa1a7259-b4f2-55c6-ecf2-246e963c74a8
DOM Object: aa1a7259-b4f2-55c6-ecf2-246e963c74a8 (v5, owner: nfh-vhost02*****, proxy owner: None, policy: hostFailuresToTolerate = 1, SCSN = 1449, CSN = 1452)
RAID_1
Component: 1e2de659-cb6e-aadd-37ef-246e963e72f0 (state: ACTIVE (5), host: nfh-vhost02*****, md: naa.55cd2e414d934879, ssd: naa.55cd2e414d8e6a6d,
votes: 1, usage: 0.3 GB, proxy component: false)
Component: ad08115a-244c-8cd0-7e1b-246e963e1948 (state: ACTIVE (5), host: dh-vhost00*****, md: naa.55cd2e414d936b0d, ssd: naa.55cd2e414d8e806a,
votes: 1, usage: 0.3 GB, proxy component: false)
Witness: ad08115a-c308-8fd0-f9fd-246e963e1948 (state: ACTIVE (5), host: odh-vhost00*****, md: naa.5002303100cc84e8, ssd: naa.5002303100cc84d6,
votes: 1, usage: 0.0 GB, proxy component: false)
Extended attributes:
Address space: 273804165120B (255.00 GB)
Object class: vmnamespace
Object path: /vmfs/volumes/vsan:5208d5c6f81944d9-8520459c09710020/
Object capabilities: NONE
----------------------------
/localhost/OU-*****-VSAN/computers> vsan.object_info 1 ad1a7259-6765-a6e1-f342-246e963c74a8
DOM Object: ad1a7259-6765-a6e1-f342-246e963c74a8 (v5, owner: nfh-vhost00*****, proxy owner: None, policy: CSN = 2891, spbmProfileId = aa6d5a82-1c88-45da-85d3-3d74b91a5bad, proportionalCapacity = 0, hostFailuresToTolerate = 1, spbmProfileGenerationNumber = 0, spbmProfileName = Virtual SAN Default Storage Policy, cacheReservation = 0, stripeWidth = 1, SCSN = 6051, forceProvisioning = 0)
RAID_1
RAID_0
Component: f26ba059-4f1b-4c64-aaff-246e963c74a8 (state: ACTIVE (5), host: nfh-vhost00*****, md: naa.55cd2e414d8968ba, ssd: naa.55cd2e414d8e6a88,
votes: 1, usage: 0.0 GB, proxy component: false)
Component: f26ba059-8afd-4e64-3ff8-246e963c74a8 (state: ACTIVE (5), host: nfh-vhost01*****, md: naa.55cd2e414d935c42, ssd: naa.55cd2e414d8e79c9,
votes: 1, usage: 0.0 GB, proxy component: false)
Component: 2e72a059-5efa-b6ac-c951-246e963c74a8 (state: ACTIVE (5), host: nfh-vhost00*****, md: naa.55cd2e414d86f90d, ssd: naa.55cd2e414d8e6b14,
votes: 1, usage: 0.0 GB, proxy component: false)
Component: 202de659-3c69-21e9-0513-246e963e7fd8 (state: ACTIVE (5), host: nfh-vhost02*****, md: naa.55cd2e414d936c81, ssd: naa.55cd2e414d8e6b2b,
votes: 1, usage: 0.0 GB, proxy component: false)
Component: 6128e659-f191-596f-fbca-246e963e7fd8 (state: ACTIVE (5), host: nfh-vhost01*****, md: naa.55cd2e414d934041, ssd: naa.55cd2e414d8e79c9,
votes: 1, usage: 0.0 GB, proxy component: false)
RAID_0
Component: 4f87a059-d34a-7229-653d-246e963c74a8 (state: ACTIVE (5), host: dh-vhost02*****, md: naa.55cd2e414d873e3d, ssd: naa.55cd2e414d8e6b25,
votes: 1, usage: 0.0 GB, proxy component: false)
Component: 4f87a059-2ef8-7529-0fdd-246e963c74a8 (state: ACTIVE (5), host: dh-vhost02*****, md: naa.55cd2e414d8968d5, ssd: naa.55cd2e414d8e8087,
votes: 1, usage: 0.0 GB, proxy component: false)
Component: 9f25f759-3078-af37-f1a8-246e963e1948 (state: ACTIVE (5), host: dh-vhost00*****, md: naa.55cd2e414d91067f, ssd: naa.55cd2e414d8e806a,
votes: 1, usage: 0.0 GB, proxy component: false)
Component: e188a059-551c-060e-04b4-246e963c74a8 (state: ACTIVE (5), host: dh-vhost02*****, md: naa.55cd2e414d86bd82, ssd: naa.55cd2e414d8e7e71,
votes: 1, usage: 0.0 GB, proxy component: false)
Component: 768aa059-ead3-6a7f-6d6f-246e963c74a8 (state: ACTIVE (5), host: dh-vhost02*****, md: naa.55cd2e414d896170, ssd: naa.55cd2e414d8e7e71,
votes: 1, usage: 0.0 GB, proxy component: false)
Witness: a925f759-0a06-b352-d7d7-246e963e1948 (state: ACTIVE (5), host: odh-vhost00*****, md: naa.5002303100cc84e8, ssd: naa.5002303100cc84d6,
votes: 5, usage: 0.0 GB, proxy component: false)
Extended attributes:
Address space: 1099511627776B (1024.00 GB)
Object class: vdisk
Object path: /vmfs/volumes/vsan:5208d5c6f81944d9-8520459c09710020/aa1a7259-b4f2-55c6-ecf2-246e963c74a8/8a949a26-5e95-4ce1-b358-92ae23b138a7-dh-vhost00*****-0.vmdk
Object capabilities: NONE
----------------------------
/localhost/OU-*****-VSAN/computers> vsan.object_info 1 ad1a7259-1a3d-c1f9-2cbf-246e963e72f0
DOM Object: ad1a7259-1a3d-c1f9-2cbf-246e963e72f0 (v5, owner: dh-vhost01*****, proxy owner: None, policy: cacheReservation = 0, stripeWidth = 1, SCSN = 8424, CSN = 2831, proportionalCapacity = 0, spbmProfileId = aa6d5a82-1c88-45da-85d3-3d74b91a5bad, forceProvisioning = 0, hostFailuresToTolerate = 1, spbmProfileName = Virtual SAN Default Storage Policy, spbmProfileGenerationNumber = 0)
RAID_1
RAID_0
Component: 6628e659-cc00-99e1-ebc8-246e963c74a8 (state: ACTIVE (5), host: nfh-vhost00*****, md: naa.55cd2e414d89616d, ssd: naa.55cd2e414d8e6a88,
votes: 1, usage: 0.0 GB, proxy component: false)
Component: 9210c059-59c7-d452-2000-246e963e19d8 (state: ACTIVE (5), host: nfh-vhost01*****, md: naa.55cd2e414d936a87, ssd: naa.55cd2e414d8e7f7a,
votes: 1, usage: 0.0 GB, proxy component: false)
Component: 9210c059-761a-d652-db40-246e963e19d8 (state: ACTIVE (5), host: nfh-vhost01*****, md: naa.55cd2e414d935582, ssd: naa.55cd2e414d8e78e4,
votes: 1, usage: 0.0 GB, proxy component: false)
Component: 252de659-7803-bd49-ce90-246e963c74a8 (state: ACTIVE (5), host: nfh-vhost02*****, md: naa.55cd2e414d936d22, ssd: naa.55cd2e414d8e6af7,
votes: 1, usage: 0.0 GB, proxy component: false)
Component: f26ba059-8aad-2ac6-2e53-246e963e7450 (state: ACTIVE (5), host: nfh-vhost01*****, md: naa.55cd2e414d9106fc, ssd: naa.55cd2e414d8e7f7a,
votes: 1, usage: 0.0 GB, proxy component: false)
RAID_0
Component: a985a059-aff7-3198-1dc3-246e963e7450 (state: ACTIVE (5), host: dh-vhost02*****, md: naa.55cd2e414d896524, ssd: naa.55cd2e414d8e7e71,
votes: 1, usage: 0.0 GB, proxy component: false)
Component: 8d00115a-1371-f999-8ccb-246e963e7450 (state: ACTIVE (5), host: dh-vhost00*****, md: naa.55cd2e414d936b4b, ssd: naa.55cd2e414d8e7e9a,
votes: 1, usage: 0.0 GB, proxy component: false)
Component: 758aa059-8535-9dc7-14bb-246e963e7450 (state: ACTIVE (5), host: dh-vhost02*****, md: naa.55cd2e414d871189, ssd: naa.55cd2e414d8e8087,
votes: 1, usage: 0.0 GB, proxy component: false)
Component: 8d00115a-99ee-fc99-722c-246e963e7450 (state: ACTIVE (5), host: dh-vhost01*****, md: naa.55cd2e414d910708, ssd: naa.55cd2e414d8e804b,
votes: 1, usage: 0.0 GB, proxy component: false)
Component: bc08115a-3f4a-63f6-5fc7-246e963e7450 (state: ACTIVE (5), host: dh-vhost02*****, md: naa.55cd2e414d86bdc1, ssd: naa.55cd2e414d8e7e71,
votes: 1, usage: 0.0 GB, proxy component: false)
Witness: bc08115a-65be-66f6-4278-246e963e7450 (state: ACTIVE (5), host: odh-vhost00*****, md: naa.5002303100cc84e8, ssd: naa.5002303100cc84d6,
votes: 5, usage: 0.0 GB, proxy component: false)
Extended attributes:
Address space: 1099511627776B (1024.00 GB)
Object class: vdisk
Object path: /vmfs/volumes/vsan:5208d5c6f81944d9-8520459c09710020/ab1a7259-3c21-e8ce-5a61-246e963e72f0/8a949a26-5e95-4ce1-b358-92ae23b138a7-dh-vhost01*****-0.vmdk
Object capabilities: NONE
----------------------------
/localhost/OU-*****-VSAN/computers> vsan.object_info 1 2c1f6a5a-6799-bcfb-19d4-246e963c74a8
DOM Object: 2c1f6a5a-6799-bcfb-19d4-246e963c74a8 (v5, owner: dh-vhost00*****, proxy owner: None, policy: proportionalCapacity = 100, hostFailuresToTolerate = 1, CSN = 2, forceProvisioning = 1)
RAID_1
Component: 2c1f6a5a-90c0-6cfd-7bc0-246e963c74a8 (state: ACTIVE (5), host: nfh-vhost03*****, md: naa.55cd2e414d935bd7, ssd: naa.55cd2e414d8e6b10,
votes: 1, usage: 32.6 GB, proxy component: false)
Component: 2c1f6a5a-4a5a-6efd-d6e5-246e963c74a8 (state: ACTIVE (5), host: dh-vhost02*****, md: naa.55cd2e414d86bd82, ssd: naa.55cd2e414d8e7e71,
votes: 1, usage: 32.6 GB, proxy component: false)
Witness: 2c1f6a5a-4e7c-6ffd-43c8-246e963c74a8 (state: ACTIVE (5), host: odh-vhost00*****, md: naa.5002303100cc84e8, ssd: naa.5002303100cc84d6,
votes: 1, usage: 0.0 GB, proxy component: false)
Extended attributes:
Address space: 34359738368B (32.00 GB)
Object class: vmswap
Object path: /vmfs/volumes/vsan:5208d5c6f81944d9-8520459c09710020/54fa695a-234a-49f1-8e9d-246e963e7fd8/airwave.net-f2b5bdbe.vswp
Object capabilities: NONE
----------------------------
/usr/lib/vmware/osfs/bin/objtool getAttr -u aa1a7259-b4f2-55c6-ecf2-246e963c74a8
Object Attributes --
UUID:aa1a7259-b4f2-55c6-ecf2-246e963c74a8
Object type:vsan
Object size:273804165120
User friendly name:vsan-loadtest-debug-8a949a26-5e95-4ce1-b358-92ae23b138a7-dh-vhost00*****
HA metadata:(null)
Allocation type:Thick
Policy:((\"hostFailuresToTolerate\" i1))
Object class: vmnamespace
Object capabilities: NONE
Object path: /vmfs/volumes/vsan:5208d5c6f81944d9-8520459c09710020/
Group uuid: 00000000-0000-0000-0000-000000000000
----------------------------
/usr/lib/vmware/osfs/bin/objtool getAttr -u ad1a7259-6765-a6e1-f342-246e963c74a8
Object Attributes --
UUID:ad1a7259-6765-a6e1-f342-246e963c74a8
Object type:vsan
Object size:1099511627776
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\" \"Virtual SAN Default Storage Policy\"))
Object class: vdisk
Object capabilities: NONE
Object path: /vmfs/volumes/vsan:5208d5c6f81944d9-8520459c09710020/aa1a7259-b4f2-55c6-ecf2-246e963c74a8/8a949a26-5e95-4ce1-b358-92ae23b138a7-dh-vhost00*****-0.vmdk
Group uuid: aa1a7259-b4f2-55c6-ecf2-246e963c74a8
----------------------------
/usr/lib/vmware/osfs/bin/objtool getAttr -u ad1a7259-1a3d-c1f9-2cbf-246e963e72f0
Object Attributes --
UUID:ad1a7259-1a3d-c1f9-2cbf-246e963e72f0
Object type:vsan
Object size:1099511627776
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\" \"Virtual SAN Default Storage Policy\"))
Object class: vdisk
Object capabilities: NONE
Object path: /vmfs/volumes/vsan:5208d5c6f81944d9-8520459c09710020/ab1a7259-3c21-e8ce-5a61-246e963e72f0/8a949a26-5e95-4ce1-b358-92ae23b138a7-dh-vhost01*****-0.vmdk
Group uuid: ab1a7259-3c21-e8ce-5a61-246e963e72f0
----------------------------
/usr/lib/vmware/osfs/bin/objtool getAttr -u 2c1f6a5a-6799-bcfb-19d4-246e963c74a8
Object Attributes --
UUID:2c1f6a5a-6799-bcfb-19d4-246e963c74a8
Object type:vsan
Object size:34359738368
User friendly name:(null)
HA metadata:(null)
Allocation type:Zeroed thick
Policy:((\"proportionalCapacity\" i0) (\"hostFailuresToTolerate\" i1) (\"forceProvisioning\" i1))
Object class: vmswap
Object capabilities: NONE
Object path: /vmfs/volumes/vsan:5208d5c6f81944d9-8520459c09710020/54fa695a-234a-49f1-8e9d-246e963e7fd8/airwave.net-f2b5bdbe.vswp
Group uuid: 54fa695a-234a-49f1-8e9d-246e963e7fd8
----------------------------
[root@nfh-vhost03:/vmfs/volumes/vsan:5208d5c6f81944d9-8520459c09710020/aa1a7259-b4f2-55c6-ecf2-246e963c74a8] ls -la
total 790528
drwxr-xr-t 1 root root 1540 Jul 21 2017 .
drwxr-xr-x 1 root root 512 Jan 26 15:07 ..
-rw------- 1 root root 0 Jul 21 2017 .ad1a7259-6765-a6e1-f342-246e963c74a8.lck
-r-------- 1 root root 1441792 Jul 21 2017 .fbb.sf
-r-------- 1 root root 267026432 Jul 21 2017 .fdc.sf
-r-------- 1 root root 1179648 Jul 21 2017 .pb2.sf
-r-------- 1 root root 268435456 Jul 21 2017 .pbc.sf
-r-------- 1 root root 262733824 Jul 21 2017 .sbc.sf
drwx------ 1 root root 280 Jul 21 2017 .sdd.sf
-r-------- 1 root root 4194304 Jul 21 2017 .vh.sf
-rw------- 1 root root 525 Jul 21 2017 8a949a26-5e95-4ce1-b358-92ae23b138a7-dh-vhost00*****-0.vmdk
Mario
Hello Mario,
I stand corrected, they are Proactive test Objects (other than that .vswp), I thought remembered from before that these had some specific format name after UUID-portion but I checked my notes from a previous case and their names end as yours do (referencing the hosts created on).
(BTW you left one reference in your last comment without *****)
As I was saying, find a friendly name and it should make more sense e.g. 'vsan-loadtest-debug' here.
Objects created during Proactive test are intended to be automatically cleaned up but there are a number of reasons why this process might fail (e.g. temporary partition of cluster or a host losing connection to vCenter briefly), all these Objects appear to be healthy so they should be easy to delete.
So, a vmdk on vSAN is just a descriptor that points to the vSAN Object (instead of pointing to a -flat.vmdk as they do on VMFS)
You should be able to remove these Objects relatively easy as they appear to be healthy via datastore browser and delete the vmdks (which *should* delete the backing vSAN Object), however if you say used 'rm' via CLI this would not remove the backing vSAN Object. You can check after if the Objects still exist of course.
I don't think removing folder that they reside in will remove backing vSAN Objects.
If the above doesn't work I can let you know a more sure-fire method of removal.
I can see the aa1a7259-b4f2-55c6-ecf2-246e963c74a8 namespace of some vmdk Objects, but do not see the namespace of
/vmfs/volumes/vsan:5208d5c6f81944d9-8520459c09710020/ab1a7259-3c21-e8ce-5a61-246e963e72f0/8a949a26-5e95-4ce1-b358-92ae23b138a7-dh-vhost01*****-0.vmdk
(e.g. ab1a7259-3c21-e8ce-5a61-246e963e72f0), is this accessible?
Bob
ab1a7259-3c21-e8ce-5a61-246e963e72f0 is not accessible, no-exist.....
[root@nfh-vhost03:/vmfs/volumes/vsan:5208d5c6f81944d9-8520459c09710020] cd ab1a7259-3c21-e8ce-5a61-246e963e72f0
-sh: cd: can't cd to ab1a7259-3c21-e8ce-5a61-246e963e72f0
I see only these in file browser as well:
Hello Mario,
+----------------------------------------------------------------------------------------------------------+---------+---------------------------+
| Unassociated objects | | |
| d6107259-8e9b-9dc1-9e10-246e963c74a8 < valid vSAN StatsDB | | 3/3 |
| aa1a7259-b4f2-55c6-ecf2-246e963c74a8 < namespace AKA vsan-loadtest-debug-8a949a26-5e95-4ce1-b358-92ae23b138a7-dh-vhost00***** | 3/3 |
| ad1a7259-6765-a6e1-f342-246e963c74a8 < vmdk AKA vmdk '8a949a26-5e95-4ce1-b358-92ae23b138a7-dh-vhost00*****-0.vmdk' | 11/11 |
| ad1a7259-1a3d-c1f9-2cbf-246e963e72f0 < vmdk AKA 8a949a26-5e95-4ce1-b358-92ae23b138a7-dh-vhost01*****-0.vmdk | 11/11 |
| 2c1f6a5a-6799-bcfb-19d4-246e963c74a8 < valid VM - .vswp file | | 3/3 |
+----------------------------------------------------------------------------------------------------------+---------+---------------------------+
As I was saying - you can likely fully remove 'ad1a7259-6765-a6e1-f342-246e963c74a8' AKA '8a949a26-5e95-4ce1-b358-92ae23b138a7-dh-vhost00*****-0.vmdk' by using delete in the datastore browser and the namespace Object (aa1a7259-b4f2-55c6-ecf2-246e963c74a) also, do this after removing the vmdk Object.
It is possible to delete any using Objects using Objtool delete, including 'vdisk' Objects that exist on vsandatastore but are not (currently) associated with a .vmdk descriptor nor namespace (perhaps this was removed before the vdisk was fully removed) - this is of course permanent and irreversible so make sure you are using the correct Object UUIDs (ad1a7259-1a3d-c1f9-2cbf-246e963e72f0 here).
Bob
Dear all,
Thanks for the post!
There is any command to delete all my Virtual Objects tagged as "unknow object type".
My issues : My cloud foundry is using a CPI to create a virtual Machine but my collegue have decided to remove the VM manually, so all object are still there but not "unassociated"
I can use "objtool delete..." but I have more than 11000 objects to delete"...
many thanks for your help