Using HPs vibdeposit with VMware Update Manager

As we’re finally at the point, where I only need to bother with HP hardware (which in itself is troublesome enough), I wanted to use HPs vibdeposit with our Update Manager. The whole purpose of the repository is the integration of HPs custom vibs (download able on each hardware under VMware ESXi 5.0) into the VMware Update Manager. That makes it easy to integrate, say the nmi-sourcing driver, into the VMware built ESXi images.

So basically what you do is, add the VIB repository to your vCenter Update Manager download list, and then create a dynamic baseline for everything “Hewlett-Packard” and attach that to the desired level of your environment (I did it at the root level, as I only have Hewlett-Packard). But I’ll show you.

First, visit your Update Manager (you’ll find it under Solutions > Update Manager). We need to update the Configuration of Update Manager in two places. First under “Configuration“, the second is under “Baseline and Groups“. But lets start with “Configuration“, since you can’t add something to a baseline that isn’t there.

Now, you want to add a new Update source:

The URL for that repository is After that is done, you can click on “Apply” and “Download Now” to add the packages to your local software repository. After this, the VIB’s from HP just need to be applied to a set of hosts.

Now, we’re going to “Baseline and groups“.

As I mentioned before, we need to create the baseline, otherwise you can’t apply the VIBs to your hosts. So we create a new Baseline named “HP Update Bundles” only containing updates/patches labeled “Host Patch”.

Next we want to select the baseline type. Based on your requirements you may either select Fixed or Dynamic. Since I don’t want to update the baseline each time HP releases a new VIB, I chose “Dynamic”. Keep in mind if you select Fixed, you need to select the VIB’s in the dialog window.

But since I selected Dynamic, I just need to apply a filter criteria in this next dialog, telling the baseline to select only VIB’s originating from the vendor “Hewlett-Packard Company”.

You may also exclude specific patches from this baseline using this following dialog, which I decided not to do. Next we need to switch to a set of hosts (for me, it is the root level of the vCenter as I only operate HP hosts). So navigate to the desired folder, cluster, host and select the “Update Manager” tab on the upper right.

Simply click on “Attach” and a new dialog opens from which you can select the newly created Baseline.

After this the baseline is attached to the selected folder and when you Scan/Update your hosts, this baseline is being pulled in also and applied.

Empty Port SSL after ADAM installation

I’ve been meaning to post this, but never actually got around to doing that. When installing vCenter 5.0, an instance of ADAM is installed, which stores all the configration data for Linked Mode.

It basically boils down to running this script and rebooting the box:

This is no new invention of myself, just writing it down for myself from here or here.

Create an offline snapshot of a VM

We’re currently thinking about automating Windows Updates and the involved disaster snapshot-copy to a degree, where we don’t need to intervene anymore.

Right now, we already have a rudimentary scheduler in place, which does the reboots for some (200 ..) systems already. Now, we’d like to extend it to also cover the bi-weekly Windows Update spree.

Since PowerShell (and PowerCLI) work quite well with vSphere automation, I cooked up the below script to first shutdown a virtual machine (for snapshot consistency reasons), then take a snapshot and power on the virtual machine again afterwards.

Using the integrated kickstart generator

VMware built an kickstart generator into ESX 3.5. You just need to enable it, simply by editing an XML configuration and restarting the webAccess service. Simply edit /usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.26/webapps/ui/WEB-INF/struts-config.xml and look for the line saying:

This line needs to be commented out (<– and –>) and the lines following, having those comment marks around them needs to be removed.

After doing that, you should be able to restart the webAccess service, and after that access your ESX host.

If that worked, you should see the Login to Script Installer link on the Dashboard of the Web interface.

VI Client: Changing the language from the system default

Well, as I am in fact running a german Windows XP, the VI Client started displaying all menus and operations in German when I updated to 2.5u2. Normally, I wouldn’t have much of a problem with that, but recently it started to annoy me, since the translation is a bit off from the real meaning of much of the operations.

So today, in the morning I started looking for ways to revert the VI Client back to displaying everything in English. And guess what. There’s no way to switch the language from the VI Client itself. There’s just a workaround.

Simply rename the folder in “%ProgramFiles%VMwareInfrastructureVirtual Infrastructure Client2.5“, %ProgramFiles%VMwareInfrastructureVIUpdate” “%ProgramFiles%VMwareInfrastructureVirtual Infrastructure ClientPluginsConverter Enterprise 4.0.2” and “%ProgramFiles%VMwareInfrastructureVirtual Infrastructure ClientPluginsUpdate Manager 1.0 Update3” named “de” to something else. Tada, your VI Client is back in English.

More VirtualCenter troubles (fini)

Well, today the support request came back. Seems one of the originally linked VMTN dicussions really is the only way:

  1. Export the customization specification
  2. Edit the XML file
  3. Import it again

The related part inside the customization specification should then look like this:

So if you ever think about switching the default VirtualCenter certificate (for whatever reason), make sure you use the above workaround. Otherwise VirtualCenter is gonna fail miserably during the customization phase of the cloning process.

More VirtualCenter troubles

Well, after my co-worker switched the VirtualCenter certificates with one produced by our RA a few days ago, I can’t clone anything using a customization specification anymore.

Unable to decrypt passwords in customization specification
Unable to decrypt passwords in customization specification

Guess, we’re shit outa luck. At least both of those linked VMTN discussions don’t contain any (that is for us) workable solution (well besides storing the password in cleartext in the spec — which ain’t sooo good). Gonna bug him tomorrow to open up a VMware support request, maybe that’ll help somewhat. I sure hope so.

Yet another VMware error

Today I was moving a pretty standard SLES10 virtual machine to another host, when the migration dialog showed me this:


And if you now think, the virtual machine is something special take a look at those settings:

Virtual machine configuration
Virtual machine configuration

I don’t know what to think about that error message. Googling for it doesn’t reveal that much about it. If anyone out there got an idea, I’m open for suggestions.

Extending VMotion compatiblity (continued)

Remember my last post about cpu masking ? Well, turns out that you can do it to a “template”.

The only point you don’t need to do, is to mark the VM as a “template“. You still can clone it and move it around and all that other stuff, but the good part is, that the cloned VM keeps the cpu mask set to the “template*shrug*

I don’t know, why VMware didn’t include that feature into the templates, since it’s a real freaky way to do.

Extending vMotion compatiblity

Today I did something horrible. I yet again noticed that I bought the wrong CPU’s (basically I bought Xeon DP’s with four cores). Those have apparently a feature called SSSE3, which makes vMotion with our old Xeon DP’s (dual cores) fail before even trying.

But as we had a cooling outage today (basically ’cause it broke), I needed to turn off some ESX servers. Thus leaving me with the new ones and one of the old ones. *yuck*

So after a bit of googling, I found this VMware KB entry, which luckily lists the registers (on level 1) you need to zero out.

Only problem after that was that it still wasn’t enough. So back to the drawing board. The final solution came rather quick and looks like this:

The only stupid thing about this is, that

  1. it ain’t supported by VMware (as in if you’re having trouble with your ESX/VC and you have a VM running with this, you’re shit outta luck!)
  2. you have to define this on a *per VM basis*, which really is a pain in the ass for larger installations

True, I just should’ve bought vMotion compatible CPU’s, that would have spared me the hassle … but it’s too late now, I have to live with those ones.