vCenter Hangs on Compliance Checks at 55% When Scanning ESXi Hosts

Products

VMware vCenter Server

Issue/Introduction

When initiating a Lifecycle Manager compliance check or scanning ESXi hosts from VMware vCenter Server, the progress task hangs indefinitely at 55% and fails to complete.

Environment

VMware ESXi: 8.0 Update 3 (8.0u3)

VMware vCenter Server: 8.x

Log Location / Scratch Partition: Configured on an external NFS share

Cause

The failure occurs because the ESXi host is unable to read or write to its local database/log files due to continuous disk I/O errors on the configured scratch partition (/scratch). When the scratch location is configured on a remote NFS share experiencing intermittent connectivity, locking, or latency issues, SQLite operations fail with sqlite3.OperationalError: disk I/O error when updating host task progress.

Log location: /var/run/log/lifecycle.log

2026-10-09T07:38:59Z Er(11) lifecycle[11688147] Scanner:906 Failed to compute addon compliance for the host: disk I/O error
2026-10-09T07:38:59Z Er(11) lifecycle[11688147] Scanner:907 Traceback (most recent call last):
2026-10-09T07:38:59Z Er(11)[+] lifecycle[11688147]   File "/tmp/esx-update-1688147/lib64/python3.11/site-packages/vmware/esximage/ImageManager/Scanner.py", line 3426, in scan
2026-10-09T07:38:59Z Er(11)[+] lifecycle[11688147]     self.task.setProgress(self.task.progress + progressStep)
2026-10-09T07:38:59Z Er(11)[+] lifecycle[11688147]   File "/lib64/python3.11/site-packages/lifecycle/task.py", line 198, in setProgress
2026-10-09T07:38:59Z Er(11)[+] lifecycle[11688147] sqlite3.OperationalError: disk I/O error
2026-10-09T07:38:59Z In(14) lifecycle[11688147] runcommand:248 runcommand called with: args = '/bin/localcli system visorfs ramdisk remove -t /tmp/esx-update-1688147', outfile = None, returnoutput = True, timeout = 0.0.
2026-10-09T07:38:59Z In(14) lifecycle[11688147] Ramdisk:243 Unmounting manual tardisk /tardisks.noauto/loadesx-1688147
2026-10-09T07:38:59Z In(14) lifecycle[11688147] Ramdisk:243 Unmounting manual tardisk /tardisks.noauto/esxupdt-1688147
2026-10-09T07:38:59Z In(14) lifecycle[11688147] Ramdisk:243 Unmounting manual tardisk /tardisks.noauto/tpmesxup-1688147
2026-10-09T07:38:59Z In(14) lifecycle[11688147] Ramdisk:243 Unmounting manual tardisk /tardisks.noauto/weaselin-1688147
2026-10-09T07:38:59Z Er(11) lifecycle[11688147] imagemanagerctl:85 [OperationalError]
2026-10-09T07:38:59Z Er(11)[+] lifecycle[11688147] disk I/O error 

Resolution

To restore host scan functionality, change the ESXi host's scratch location (ScratchConfig.ConfiguredScratchLocation) back to a reliable local datastore and reboot the host.

1.Reconfigure Scratch Location to Local Storage:vSphere Client or CLI.

In the vSphere Client, navigate to Host > Configure > Advanced System Settings. Edit ScratchConfig.ConfiguredScratchLocation to point to a folder on a valid local VMFS datastore (e.g., /vmfs/volumes/Local-Datastore/.locker-ESXHostName).

Verification: Ensure the newly specified directory exists on the local datastore.

2.Reboot the ESXi Host:Maintenance Mode required.

Place the affected ESXi host into Maintenance Mode and perform a host reboot to apply the new scratch partition settings.

Verification: Once booted, run vim-cmd hostsvc/advopt/view ScratchConfig.CurrentScratchLocation via SSH to confirm the active scratch path matches the local datastore path.

3.Re-run Compliance Scan:vSphere Lifecycle Manager.

Navigate back to vSphere Lifecycle Manager in vCenter and trigger a new Check Compliance scan on the affected host.

Verification: The scan task successfully completes past 55% and reports the correct host compliance status without I/O errors.

Additional Information

NFS Scratch Partition Risks: Redirecting ScratchConfig to NFS datastores can cause locking issues, file descriptor timeouts, or dropped I/O operations under load. This prevents ESXi system components from performing basic file updates.

Investigating NFS Root Causes: Because NFS network/storage drops occur externally, local ESXi host logs may not reflect the full underlying issue while using the NFS path. Troubleshooting network latency, export permissions, and storage controller performance on the NFS array side is required if NFS logging must be maintained.

Best Practice: Keep ESXi scratch partitions on local SSDs, direct-attached storage (DAS), or high-reliability SAN VMFS datastores rather than shared NFS mounts.