VMware Update Manager: Fix for “Scanning virtual appliance”

Today had to solve a problem with my vSphere’s Update Manager (affectionately known as the “vUM”). The vUM’s job is to download patches from the VMware site and figure out which hosts / appliances / VMs need to be updated. In my case, this process failed due to the vUM getting stuck at “Scanning virtual appliance”…forever. Read on to see how to fix this in a true vCloud environment!

First, the error shows itself within the vCenter Server as a task named “Download patch definitions” where the Status is “Scanning virtual appliance”. Within the server running the vUM, you can see the problem in action by opening the vUM log file (C:\ProgramData\VMware\VMware Update Manager\Logs on a Windows Server 2008 R2 box). The below is an example:

2013-06-05T10:16:29.791-04:00 [09064 info 'Default'] [serviceWin32,506] VMware vSphere Update Manager Service service started
2013-06-05T10:18:29.947-04:00 [08964 error 'Default'] SSLStreamImpl::BIORead (03303238) timed out
2013-06-05T10:18:29.947-04:00 [08964 error 'Default'] SSLStreamImpl::DoClientHandshake (03303238) SSL_connect failed with BIO Error
2013-06-05T10:18:29.947-04:00 [08964 error 'HttpConnectionPool-000000'] [ConnectComplete] Connect failed to ; cnx: (null), error: class Vmacore::Ssl::SSLHandshakeTimeoutException(SSL Exception: The SSL handshake timed out local: 172.24.4.66:49595 peer: 172.24.12.3:5489.)

The above lines are quite misleading…one might quite naturally start with a search for SSLStreamImpl::BIORead timed out and you would find numerous matches. For example, the very first match is a VMware entry Alarms about the host connection state changing from green to red frequently occur which – while not exactly our error message – is pretty close. Close enough so that you would be perfectly excused for going down the garden path.

Too bad that it isn’t even close to the problem where the VMware Update Manager can’t complete its download task! Which will lead you (eventually) to a couple of posts that give you the solution, namely:

• “download patch definitions scanning virtual appliance” from the VMware communities; and,
• “Download Patch Definitions In Progress” which is a more concise take on the problem.

Reading those articles helps to solve the problem, but not specifically if you are running VMware vFabric Application Director. In fact, the issue can show up for any installed VMware “appliance” in your vSphere environment; this includes the things like the vSphere Storage Appliance, or the vSphere Management Assistant, and numerous others.

The issue turns out to be really ridiculous: For any installed virtual appliance (“vApp”), you must make sure that the “vApp Options” are properly set…even though these settings seem to be kind of meaningless.

Let’s start with the vSphere Management Assistant (vMA). In the vSphere Web Client, use the “Edit Settings” and then click the “vApp Options” tab. Then set the “Product URL” and the “Vendor URL” both to http://www.vmware.com as shown in the picture below:

While we’re at it, let’s do another problematic entry one from my setup: the vSphere vFabric Application Director. This one was even more ridiculous: not only must you set the “Product URL” to http://www.vmware.com as with the vMA, you must also fill in the “Application URL” with the specially-formatted value http://${vami.ip0.VMware_vFabric_Application_Director}/. (That encoding references the configured runtime IP address from the virtual appliance.) See the following shot:

On the bright side…once you’ve made these changes and restarted your (failed) vSphere Update Manager service, the patch downloads succeed.

Ah…the sweet smell of Vic-tor-y! (Sung to the tune of your choice.)

The moral of the story? Any time you import a virtual appliance into your vSphere environment, be sure to check and fill in all of the product information fields. And – if you are unsure what to put there – spend the time to figure it out. Because otherwise your updates will just refuse to work.

Happy computing…