VMware Cloud Community
AEGunnarsson
Contributor
Contributor
Jump to solution

Used Capacity Breakdown - Object Type - Other

In the vSan capacity overview there is an object type of "Other"

How/Where can I see what is in the object type others? I know what the help says about what the "other"  capacity is consumed by, but what I wold like to do is to dive deeper and see what objects it is and the size of each object. Anyone who know a way to list all the objects in other? (Please feel free to move this discussion to proper place)

Obejct type other.PNG

Regards, Andreas

Reply
0 Kudos
1 Solution

Accepted Solutions
TheBobkin
Champion
Champion
Jump to solution

Hello Andreas,

Welcome to Communities!

Can you validate whether these show as Unassociated Objects in RVC?

> vsan.obj_status_report -t <pathToCluster>

If they do then it would happen that I wrote a kb article specifically for this scenario:

VMware Knowledge Base

Bob

View solution in original post

Reply
0 Kudos
7 Replies
scott28tt
VMware Employee
VMware Employee
Jump to solution

Moderator: Moved to vSAN


-------------------------------------------------------------------------------------------------------------------------------------------------------------

Although I am a VMware employee I contribute to VMware Communities voluntarily (ie. not in any official capacity)
VMware Training & Certification blog
Reply
0 Kudos
scott28tt
VMware Employee
VMware Employee
Jump to solution

https://cormachogan.com/2016/02/25/vsan-6-2-part-7-capacity-views/


-------------------------------------------------------------------------------------------------------------------------------------------------------------

Although I am a VMware employee I contribute to VMware Communities voluntarily (ie. not in any official capacity)
VMware Training & Certification blog
Reply
0 Kudos
TheBobkin
Champion
Champion
Jump to solution

Hello Andreas,

Welcome to Communities!

Can you validate whether these show as Unassociated Objects in RVC?

> vsan.obj_status_report -t <pathToCluster>

If they do then it would happen that I wrote a kb article specifically for this scenario:

VMware Knowledge Base

Bob

Reply
0 Kudos
AEGunnarsson
Contributor
Contributor
Jump to solution

Hi Bon and thank you Smiley Happy

The "vsan.obj_status_report -t" resulted in a finding of 576 Unassociated Objects. However I'm not able to see the size of the files.

My guess is that the files will be only be around 2 TB and not close to the 175 TB that I'm trying to discover and map.

It there a way to see the sizes of the files?

Here is an example of the outcome of vsan.obj_status_report -t:

|    1318c15c-3450-6000-7d4d-b02628396580                                                                                                  |         | 3/3                       |

|    ea95c65c-aac7-fe00-6e73-b02628396c80                                                                                                  |         | 3/3                       |

|    a850ac5c-809d-ad01-9ad0-b02628397230                                                                                                  |         | 3/3                       |

|    1505c45d-860e-1d07-66cb-b026283974d0                                                                                                  |         | 3/3                       |

Regards, Andreas

Reply
0 Kudos
TheBobkin
Champion
Champion
Jump to solution

Hello Andreas,

As per the article, it is (for now) a 2-step process in that you get the Unassociated Object UUIDs from RVC to make a list to run Objtool against on a host to get the information about the Objects.

You can of course edit the grep output checked to include size of the Objects (which is in bytes) e.g. replace 'UUID|Object class|Object path' with 'UUID|Object size|Object class|Object path'

Bob

Reply
0 Kudos
AEGunnarsson
Contributor
Contributor
Jump to solution

Hi Bob, I ran vsan.object_info on one of the objects and got this result, could you please let me know what amount of data I shall calculate this object holds:

vsan.object_info computers/***********/ aa50b95d-2a42-c2fb-1c85-b02628396580

2020-01-21 13:18:32 +0100: Fetching vSAN disk info from ***********-ins.com (may take a moment) ...

2020-01-21 13:18:32 +0100: Fetching vSAN disk info from ***********ins.com (may take a moment) ...

2020-01-21 13:18:32 +0100: Fetching vSAN disk info from ***********ins.com (may take a moment) ...

2020-01-21 13:18:32 +0100: Fetching vSAN disk info from ***********ins.com (may take a moment) ...

2020-01-21 13:18:32 +0100: Fetching vSAN disk info from ***********ins.com (may take a moment) ...

2020-01-21 13:18:32 +0100: Fetching vSAN disk info from ***********ins.com (may take a moment) ...

2020-01-21 13:18:32 +0100: Fetching vSAN disk info from ***********ins.com (may take a moment) ...

2020-01-21 13:18:32 +0100: Fetching vSAN disk info from ***********ins.com (may take a moment) ...

2020-01-21 13:18:32 +0100: Fetching vSAN disk info from ***********ins.com (may take a moment) ...

2020-01-21 13:18:32 +0100: Fetching vSAN disk info from ***********ins.com (may take a moment) ...

2020-01-21 13:18:32 +0100: Fetching vSAN disk info from ***********ins.com (may take a moment) ...

2020-01-21 13:18:32 +0100: Fetching vSAN disk info from ***********ins.com (may take a moment) ...

2020-01-21 13:18:35 +0100: Done fetching vSAN disk infos

DOM Object: aa50b95d-2a42-c2fb-1c85-b02628396580 (v7, owner: ***********ins.com, proxy owner: None, policy: SCSN = 10, hostFailuresToTolerate = 1, forceProvisioning = 0, CSN = 38, spbmProfileGenerationNumber = 0, stripeWidth = 1, spbmProfileId = aa6d5a82-1c88-45da-85d3-3d74b91a5bad, proportionalCapacity = 0, spbmProfileName = vSAN Default Storage Policy, cacheReservation = 0)

  RAID_1

    Component: 93b0ba5d-eaa7-64cb-592e-b026283972b0 (state: ACTIVE (5), host: 01***********ins.com, capacity: naa.55cd2e41500c17ca, cache: t10.NVMe____Dell_Express_Flash_PM1725a_800GB_SFF____5B02B081EA382500,

                                                     votes: 1, usage: 27.3 GB, proxy component: false)

    Component: aa50b95d-0cc1-e2fd-c7c0-b02628396580 (state: ACTIVE (5), host: 02***********ins.com, capacity: naa.55cd2e41500c1f64, cache: t10.NVMe____Dell_Express_Flash_PM1725a_800GB_SFF____2303B081EA382500,

                                                     votes: 1, usage: 27.3 GB, proxy component: false)

  Witness: aa50b95d-9462-e4fd-7d7f-b02628396580 (state: ACTIVE (5), host: ***vsan01********ins.com, capacity: mpx.vmhba1:C0:T4:L0, cache: mpx.vmhba1:C0:T2:L0,

                                                 votes: 1, usage: 0.0 GB, proxy component: false)

  Extended attributes:

    Address space: 107374182400B (100.00 GB)

    Object class: vdisk

    Object path: /vmfs/volumes/vsan:52c310f7d8df8750-33ad7e9fb030c8b8/a950b95d-8cfe-c57c-3f72-b02628396580/sd001thomas.vmdk

    Object capabilities: NONE

Regards, Andreas

Reply
0 Kudos
TheBobkin
Champion
Champion
Jump to solution

Hello Andreas,

It says it all there in the output:

It is a 100GB vmdk (e.g. max usage on datastore if the vmdk were full with FTT=1,FTM=RAID1 would be 200GB), currently it is using 27.3GB per replica (54.6GB total).

I would advise using the scripted method I pointed out above as opposed to going through every Object one at a time.

Alternatively, you can actually just copy the obj_status_report info, edit it and make a blob of UUIDs to check via RVC all at once e.g.:

> vsan.object_info <pathToCluster> 1318c15c-3450-6000-7d4d-b02628396580 ea95c65c-aac7-fe00-6e73-b02628396c80 a850ac5c-809d-ad01-9ad0-b02628397230 1505c45d-860e-1d07-66cb-b026283974d0

Bob

Reply
0 Kudos