When storage is severely overloaded, commands are aborted because the storage subsystem is taking too long to respond to the commands. The storage subsystem has not responded within an acceptable amount of time, as defined by the guest operating system. Aborted commands are a sign that the storage hardware is overloaded and unable to handle the requests in line with the host’s expectations.
The number of aborted commands can be monitored by using either vsphere client or esxtop.
- from vsphere client, monitor disk commands aborts
this one can be generated from host and clusters->Performance-> Advanced -> Switch to disk -> chart options-> commands aborted-> ok.
- from esxtop, monitor ABRTS/s
Open putty, login to the ESXi host, run esxtop, for the disk type u, type f to change the settings and type L to select Error stats. Press W to save it.
Once this is we can see the ABRTS/s field there which tracks the SCSI aborts, Aborts generally occur because the array takes long time to respond to commands.
Now if you are planning to deploy a monitoring tool to monitor this parameter, the threshold for ABRTS/s should be 1. This signifies number of SCSI commands aborted during the collection interval i.e. in 1 second.
DISK ABRTS/s 1 Aborts issued by guest(VM) because storage is not responding. For Windows VMs this happens after 60 seconds by default. Can be caused for instance when paths failed or array is not accepting any IO for whatever reason.
However having said that the in ideal case the output of ABRTS/s should be 0, which may sometime not been observer during peak hours i.e. Backup may be running on the servers hosted on the ESXi host resulting in disk intensive workouts. This ABRTS/s will fluctuate 0 to 0.xx in real case scenario as the storage is always overloaded during these peak hours.