Get Only ESXi 4 Updates in VUM 4

One of the (many) things that bugs me about VMware Update Manager is the fact that I can’t specify to only pull down ESXi updates. I doubt there are many large enterprises that will run both fat and thin ESX in production for any length of time, I know I wouldn’t. And sure it’s “only” metadata if I never actually scan an ESX host, but it pollutes the VUM interface with millions of entries for fat ESX that I will never care about. So maybe I’m a little bit OCD about stuff like that, but there you go. Luckily I can do something about it though, via the use of a custom patch source and a little XML hacking.

And I do use the term “hacking” veeeery loosely here, as modifying a bit of clear text XML and hosting it on a web server is something my grandmother could probably do.

To see this in action, I’ve put the necessary files in place right here on vinternals.com. Simply add a custom patch source with a URL of https://vinternals.files.wordpress.com/2010/01/vum-clean1.pngesxi/index.xml (if you don’t know how, follow the instructions for adding the Cisco Nexus patch source):

… you will end up with a patch repository on a clean VUM 4 server like this:

Nice and clean :). Now I’m not actually hosting anything more than a couple of XML files on this site (https://vinternals.files.wordpress.com/2010/01/vum-clean1.pngesxi/index.xml and https://vinternals.files.wordpress.com/2010/01/vum-clean1.pngesxi/ftw/esxi-index.xml) – the actual metadata file and patches themselves are all hosted securely by VMware. But still, not even I would point my production servers here, this is just a little experiment. Should you wish to follow my lead and host these files on a webserver internal to your environment however… well, surely there wouldn’t be any problem with that 😉

UPDATE D’oh! Looks like you also need to host the patch binaries in the same subdirectory as the secondary XML file, in this example https://vinternals.files.wordpress.com/2010/01/vum-clean1.pngesxi/ftw/. The metadata zip file only contains relative paths to the patch binaries, not fully qualified ones. It seems that it constructs the fully qualified path to the patch binaries using the custom patch repository URL value in the UI or something. So if you wanted to do this internally, you’d have to ensure you mirrored the patch binaries as well.

I’ve put in a request to VMware to enable this functionality themselves. Given the triviality of implementation, hopefully they will but who knows!