During the current vSphere 5 upgrade that I’m going through I came across some behavior with Update Manager that I wanted to document and share.
Here’s the scenario: I’m using vCenter to manage multiple sets of hosts. One set is on the same subnet as vCenter and the other set is hanging off the DMZ burb on the firewall. Late last week I used Update Manager to upgrade the DMZ hosts from ESXi 4.1 to 5.0 and had no issues. Today I realized that I had not applied the two additional ESXi 5 patches. I thought “easy, let me just fire up Update Manager, run a scan for Patches and Extensions and then remediate.” So of course because I thought it was easy, it wasn’t.
I navigated to the DMZ cluster in vCenter and from the Update Manager tab I chose Scan… and chose Patches and Extensions. I immediately got an error
I honestly didn’t expect this error (or any other for that matter). I had successfully scanned this cluster for Host Upgrades and was able to perform remediation. So why am I now getting an error? A quick Google search didn’t result in much. One item I did find was on Jason Nash’s blog from 2009 (http://jasonnash.com/2009/10/21/esx-host-cant-download-patches-from-update-manager/) that talked about the target host being able to resolve the DNS name for the vCenter server. We don’t allow DNS traffic from the DMZ burb to the internal burb so I modified the hosts file (/etc/hosts) with the proper vCenter information. While I was able to successfully resolve the name, that still didn’t fix my problem.
Instead of looking at the Update Manager documentation I jumped into the logs on that particular host. I checked out the esxupdate.log file located at /var/log. Looking at the last few lines of the logs this is what I found:
I’ve blacked out some of the URL highlighted which was the IP of the vCenter server. See anything interesting? I’m sure you noticed, it’s using port 9084 to connect to the patch repository on the vCenter server.
Check out page 66 of the Installing and Administering VMware vSphere Update Manager guide. Here is the table from page 66
After I read the table above it became clear to me how I was able to scan for, and remediate Host Upgrades and not Patches and Extensions. From the table above you’ll see that Host Upgrades are pushed out over port 902. Why is port 902 open on my firewall you might ask? Port 902 is also used for management traffic between vCenter and an ESXi host, so naturally that port was already opened. Once I opened up port 9084 on my firewall I was able to scan and remediate for Patches and Extensions.
If you don’t have access to your firewall(s), just ask this guy and he’ll help you out!