Update Signature VMware Update Manager

[mattinator]

I have a scheduled task to "Update Signature" that was started by the VMware Update Manager and it has been in a Queued state since 2AM this morning. I upgraded my ESX 3.0.2 Update 1 servers to ESX 3.5 last night. Any idea how to remedy the Update Signature task? Thanks.

[mattinator]

I uninstalled the VMware update manager software from VirtualCenter server, rebooted and the problem has been remedied.

[LiamGP]

Did you re-install update manager after this?

[mattinator]

No, but its on my list of things to do.

[Schorschi]

We can not get Update Manager to sync and download from VMware website no matter what we try, with or without proxy (in DMZ), nothing we try works.

[Sbeard333]

To get Update manager to sync its updates you will have to change the 'VMWare update manager' service to start with a valid domain account which has internet access

[Schorschi]

Well, after uninstalling Update Manager and reinstalling it, it appeared the issue disappeared, that the Download via the Update Manager GUI in VC was working, but on explicit review, it did not work. No need for a domain account with internet access, since in the initial test since it was in front of our proxy. The only conclusion is that Update Manager appears flakey.

Given other security issues, we have decided to use the stand-alone repository model, but after several tests, we have found also that vmware-updatedownloadcli.exe import method is also flakey. We opened an SR with VMware and are awaiting their response on the issue. When vmware-updatedownloadcli.exe import does fail, we get the following...

C:\Program Files\VMware\Infrastructure\Update Manager>vmware-updatedownloadcli --update-path d:\ --config-import esx --vc-user administrator

Please type in password for user <administrator>:

Connecting to VMware Update Manager Service to import updates

INFO - Successfully connected to Integrity.VcIntegrity

INFO - Get configure file information successfully

INFO - Set configure file information successfully

INFO - Waiting for a task to complete...

INFO - Update state: running

INFO - Update Progress: 50%

INFO - Update state: running

INFO - Update Progress: 100%

INFO - Update state: running

INFO - Update state: running

INFO - Update state: running

INFO - Update state: running

INFO - Update state: error

INFO - Download/Import task failed.

For detailed information, please refer to Virtual Infrastruture Client.

C:\Program Files\VMware\Infrastructure\Update Manager>

And of course, the Update Manager patch location has no patches imported, in fact nothing happened but the creation of a folder called 'hostupdate' which is empty. OH! And what the heck.... what is "Virtual Infrastruture Client" Geez, VMware is your QA process broken? Any serious QA? Last time we checked it is spelled "Infrastructure" no?

[atc]

I had this same problem too so I've gaven up the export/import and went back to the old way of patching ESX. Based on the error in VI Client, it appears that even though we're importing from a local path, it still tries to contact the website and failing since VC can't get out to the Internet. Did you hear back from tech support regarding this?

[mattinator]

I ended up sticking with old faithful and I upload the updates using WinSCP and then run esxupdate from a local repository.

[Schorschi]

Get this.... I missed this in the documentation for Update Manager... The only way you can do an import, is if you do an explicit export using UMDS. UMDS must be used, and can not be installed on the VirtualCenter server with VMware Update Manager. This is nuts. A very signficant limitation for importing.

We want to download the updates, test them with esxupdate, in a lab, on a few representative host servers, and when we feel the updates are safe, we then and only then import them to all our VirtualCenter servers as imported local process, no use of the VirtualCenter downloads from the website.

VMware support has identified this as a gap, based on how we want to do this, meaning we never what to download from the web as an automated batch process. VMware has established a feature request to allow import of individual updates without having to use UMDS and an explicit export.

I don't fault VMware design for Update Manager in the sense that what they did is easy to use, but once again, VMware does not think like an enterprise or large scale environment concept or even a significant corporate infrastrucutre? I am surprised again and again that VMware is still designing for the small customer, at least it appears that way. Does anyone believe that Citrix Xen or Microsoft will focus on anything but the enterprise customer?

[Sbeard333]

>> Schorschi

I understand this limitation and agree it would be nice to be able to import designated/tested updates.

Myself i will be testing my patches and pushing these tested patches out using update manager by way of a fixed host baseline. I understand this means all host patches have to be pulled down from the web so i can select the ones i wish to apply but still feel this is better than updating all hosts one by one.

[atc]

Nay...that's not it. I followed their step-by-step instruction on page 16 of the UM Administration Guide and still could not import the patches. The Download Service was installed on my XP pro workstation and exported fine. It's the last step during the import that I received the same error above.

[Schorschi]

Post your directory structure of the export? Just to see if you and I have the same output from the export task?

[atc]

I did get it to work. The problem was after the export command, there were 3 directories (i.e., hostupdate, metadata, vm-patch-binaries) created in the export depot directory (c:\export-depot) but on step 5, I only copied the hostupdate directory to the UM machine. Once I copy the whole c:\export-depot directory to the UM machine and running the import command specifying d:\export-depot as the update-path instead of d:\ as stated, the esx patches imported just fine.

I think VMware should've documented that clearer.

Update:

Another confusion, all the Jan. 17, 2008 patches have the date of 2007124xx-?G.zip in their names so you think that they are 12/4/2007 patches but if you run the export command specifying date range for 2007, nothing was exported. You would have to specify date range for 2008.

[Vduster]

Hello there...

could someone perhaps give us "the big picture", i.e. an overview about how the data flows from where to where when doing this offline updating:

- vmware-umds export moves the patches from directory <A ... or what, if it can't reach the Internet ?> to directory <B> ( and does what else ? )

- vmware-umds import moves the patches fom directory <B> to directory <C> ( and does what else ? )

- the VIC snap-in VMware-Update takes the patches from directory <C>

... something like this.

many thanks!

Burkhard