VCSA 7.0U2 disk (VMDK) numbering mismatch

[mschenker]

We have a 70,4% warning on the /storage/log partition in our VCSA 7.0U2 (7.0.2.00400)

The disk "number" is shown as "8" with com.vmware.appliance.version1.resources.storage.stats.list

.

8:
Name: /storage/log
Usedkbytes: 7273468
Totalkbytes: 12311688
Usedinodes: 107805
Totalinodes: 786432

But disk 8 under the VCSA VMs is NOT the 12 GB drive I'd expect... that's disk 5!! Is there a way to align that? I erroneously increased the 25 GB disk "8" to 30 GB in the first place, then found out that /storage/log should be disk 5 and increased that from 10 GB to 12 GB...  like https://kb.vmware.com/s/article/78515 states.

How do we align the output from both queries? Just "aiming" based on disk size or the table given by VMware seems a bit off...

Best, Martin

[Ajay1988]

The KB is fine to me >> https://kb.vmware.com/s/article/78515

VMDK5

10GB

/storage/log

Use https://kb.vmware.com/s/article/2145603 and command "df -h; lsblk; lsscsi" for better details . 

[mschenker]

This is the KB I followed.

My /storage/log disk show up as No. 8 (as shown above!!) 

Care to explain?!

[Ajay1988 · Accepted solution]

com.vmware.appliance.version1.resources.storage.stats.list >> This will just fetch storage statistics for each logical disk and doesn't match to the SCSI-ID/VMDK numbering.

Use the below command to verify which disk is experiencing disk capacity issues, then trace which SCSI ID will show in the VM edit settings:
df -h; lsblk; lsscsi

sde 8:64 0 25G 0 disk
└─log_vg-log 254:11 0 25G 0 lvm /storage/log

[2:0:4:0] disk VMware Virtual disk 1.0 /dev/sde
You can see the the device name, and 4 numbers a:b:c:d
a = Hostadapter ID
b = SCSI channel
c = Device ID
d = LUN

I don't see always a reason to do the above. Just do a df -h and get which mount you want to increase.
/dev/mapper/log_vg-log 25G 5.8G 18G 25% /storage/log

VMDK5  > Hard disk 5 >> /storage/log

[mschenker]

Thanks for the explanation. In the KB the disk number is shown correctly so I believed this is part of the query.

If that's not the case, a change in the KB would be good.