vCenter Update Manager – A Feature Request

Way back in August 24 2010 I wrote a post called vCenter Update Manager to lose it’s fat. I’m still very happy that VMware has decided to drop OS patching from the product, and I still mean that can only be a good thing. In fact, that article prompted Beth Pariseau Senior News Writer for to call me when researching her VMware users eye changes to Update Manager article.

I would like to expand a bit on the following quote from the article:

Centralized management is fine, Mohn said, but he’d like to see satellite servers hang on to a local repository of patches, which can then be applied with a command from the central server …

As I work with small ROBO environments, which in many cases have low bandwidth available coupled with very high latency, using VMware Update Manager to update the sites is often not feasible. The sheer problem with installing the patches from a central HQ based repository, and the time it consumes and potential failure rates, makes it more practical to download the patches manually to a local vMA installation (possibly even replicated with rsync) and applying the patches to the host from a local repository. This also minimizes the hosts downtime when applying patches.

What I would like to see added to VMware Update Manager is the ability to tell a remote host to apply patches, but from a local file repository.

Using vMA for this is absolutely possible, but I can also see using local (to the host) NAS storage as the patch repository as another possibility. By using some DNS magic, it would even be possible to tell all remote vSphere hosts to fetch their updates from \\patchrepo\vmware\ (or something similar) and it would still be a local repository.

VMware Update Manager could even handle the replication of the patches to the remote sites, but in general I’m in favor of using the existing underlying network infrastructure that’s already in place to move the patches from a central location to the remote locations.

So, in short, all I’m asking is for a way to tell a central VMware Update Manager installation where the patches for a remote server is, and invoke the patching process from the central installation. Surely, that can’t be too much to ask for, can it?


  1. Hey Christian,

    Great article. It’s interesting to see how you solve this problem.

    As I have no true knowledge of the environments you work in, I have a couple of questions:

    – Wouldn’t it be possible to make a central repository and a let the local vMA decide what is needed to download. In other words, isn’t it possible to let vMA (or Rsync) decide the bandwith available. On the central repository you can make make several download folders seperated to available bandwith. Then make a script on the local vMA (Rsync) that checks bandwith and then download only the really needed downloads (and not everything).
    – How many times does a ship go into harbor (what is their time at see) and wouldn’t it be possible to use the time in harbor to update the fast majority of downloads (one way or the other)?

    But your already into vMA and rsync and your questions are more then valid. My question is, looking at VUM and it’s lack of some features, isn’t it a better idea to build a script that does all these things for you? But I don’t think your question towards VUM is too much to ask :-P

    Have a great easter weekend ;-)

  2. @Arjan: Of course, my usage of vMA and rsync can be refined with several scripts and several levels of replication based on available bandwidth.

    As far as doing it while in port, that doesn’t help all that much in my environment, as the bandwidth available is generally the same. Some vessels might have better bandwidth while being close to shore, but the majority of our vessels have the same VSAT connection regardless of location. In general though, bandwidth isn’t a major concern, at least not a big a concern as latency is.

    VUM patches “over the air”, and latency/dropped packets is not desirable in that case. If we had a way of telling VUM which (local) repository it should use, for a particular host, I could always replicate the patches over a number of days for that matter.

    I like scripting, but as VMware vSphere hosts pop up in several remote locations, being able to handle this kind of scenario without having to create your own solution would be a nice addition to VUM.

  3. Latency is a mean [email protected]#$^ And I’m totally agreeing with you it should be build in VUM by VMware….
    While that’s not the case, you’ll have to deal with your problem in another way. And then scripting is the most appealing way (I guess).
    You are already three steps ahaed of me in solving the problem, but I will keep an eye out for some sort of solution ;-)

Leave a Reply