VMware Cloud Community
LessMe
Contributor
Contributor

Mount point free disk space

Hi,

We have an HPE Nimble/Alletra appliance which needs to update our ESXi hosts. This is a scripting-based process which access the hosts through SSH. When we run this update mechanism it fails when it tries to determine the amount of free space on the syslog global directory. We configured the setting to point to a folder in a VMFS datastore. Although this seems to work (there are logfiles present, including for the problematic host) we receive an error when trying to determine the free space on the mount point of this volume through CLI.

We use the commands:
- "esxcli system syslog config get" to verify the syslog global directory
- "cd ..." to navigate to this directory
- "df -h ./" to obtain the free space on the moint point of the directory

The error we receive is:

Unable to statvfs(./): 2
Filesystem Size Used Available Use% Mounted on

I've also added this output as a screenshot in attachment, compared to any other host which works just fine.

Do you have any idea what might be the cause of this?

 

Perhaps completely unrelated, but something else I've noticed:

I've used the command "esxcli software vib list" to list the installed VIBs and compare this between a host which passed the test and the problematic one. They are identical.

When I run the same command with switch "--rebooting-image" I get no output on the problematic one, but on the other host it gives me a list of the installed VIBs. Could that mean that the VIBs don't run automatically after a reboot on the faulty host? Could this mean anything?

Thanks in advance!

Kind regards

Reply
0 Kudos
1 Reply
Lalegre
Virtuoso
Virtuoso

@LessMe,

In order to confirm the space consumed on the log partition, you need to run like this:

df -h

The ./ will simply not work. Also, once you see the partition that is consuming space you can run the following:

du -h --max-depth=1 /DIRECTORY

You need to replace the /DIRECTORY with the directory with full space and keep changing the path until you find which one is the one consuming space. From there, if you identify the issue is on /storage/log/vmware there could be many solutions as there is a KB with solutions for different issues from different services.

Reply
0 Kudos