Remediate this host…

You’re going to update my what?

With the release of ESX 3.5 and VirtualCenter Server 2.5, VMware also released Update Manager. Update Manager is a neat concept…download Windows, windows programs (e.g. firefox, adobe reader, etc), RHEL, and ESX (3.5 only) updates to the update host, then let VirtualCenter Server apply the updates. I can see where the ESX updates would be valuable, however I think any IT department big enough to support a large number of Windows VMs is already going to have a method of deploying updates (i.e., SMS, or whatever you windows admins use). Same for linux shops. So those updates, in my opinion, aren’t as valuable to the enterprise. I do see where small-to-medium businesses, especially those with a very small IT department, would want the advantage of having updates deployed to all VMs via a product they’ve already purchased (ESX) rather than having to buy another MS product (SMS, etc).

ESX is different however. Previously, there was no VMware product (to my knowledge) that allowed for automated update of the ESX hosts. There were some fantastic utilities that were published by the community, but there was no VMware product.

Well, that has changed. Once the Update Manager is installed, you simply tell it to update it’s database and download the updates.

Or is it so simple… What if you are not connected to the internet? What if you are on an isolated network? Well, VMware has what’s called the Update Manager Download Service.

In a nutshell, UMDS is installed to a computer that has (high-speed) internet access and does the download portion, but doesn’t do any of the other management. Once the updates are downloaded, you export them to portable media (CD-R / USB drive) and move them to your Update Manager server (presumably your VirtualCenter Server). After importing, you can push updates to ESX hosts and/or windows/linux hosts.

Installaltion
Installing UMDS is somewhat trivial. Simply insert your VirtualCenter Server install CD, browse to find hte “VMware-UMDS.exe” file, and execute it. It will walk you through the steps like every other windows installer. If you have a SQL server available, you can use it, or just use SQL Server Express, which it will install to the local machine for you.

A note here. When installing VMware’s windows based products to XP Pro, I’ve consistently encountered an error where the MSI installer will fail saying something to the effect of “options are incorrect”. The fix is to append /V"/le install.log" to the executable. In other words, open a command prompt, browse to the location of the installer, then execute it with the above afterward:

Downloading

Once you get through all of the installer options and get the thing installed, it’s time to execute the update download process. We have a large windows shop and they are kind of touchy about what updates get applied to what programs and when, so I let them worry about their updates. Our nonexistent linux admin shop (with the exception of myself and another admin, everyone else is all Solaris) decided to use our own update process as well. To prevent UMDS from downloading 10+ GB (yes, that’s GIGABYTES) of windows updates (to be fair there are other windows based apps updates in there as well), and 1.5-2 GB of linux updates, we want to disable them. From the command prompt:

It’s a good idea to do this at the end of the day and let it run overnight. Especially if you elect to download windows updates. Once it’s done, go back to the command line to export the updates to your portable media:

vmware-umds -E --dest e:updates

There are a couple of options that I’m not using here. After the initial export you will want to specify a start date using the -s option:

vmware-umds -E --dest e:updates -s 2008-07-20T08:00:00

This will export any updates that were downloaded after 0800 July 20, 2008. Notice I said downloaded…not released. You can also use an end time with the -e option, using the same date format. Just remember, the start and end date pertain to the dates that you downloaded updates, not the dates that the respective updates were released.

Configuration

Once they are exported (I’m assuming e: is a usb key, external hard drive, or some such), move them to your Update Manager server. Go to the command line there, and execute the following:

C:Program FilesVMwareInfrastructureUpdate Managervmware-updateDownloadCli.exe --update-path e:updates --config-import esx --vc-user vc_user_name

In the folder structure that was exported from the internet connected host is a metadata update file. It’s an xml file that contains the information UM needs to determine what updates get applied to what, what action needs to be taken on the host (e.g., nothing, reboot, services restarted, etc), and some other info. It will read the file, determine which updates it doesn’t have (if it isn’t the first time you’ve imported updates), and begin to update the database.

Note that the files are copied into the folder you selected during the install of Update Manager to contain all the updates. The default is in the “Documents and SettingsAll Users” directory. If you copy the “updates” directory off your removable media and onto your server (or a network share), you can delete it after the import.

Remediation

Once the import is done, the updates are available to Update Manager. If you haven’t already installed the Update Manager plugin to your Virtual Infrastructure Client, do so now and enable it. There should be a new tab for each host and compatible VM for Update Manager. There should also be a new option in the top menu bar. Click that option, and you should be able to create baselines.

Baselines are exactly that – they are a set of updates that a host is expected to have. Create a baseline, give it a name, select some updates for it (or just chose “Dynamic” and “All updates”), then begin applying it to hosts.

After a baseline has been attached to a host, you can then scan it for updates (right click the host in Virtual Infrastructure Client, select “Scan for updates”), after which it will tell you how many updates are available, how many have been applied, and how many need to be applied. If updates need to be applied, right click the host, and select remediate. If it’s an ESX host, you should ensure that all active VMs have been evacuated, and put the host in maintenance mode first.

Ta Da!!

That should be it. It’ll do it’s thing and update whatever you’ve told it to update.

The Update Manager is quite easy to use, and for ESX hosts, does exactly what it says it will. I’ve never used it with anything else, so I can’t comment on it.

Afterward

One quirk that I have encountered with the UMDS host (that’s the internet connected one) is that if you need to export all updates for reimport (if for example, you reloaded the VirtualCenter Server and “started fresh”) it will not export the metadata for updates that have been exported previously. I had to go and remove the records from the database (not the records for the updates, but that they had been exported). I don’t remember which table it was (I’m not at that box now), but when I am able to, I will post it.

1 thought on “Remediate this host…”

  1. It’s too bad that Update Manager is unable to integrate with WSUS. Personaly I would love to pass of the OS/Product patching to UM. Experience tells me that it wouldn’t last long… Some SQL server would get SP2, or .net 3.5, and boom back to WSUS.

    I do love that VMware provided the tool though. In today’s world of zero day attacks. Patch levels aren’t a nicety they are a necessity. Given SVMotion and VMotion there are no good reasons not to patch your hosts.

    Reply

Leave a Reply