Failed to Staging Patch

[horace_ng]

Update Manager is working fine for both VM and HOST remedating, however, staging won't work at all. Is there anyone encountering this problem?

error show in the host events of vsphere client:

Failed to stage patches on xxxx.host.xxxx

Staging failed for xxxx.host.xxxx

/var/log/vmware/upgrade.log is a all pass

/var/log/vmware/esxupdate.log is showing lots of patches and checking signature, but no error in it

then after the last entry in esxupdate.log, i found some timeout errors in /var/log/messages

' 131081 warning] Closing stream UNIX(/var/run/vmware/proxy-sdk) due to timeout

' 98311 warning] Closing stream UNIX(/var/run/vmware/proxy-sdk) due to timeout

I don't use any proxy server, anyone know what is happening on the staging?

[AndreTheGiant]

Check that you have free space on / and /var.

And also check that ESX firewall has outgoing port 80 enabled.

Andre

[horace_ng]

I have enough space on /var and I think vcenter will open the firewall port when it staging patch (I can see there is an log entry called 'open firewall ports')

[AndreTheGiant]

Have you configured VUM to use a proxy server?

Andre

[horace_ng]

I don't use any proxy server, and the ESX host can access to the patch store port directly.

[AndreTheGiant]

No other idea, sorry.

Andre

[mmi9567]

I ran into the same issue and it turned out that when my VUM server added certain patches to the repository, the host was getting a 404 error when attempting to stage the patches because the metadata.zip was referencing /VENDOR/metadata/long-name-of-patch-package.vib and the .vib file is in a different folder (/VENDOR/vibs/long-name-of-patch-package.vib).

To find out if this is the case, just attempt to open the URL of the patch in your favorite web browser (e.g. http://yourupdatemanagerserver:9084/vci/hostupdates/hostupdate/BCM/metadata/vmware-esx-drivers-net-bnx2-400.2.0.22f.v40.1-1vmw.2.17.00000.x86_64.vib if you added the NetXtreme II driver to your VUM server for distibution). In my case, the .vib file was put in a folder called vibs and the solution was to copy the .vib file from the vibs folder to the metadata folder along with the metadata.zip file.

UPDATE:

Check your update sources entry in your VUM database. The table is called VCI_TEXTFILES and it's the data in the TEXTFILE field.

Select * from VCI_TEXTFILES Where [KEYSTR] = 'integrity.SoftwareUpdateURL'

(I am not a SQL guy, so make sure you syntax check it)

You should get information similar to the following:

/_length = "7"

/_type = "integrity.SoftwareUpdateURL[]"

/e[0]/_type = "integrity.SoftwareUpdateURL"

/e[0]/description = "Download ESX 4x patches"

/e[0]/enabled = "true"

/e[0]/systemDefined = "true"

/e[0]/url = "https://hostupdate.vmware.com/software/VUM/PRODUCTION/index.xml"

/e[0]/urlType = "ESX4xHostPatches"

The first five (/e[0] - /e[4]) are system entries if you're running a version of VUM that patches guest OS and shouldn't have been modified.

Your custom entries start at /e[5] and might have invalid characters in the description (in my case I had a URL listed because I was using the description field to copy and paste the URL and description to my different VUM servers and hit OK). If you need to fix any entries, you will need to stop the update manager service affected and issue a SQL UPDATE statement, rewriting the entire entry in the process. If you aren't a SQL DBA, I would suggest you find yourself one so you don't do anything regrettable.

HTH

-Doug