SSH VMWare ESX(i) Disk Sensor error

Hello,

which exact version of PRTG are you running? Furthermore please enable the option "Write result to disk (Filename: "Result of Sensor [ID].txt")" in the Sensors Settings-tab and then check this logfile for further information.

best regards.

Hi,

We are using the 8.4.2.2381 of PRTG

We are using ESXi 40 & 4.1

The error is

~ # echo PAESSHSTART;df -P;echo PAESSHEN D PAESSHSTART df: invalid option -- P BusyBox v1.9.1-VMware-visor-klnext-2965 (2010-04-19 12:53:48 PDT) multi-call binary

Usage: df [-hmk] [FILESYSTEM...]

Print filesystem usage statistics

Options: -h Human readable (e.g. 1K 243M 2G) -m 1024*1024 blocks -k 1024 blocks

PAESSHEND ~ #

Busybox should be support with PRTG 9 (and onwards) in a few weeks. Please bear with us.

Hello!

I experienced the same error as Daniele. However, the error is arising under different cirumstances:

We're using PRTG 9.2.0.2176 and have 3 VM hosts configured. Sensors for one datastore on each host were running for some weeks already. Yesterday I installed vCenter Server, After that for 2 of the 3 hosts the sensor showed this error. SSH is still enabled, though the vCenter Server complaints about, and it is possibe to log in to the hosts.

The solution was simple in the end: When adding the hosts to vCenter server, the 2 out of 3 datastores has been renamed by vCenter Server software. It seems that all datastores in an datcenter has to have an unique name.

Maybe the PE094 was arising because the new name was "oldname (1)". I can imagine that the blank in the name was the reason for this error.

If you do not need historical data , simply delete sensor and create new sensor for renamed datastore.

I wanted to heep historical data, so solution for this case is as follows:

1) Check sensor ID of sensors with error 2) Rename datastores in vCenter to match your preferences 3) Shut down PRTG server and sensor service 4) Make backup copy of "PRTG Configuration.dat" in PRTG folder 5) Open "PRTG Configuration.dat" 6) Search for sensor with appropriate ID <sensor id="nnnn"> 7) Change values in <disk> and <diskid> tags to reflect new sensor names 8) Repeat steps 6-7 for addtl. sensors if necessary 9) Save file 10) StartPRTG services

Cheers Thomas

@PRTG team:

There is another solution for querying datastore of VMs for sure. Veeam Monitor dioes not need SSH enabled for datastore queries. Also it is using any internal ID, because, it did not have any problems with renaming of the datastores.

Additionally I experience short errors with the PRTG datastore sensors. It seems that next query is ok, I just see this when I'm in PRTG console at this time.

Is it planned to change VM datastore sensor to some more stable technique like Veeam is using?

Nevertheless, I like PRTG a lot, Regards, Thomas

Hello Thomas,

you are right, in a vCenter-environment with cluster-functionality enabled it is necessary to use the same datastorenames for all hosts. They can be renamed automatically if you are using host-profiles. This is necessary for high availability setups using vMotion. Unfortunately there is no easy way to rename the datastore in our sensor but your description is meant to work. Another way to keep historic data for a while is to pause the old sensor and add new sensors for the renamed datastores.

Yes, there are other ways to querying datastores, too. The most disadvantage of these ways is a long response-time respectively they are using much performance on both the requesting as the requested machine. The problem you are describing happens when the host or the datastore is on high load. ESX-Servers handle diskfree-requests with a low priority. Increasing the 'Shell Timeout' in the sensor settings from 5 seconds (default) up to 10 or 15 seconds fixes this problem in most cases. We are still working on it to find a high performing solution.

Kind regards

Hello everybody It seems that the problem still exist. In The past, i used nagios and had a sensor which used An url on the esxi that list the datastore, the size and the used or free space available. This is somethink "standard" / supported method. Kind regards. Vincent