Error "Host cannot download files from VMware vSphere Lifecycle Manager patch store. Image not found." during a compliance check or image staging operation
search cancel

Error "Host cannot download files from VMware vSphere Lifecycle Manager patch store. Image not found." during a compliance check or image staging operation

book

Article ID: 439017

calendar_today

Updated On:

Products

VMware vCenter Server 8.0 VMware vSphere ESXi 8.0

Issue/Introduction

In a VMware vCenter 8.0.# environment, the following issues occur during ESXi host lifecycle operations:

  • Compliance scans or staging tasks fail across a large number of hosts (e.g., 15+).
  • The vmware-updatemgr service crashes and may fail to restart automatically.
  • The vSphere Client reports errors such as:
Host cannot download files from VMware vSphere Lifecycle Manager patch store.
Image not found.
  • Staging tasks initiated via PowerCLI scripts in batches frequently trigger service instability.

Cause

The vmware-updatemgr service failure is often triggered by underlying ESXi host storage issue rather than a vCenter defect, ESXi hosts booting from non-recommended devices (e.g., USB or SD cards) may experience local storage disconnects or file system corruption, causing the bootbank symlink to break.

Resolution

To identify and isolate the problematic hosts causing the service to crash, perform the following steps:

1. Check update manager service Status.

  • Log in to the vCenter Server Appliance (VCSA) via SSH and check the service status: service-control --status vmware-updatemgr

2. Identify failing hosts in vCenter logs.

  • Navigate to the update manager log directory: cd /var/log/vmware/vmware-updatemgr/vum-server
  • Search for specific error code 30, which indicates a transaction failure on the host: less vmware-vum-server.log | grep -A2 -i "Unrecognized esxupdate errorNo: 30"
  • For older logs, use: zcat vmware-vum-server-###.log.gz | grep -A2 -i "Unrecognized esxupdate errorNo: 30"

Note: ### represents the log rotation number.

3. Verify ESXi host bootbank health, on any host identified in the previous step, log in via SSH into the ESXi host and check the integrity of the bootbank: ls -lrtha

  • The healthy bootbank symlink appears in cyan/light blue.
  • The broken/corrupt symlink appears in red bold, indicating the target storage device is inaccessible.

4. Remediation.

  • Isolate problematic hosts and remove those hosts with broken bootbanks from the staging/patching list until their hardware or storage connectivity issues are resolved.