Troubleshooting

SRM Plugin Down? How to Generate Diagnostic Logs via the Command Line | Lazy Admin Blog

Posted on Updated on

In a high-pressure recovery situation, the last thing you want to see is the “SRM Connection Failed” error in your vSphere Client. If you can’t access the SRM interface to click “Gather Logs,” you have to go straight to the source.

Site Recovery Manager includes a standalone support script that packages all necessary diagnostics directly from the Windows Server filesystem, even if the SRM service itself is struggling.

Step 1: Locate the Support Script

Log into the Windows Server where SRM is installed and navigate to the \bin\ directory. The path varies slightly depending on your version and OS architecture:

  • 64-bit Windows (Standard): C:\Program Files\VMware\VMware vCenter Site Recovery Manager\bin\
  • 32-bit Windows (Legacy): C:\Program Files (32 bit)\VMware\VMware vCenter Site Recovery Manager\bin\
  • SRM 1.0 (Vintage): C:\Program Files\VMware\VMware Site Recovery Manager\bin\

Step 2: Generate the Bundle

  1. Look for the file named srm-support.wsf.
  2. Double-click the file to execute it.
  3. Wait a few moments. A compressed log bundle will appear on the Desktop of the current user, named in this format: srm-plugin-support-MM-DD-YYYY-hh-mm.zip.

Step 3: Label Your Logs (The “Pro” Tip)

VMware Support will often need logs from both the Protected and Recovery sites. Because the log bundles look identical, VMware highly recommends renaming the files before uploading them to the FTP portal:

  • protected-srm-support-MM-DD-YYYY.zip
  • recovery-srm-support-MM-DD-YYYY.zip

Don’t Forget the SRA Logs!

If your issue involves storage replication, VMware will also need the Storage Replication Adapter (SRA) logs. These are usually tucked away in vendor-specific folders:

  • ...\VMware vCenter Site Recovery Manager\scripts\SAN\<SRA Vendor Name>\log\
  • C:\Program Files\<SRA Vendor Name>\

Manual Configuration Check

If you need to verify your extension ID or database connection strings manually, you can find the core XML configuration files in the \config\ directory:

  • extension.xml
  • vmware-dr.xml

This entry was posted in VMware and tagged , , , , , , , , , .

Locked Out of Cisco UCS? How to Recover the Master Admin Password | Lazy Admin Blog

Posted on Updated on

It’s the nightmare scenario: you need to make a critical service profile change, but the only admin password is lost or forgotten. Because Cisco UCS Manager doesn’t store passwords in a reversible format, you can’t “view” the old one. Instead, you must perform a password reset by power-cycling the Fabric Interconnects (FIs) and interrupting the boot sequence.

⚠️ Warning: This procedure requires a physical power cycle of the Fabric Interconnects. In a production environment, this will cause a temporary disruption in management connectivity and potentially data traffic if not handled correctly in a cluster.

Phase 1: The Pre-Flight Check

Before you pull the power cables, you need two pieces of information. If you still have read-only access or a lower-privilege account, gather these now:

  1. Identify the Roles: In a cluster, you must know which FI is Primary and which is Subordinate.
    • Path: Equipment > Fabric Interconnects > [FI Name] > General > High Availability Details.
  2. Verify Firmware Versions: You must know the exact Kernel and System firmware versions currently running.
    • Path: Equipment > Firmware Management > Installed Firmware.

Phase 2: Password Recovery (The Process)

Scenario A: Standalone Configuration

If you only have one Fabric Interconnect, the process is straightforward but requires downtime.

  1. Connect: Attach a console cable physically to the FI console port.
  2. Power Cycle: Turn the FI off and then back on.
  3. Interrupt Boot: As it boots, repeatedly press Ctrl+L or Ctrl+Shift+R until you see the loader > prompt.
  4. Boot Kernel: Load the kickstart/kernel image: loader > boot /installables/switch/ucs-6100-k9-kickstart.x.x.x.gbin
  5. Enter Config: Fabric(boot)# config terminal
  6. Reset Password: Fabric(boot)(config)# admin-password YourNewPassword123
  7. Load System: Exit config mode and boot the system image: Fabric(boot)# load /installables/switch/ucs-6100-k9-system.x.x.x.bin

Scenario B: Cluster Configuration (High Availability)

In a cluster, the order of operations is vital to ensure the database remains synchronized.

  1. Subordinate First: Power cycle the Subordinate FI and interrupt its boot to the loader > prompt. Leave it there.
  2. Primary Second: Power cycle the Primary FI and interrupt its boot to the loader > prompt.
  3. Reset on Primary: Follow the “Standalone” steps (4 through 7) on the Primary FI console.
  4. Bring up Subordinate: Once the Primary is back up and you can log into UCS Manager, go to the Subordinate console and boot its kernel and system images normally from the loader prompt.

Important Notes

  • Clear Text: When you type the admin-password command in the boot loader, the password displays in clear text on the screen. Ensure no one is shoulder-surfing!
  • Strong Passwords: UCS Manager requires at least one capital letter and one number.
  • Console Access: This cannot be done via SSH. You must have physical or terminal server access to the console port.

#CiscoUCS #DataCenter #CiscoProphet #SysAdmin #Networking #ITTech #Cisco #UCSManager #LazyAdmin #Infrastructure

This entry was posted in Cisco UCS and tagged , , , , , , , , .

vSphere Ports & Connections: The Infrastructure Roadmap | Lazy Admin Blog

Posted on Updated on

In a locked-down enterprise environment, the “Any-to-Any” firewall rule is a myth. To manage ESXi effectively, you need to poke specific holes in your hardware and software firewalls.

The Core Management Ports

These are the “must-haves” for basic connectivity between vCenter, the vSphere Client, and the Host.

PortProtocolSourceDestinationPurpose
443TCPManagement WorkstationvCenter / ESXivSphere Client / SDK: The primary port for the Web Client and API access.
902TCP/UDPvCenter ServerESXi HostvCenter Agent (vpxa): vCenter uses this to send data to the host and receive heartbeats.
902TCPManagement WorkstationESXi HostVM Console: Required to open the “Remote Console” (MKS) to a virtual machine.
80TCPvCenter / WorkstationESXi HostHTTP: Used for redirecting to 443 and for some legacy file downloads.

Advanced Feature Ports

If you are using specific vSphere features like vMotion, HA, or specialized storage, you need these additional ports open:

1. vMotion (Live Migration)

  • 8000 (TCP): Required for vMotion traffic.
  • 2049 (TCP/UDP): If using NFS storage for the virtual disks.

2. vSphere High Availability (HA)

  • 8182 (TCP/UDP): Used by the Fault Domain Manager (FDM) agent for inter-host communication and election of the master host.

3. Provisioning & Deployment

  • 69 (UDP): TFTP, used for PXE booting ESXi for Auto Deploy.
  • 4012 (TCP): Used by the Auto Deploy service.

4. Troubleshooting & Monitoring

  • 22 (TCP): SSH access to the ESXi Shell.
  • 161 / 162 (UDP): SNMP polling and traps for hardware monitoring.

Troubleshooting “Host Disconnected”

If your host shows as “Not Responding” in vCenter, check these three things in order:

  1. Ping: Can the vCenter server ping the ESXi management IP?
  2. Port 902: From the vCenter server, try to telnet to the host on port 902 (telnet <host-ip> 902). If it fails, the heartbeat can’t get through.
  3. DNS: VMware is extremely sensitive to DNS. Ensure forward and reverse lookups work for both the vCenter and the Host.

Lazy Admin Tip 💡

Don’t memorize every port! Use the VMware Ports and Protocols Tool (the official online matrix). It allows you to select your source and destination products and generates a custom firewall rule list for you.

A high resolution pdf can be downloaded here Connections and Ports in ESX and ESXi

#VMware #vSphere #Networking #SysAdmin #Firewall #DataCenter #ESXi #ITOps #LazyAdmin #Connectivity

This entry was posted in VMware and tagged , , , , , , , , , .

Emergency Log Collection: Generating and Uploading ESXi Support Bundles | Lazy Admin Blog

Posted on Updated on

If you can’t generate a support bundle through vCenter, your best bet is the ESXi Shell. By running vm-support directly on the host, you bypass the management overhead and get your diagnostics faster.

Step 1: Generate Logs via SSH (CLI)

Before running the command, identify a datastore with at least 5-10GB of free space to store the compressed bundle.

  1. SSH into your ESXi host using Putty.
  2. Navigate to your chosen datastore: cd /vmfs/volumes/YOUR_DATASTORE_NAME/
  3. Run the support command and redirect the output to a specific file name:Bashvm-support -s > vm-support-HostName-$(date +%Y%m%d).tgz
    • -s stands for “stream,” directing the output to the file you specified.
    • Tip: Using $(date +%Y%m%d) automatically adds the current date to the filename.
  4. Once finished, use the vSphere Datastore Browser to download the .tgz file to your local workstation.

Step 2: Uploading to VMware via FileZilla

VMware provides a public FTP/SFTP landing zone for Support Requests (SR). While many admins use the browser, a dedicated client like FileZilla is much more reliable for large multi-gigabyte bundles.

Configure FileZilla for VMware

  1. Set Transfer Mode: Go to Transfer > Transfer type > Binary. This prevents file corruption during the upload.
  2. Open Site Manager: (File > Site Manager) and create a new site:
    • Host: ftpsite.vmware.com
    • Protocol: FTP (or SFTP if requested by support)
    • Logon Type: Normal
    • User: inbound
    • Password: inbound

Navigating the Remote Site

  1. Connect to the server.
  2. Create your SR Folder: In the “Remote Site” pane, right-click and select Create Directory. Name it exactly after your 10-digit Support Request number (e.g., 2612345678).
  3. Upload: Locate your .tgz bundle in the left pane (Local Site), right-click it, and select Upload.

Important Note: For security, the VMware FTP is “blind.” You will not see your files or folders once they are created/uploaded. Don’t panic if the directory looks empty after the transfer completes; as long as the transfer queue shows 100%, VMware has it.

#VMware #ESXi #Troubleshooting #SysAdmin #DataCenter #Virtualization #ITOps #FileZilla #LazyAdmin #TechTips

This entry was posted in VMware and tagged , , , , , , , , , .

Nuclear Option: How to Force Power Off a Hung VM via SSH | Lazy Admin Blog

Posted on Updated on

We’ve all been there: a Windows Update goes sideways or a database lock freezes a guest OS, and suddenly the “Shut Down Guest” command is greyed out or simply times out. When the GUI fails you, the ESXi Command Line (esxcli) is your best friend.

Step 1: Identify the “World ID”

In ESXi terminology, every running process is assigned a World ID. To kill a VM, you first need to find this unique identifier.

  1. SSH into your ESXi host using Putty.
  2. Run the following command to see all active VM processes:Bashesxcli vm process list
  3. Locate your hung VM in the list. Look for the World ID (a long string of numbers). You will also see the Display Name and the path to the .vmx file to confirm you have the right one.

Step 2: Execute the Kill Command

ESXi offers three levels of “force” to stop a process. It is best practice to try them in order:

  1. Soft: The most graceful. It attempts to give the guest OS a chance to shut down cleanly.
  2. Hard: Equivalent to pulling the power cable. Immediate cessation of the VMX process.
  3. Force: The “last resort.” Use this only if ‘Hard’ fails to clear the process from the kernel.

The Syntax:

Bash

esxcli vm process kill --type=[soft,hard,force] --world-id=WorldNumber

Example (Hard Kill): esxcli vm process kill -t hard -w 5241852

Step 3: Verify the Result

After running the kill command, it may take a few seconds for the host to clean up the memory registration. Run the list command again to ensure it’s gone:

Bash

esxcli vm process list | grep "Your_VM_Name"

If the command returns nothing, the VM is officially offline, and you can attempt to power it back on via the vSphere Client.

Lazy Admin Tip 💡

If esxcli still won’t kill the VM, the process might be stuck in an “I/O Wait” state (usually due to a failed storage path). In that rare case, you might actually need to restart the Management Agents (services.sh restart) or, in extreme cases, reboot the entire host.

#VMware #vSphere #ESXi #SysAdmin #Troubleshooting #Virtualization #ITOps #LazyAdmin #ServerManagement #DataCenter

This entry was posted in VMware and tagged , , , , , , , , , .

Fixing Server Manager Error 0x800706BE: The Missing MUM/CAT Mystery | Lazy Admin Blog

Posted on Updated on

If your Server Manager is blank, showing a yellow bang, or refusing to refresh with a “Remote Procedure Call Failed” error, you aren’t looking at a network issue—you’re looking at a corrupted Windows Update store.

When Windows cannot validate the files in the C:\Windows\Servicing\Packages directory, the Server Manager discovery process crashes. Here is how to perform manual surgery on the CBS store to fix it.

The Symptom

  • Error Code: 0x800706BE
  • Event ID: 1601 (Microsoft-Windows-ServerManager/Operational)
  • Message: Could not discover the state of the system.

Step 1: The Diagnostics (CheckSUR)

First, we need to know exactly which files are broken.

  1. Download and run the System Update Readiness Tool (CheckSUR) (KB947821) or, on newer versions of Windows Server, run: DISM.exe /Online /Cleanup-image /Scanhealth
  2. Once finished, open the log file: %Systemroot%\Logs\CBS\Checksur.log
  3. Look for lines starting with (f) CBS MUM Corrupt or (f) CBS MUM Missing. These are your “targets.”

Step 2: Gain Control of the Packages Folder

By default, even an Administrator cannot write to the Servicing folder. You must take ownership:

DOS

takeown /F C:\Windows\Servicing\Packages /D y /R
icacls C:\Windows\Servicing\Packages /save %temp%\AclFile /T
icacls C:\Windows\Servicing\Packages /grant %username%:F /T

Step 3: Extract and Replace the “Grafts”

Now you need to “borrow” healthy files from the original Update files to replace your corrupt ones.

  1. Download the KB: Download the .msu file for the KB number listed as corrupt in your log.
  2. Expand the MSU: expand -F:* Windows6.1-KB978601-x64.msu C:\Repair
  3. Expand the CAB: Inside that folder, find the .cab file and expand it too: expand -F:* Windows6.1-KB978601-x64.cab C:\Repair\CAB
  4. The Extraction: Inside the CAB folder, find update.mum and update.cat.

Step 4: The Rename and Replace

This is where precision matters. You must rename those generic files to match the exact long string found in your Checksur.log.

  • Example Rename:
    • From: update.mum
    • To: Package_for_KB978601~31bf3856ad364e35~amd64~~6.0.1.0.mum
  • Move: Copy these renamed files into C:\Windows\Servicing\Packages.

Step 5: Verify the Fix

Close and reopen Server Manager. It should now trigger a fresh discovery without the RPC error. If it still fails, check the Checksur.log again—you likely have more missing packages to replace!

Lazy Admin Tip 💡

If you have another server running the exact same OS and patch level, you can often just copy the healthy .mum and .cat files from the “Good” server’s C:\Windows\Servicing\Packages folder to the “Bad” one. It’s much faster than manually expanding CAB files!

#WindowsServer #SysAdmin #ServerManager #Troubleshooting #ITOps #Microsoft #TechSupport #LazyAdmin #WindowsUpdate

This entry was posted in Windows and tagged , , , , , , , , .

HPE ProLiant Diagnostics: How to Generate a Survey Log (Online & Offline) | Lazy Admin Blog

Posted on Updated on

An HPE Survey Log provides a deep-dive look at your server’s hardware configuration, firmware levels, and error counts. Depending on whether your OS is healthy or the server is “down,” you have two ways to get this data.

Method 1: The Offline Approach (Non-Booting Servers)

Use this method if the OS is corrupted or you need to test the hardware in a “clean” state using the SmartStart CD (Gen8 and older) or Service Pack for ProLiant (SPP).

  1. Boot the server using the SmartStart CD or SPP ISO.
  2. Navigate: From the homepage, click Maintenance > HP Insight Diagnostics.
  3. Default View: The Survey tab will open by default.
  4. The “Pro” Settings: * Change Category from ‘Overview’ to ‘All’.
    • Change View Level from ‘Summary’ to ‘Advanced’.
  5. Save: Click Save. Note that you will need a USB flash drive plugged in to export the .html or .txt log file.

Method 2: The Online Approach (Live Production)

If the server is running Windows or Linux, you can pull the logs without a reboot by using the HP Insight Diagnostics Online Edition.

For Windows Admins:

  • Via Start Menu: Go to Start > All Programs > HP System Tools > HP Insight Diagnostics.
  • Via Web Browser: Open the HP System Management Homepage (SMH), click Webapps, and select HP Insight Diagnostics.

For Linux Admins:

  1. Open your browser and navigate to: https://localhost:2381
  2. Log in with root credentials.
  3. Click Webapps > HP Insight Diagnostics.

Exporting the Online Log:

Once the interface opens, follow the same “Advanced” steps:

  1. Set Category to ‘All’.
  2. Set View Level to ‘Advanced’.
  3. Click Save to download the file directly to your workstation.

How to Install Online Diagnostics (If Missing)

If the tool isn’t installed, you’ll need the HPE Service Pack for ProLiant (SPP):

  1. Mount the SPP ISO.
  2. Navigate to /hp/swpackages and run hpsum.exe (Windows) or ./hpsum (Linux).
  3. Select Localhost as the target and ensure HP Insight Diagnostics Online Edition is checked for installation.

Lazy Admin Tip 💡

For modern Gen9, Gen10, and Gen11 servers, you can bypass these tools entirely by using the iLO (Integrated Lights-Out). Simply log into the iLO web interface and download the Active Health System (AHS) log. It’s the modern replacement for the Survey log and is much faster to collect!

#HPE #ProLiant #ServerAdmin #SysAdmin #ITOps #HardwareTroubleshooting #iLO #DataCenter #LazyAdmin #TechTips

This entry was posted in HP Enterprise Servers, Windows and tagged , , , , , , , , , .

RDP Rescue: How to Fix Remote Desktop Issues Without a Reboot | Lazy Admin Blog

Posted on Updated on

If you can reach a server via ping or the VM console but RDP is failing, you can often “kick-start” the service by toggling specific registry keys. This forces the Terminal Services stack to re-read its configuration without dropping the entire OS.

1. The Firewall Check

Before diving into the registry, ensure the Windows Firewall isn’t blocking Port 3389. If you have console access, try disabling it temporarily to rule it out.

  • Quick Command: netsh advfirewall set allprofiles state off

2. The “Deny” Toggle (The Most Common Fix)

Sometimes the registry says RDP is allowed, but the service isn’t honoring it. Toggling the value can reset the listener.

Path: HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server

  • fDenyTSConnection: Should be 0. (If it’s already 0, change it to 1, refresh, then back to 0).
  • fAllowToGetHelp: Should be 0 to ensure Remote Assistance isn’t conflicting.

3. WinStation Listeners (RDP & Citrix)

If the main switch is on but the specific “listener” is disabled, you’ll get a “Connection Refused” error.

For Standard RDP: Path: HKLM\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp

  • fEnableWinStation: Must be 1. Toggle this (1 -> 0 -> 1) to reset the listener.

For Citrix Servers (ICA): Path: HKLM\System\CurrentControlSet\Control\TerminalServer\WinStations\ICA-Tcp

  • fEnableWinStation: Must be 1.

4. Port Verification

Ensure the server is actually listening on the standard port. If someone changed the RDP port for “security,” your connection will fail.

Path: HKLM\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp

  • PortNumber: Should be 3389 (Decimal).

Test it from your workstation: tnc <ServerIP> -port 3389 (PowerShell) or telnet <ServerIP> 3389

5. The Winlogon Block

In rare cases, the entire Winlogon station for terminal services is disabled at the software level.

Path: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

  • WinStationsDisabled: Must be 0. If set to 1, no one can log in via RDP regardless of other settings.

Lazy Admin Tip 💡

If you can’t get to the console, you can change these registry keys remotely from your workstation! Open Regedit, go to File > Connect Network Registry, and enter the target server’s name. You can perform all the toggles mentioned above without ever leaving your desk.

#WindowsServer #RDP #SysAdmin #Troubleshooting #ITOps #TechTips #Networking #RemoteDesktop #LazyAdmin #ServerManagement

This entry was posted in Windows and tagged , , , , , , , , , .

Troubleshooting VMware Tools Upgrade Failures on Windows Server 2003 | Lazy Admin Blog

Posted on Updated on

In the world of legacy infrastructure, Windows Server 2003 virtual machines (VMs) occasionally hit a “brick wall” during VMware Tools upgrades. While VMware continues to investigate the root cause, the community has identified a manual “scrubbing” process to bypass the installer errors and force a clean installation.

🛑 Pre-Requisites & Data Collection

Before performing a manual registry cleanup, VMware Support recommends gathering the following data to help identify the underlying issue:

  1. Version Mapping: Note the current “from” version and the target “to” version.
  2. Upgrade Method: Are you using the “Interactive” installer, “Silent” switches, or vCenter’s “Automatic” update?
  3. Historical Data: Open the Windows Event Viewer, search for Event Source: MsiInstaller, and look for Event ID: 1034 to find traces of previous installation attempts.

🛠️ The Fix: Manual Registry & System Scrubbing

[!CAUTION] Warning: This procedure involves modifying the Windows Registry. Incorrect changes can destabilize your OS. Always take a full VM Snapshot and a Registry Backup before proceeding.

1. Registry Cleanup (Installer Keys)

Log in as an Administrator, open regedit, and navigate to/delete the following keys if they exist:

  • HKEY_CLASSES_ROOT\Installer\Features\05014B32081E884E91FB41199E24004
  • HKEY_CLASSES_ROOT\Installer\Products\05014B32081E884E91FB41199E24004
  • HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Features\05014B32081E884E91FB41199E24004
  • HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\05014B32081E884E91FB41199E24004
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\B150AC107B12D11A9DD0006794C4E25
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{3B410500-1802-488E-9EF1-4B11992E0440}
  • HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.

2. Service Removal

Deep-seated services can block the new installer. Delete these keys under CurrentControlSet\Services:

  • VMTools
  • VMUpgradeHelper
  • VMware Physical Disk Helper Service
  • vmvss

3. File System Cleanup

Once the registry is clear, you must remove the physical binary remnants:

  1. Open Windows Explorer.
  2. Delete the folder: %ProgramFiles%\VMware\VMware Tools.
  3. Restart the Virtual Machine. This step is non-negotiable as it clears the memory and releases hooks on drivers.

🚀 Final Step: Fresh Installation

After the reboot, the system will be “clean” of previous VMware Tools traces. You can now mount the VMware Tools ISO through your vSphere client and run a fresh installation.

Pro-Tip: If the VM has other VMware products installed (like vCenter Server), do not do a blanket search-and-destroy for the term “VMware” in the registry. Stick strictly to the keys listed above to avoid breaking other applications.

This entry was posted in VMware and tagged , , , , , , , , , , , .

Monitoring Disk Command Aborts on ESXi: Identifying Storage Overload | Lazy Admin Blog

Posted on Updated on

When your storage subsystem is severely overloaded, it cannot process commands within the acceptable timeframe defined by the Guest Operating System. The result? Disk Command Aborts. For Windows VMs, this usually triggers after 60 seconds of silence from the storage array.

Aborted commands are a critical red flag indicating that your storage hardware is overwhelmed and unable to meet the host’s performance expectations. Monitoring this parameter is essential for proactive datacenter management.

Here is how you can track these aborts using two primary methods: the vSphere Client and esxtop.

💻 Method 1: vSphere Client (Graphical Interface)

This method provides a visual, historical look at command aborts across your infrastructure.

  1. Navigate to Hosts and Clusters.
  2. Select the object you want to monitor (Host or Cluster).
  3. Click on the Monitor tab, then Performance, and select Advanced.
  4. Click Chart Options.
  5. Switch the metric grouping to Disk.
  6. Select Commands aborted from the list of measurements.
  7. Click OK.

🛠️ Method 2: esxtop (Command Line Interface)

For real-time, granular troubleshooting, esxtop is the definitive tool. It monitors the ABRTS/s (Aborts per Second) field, specifically tracking SCSI aborts.

Steps to Configure esxtop for Aborts:

  1. Open Putty and log in to your ESXi host via SSH.
  2. Type esxtop and press Enter.
  3. Type u to switch to the Disk Device view.
  4. Type f to change the field settings.
  5. Type L to select Error stats.
  6. Press Enter, then press W to save these settings for future sessions.

You will now see the ABRTS/s column. This number represents the SCSI commands aborted by the guest VM during the 1-second collection interval.

📈 Thresholds and Interpretation

If you are deploying a monitoring tool, the critical threshold for ABRTS/s is 1. A value of 1 or higher means SCSI commands are actively being aborted by the guest OS because the storage is not responding.

What is Ideal?

In an ideal scenario, ABRTS/s should always be 0.

What is Real-World?

In a busy production environment, you may see this value fluctuate between 0 and 0.xx. This occurs during “peak hours”—for instance, when multiple servers on the host are running disk-intensive backup operations simultaneously, leading to temporary storage saturation. However, any consistent spike above 1 requires immediate investigation into path failures, array congestion, or complete storage unresponsiveness.

This entry was posted in VMware and tagged , , , , , , , , , , , .