VMware: Taking two steps back for every step forward

Some of you may remember an earlier rant I went on about VMware support. I’m glad to say that it got resolved at the time, though not as smoothly as I could have hoped. Still, it got resolved, and I went on my happy way.

I’m sorry to report that VMware has failed me yet again – this time in a spectacularly embarrassing way for it’s engineering department. See, I’m at a new job, and the new job also uses VMware virtualization – fairly heavily. We’ve been running into some performance problems on the guest VMs related to either not having VMware-tools installed, or it being out of date. That is clearly our problem – and we started resolving it. By having to compile VMware tools manually, since for some reason the kernel we’re running (RHEL 5, 2.6.18-308.1.1.el5) doesn’t have precompiled modules. No biggie, it still works.

Well, compiling manually by running vmware-tools-config.pl on hundreds of boxes isn’t gonna fly, so I looked in to ways of compiling once and pushing out packages from our RHN Satellite. This is when VMware started to impress me. They have a new method of distibuting the vmware-tools package via YUM repositores. I found a treasure trove of RPMs at http://packages.vmware.com/tools, including a source RPM for the kmod package. Hallelujia! Oh frabjous day! My task has just been vastly simplified!

So I pulled down the source RPM for the kernel modules for the version of ESX we have and launched an “rpmbuild -bb”. The build failed. Wait, WHAT? Turns out that the source for the vmxnet and vmxnet3 modules have a conflicting definition for “struct napi_struct”. Some research led me to figure out that the kmod source for 4.0U2 was okay, since it had taken into account a port for GRO that Red Hat had done. I created diffs of those two trees, added the patches to the 4.0U1 build, and the package built. Okay, a little annoying, but understandable.

Now that I have a kernel module package, time to start pulling down all the other packages – for which, I should note, the source RPM is *not* available. So I pull them down one by one, starting with just the base “vmware-tools” package, doing a manual dependency resolution with wget and “rpm -qi –requires”. Well, I finally get to the “vmware-open-vm-tools-xorg-utilities” package, and it requires both xorg-x11-drv-vmware and xorg-x11-drv-vmmouse. Those are actually in the base RHEL channel.

This is where VMware failed utterly and completely. The binary RPM on their site, in the directory at http://packages.vmware.com/tools/esx/4.0u1/rhel5/x86_64, has version dependencies. Specifically, it depends on:

  • xorg-x11-drv-vmware >= 10.15.2.0
  • xorg-x11-drv-vmmouse >= 12.4.3.0

The versions of these packages available from Red Hat via RHN?

  • xorg-x11-drv-vmware           10.13.0-2
  • xorg-x11-drv-vmmouse        12.4.0-2

That’s right, the VMware packages for RHEL 5, as provided by VMware, require a version of Red Hat packages that doesn’t exist! What’s worse is the xorg-x11-drv-vmmouse packages doesn’t seem to exist for RHEL 6, so I can’t even try to back-port the RHEL 6 packages to RHEL 5. Which means that the past 3 hours of work in trying to generate local packages to install VMware Tools and not have to do so manually was wasted because VMware’s build system for their vmware-tools package is fundamentally broken. Did nobody at VMware bother to do any quality checking to ensure these packages can be installed? Does anybody from VMware realize just how idiotic the entire VMware organization looks to me right now?

EDIT: I’ve now found the two packages that provide the xorg-x11-drv-vmmouse and xorg-x11-drv-vmware versions required. They’re in the VMware download folder, but they have “vmware-open-vm-tools-xorg” type names. Not really too smart there, VMware… either use the same name as upstream, or require a different package name please. Don’t muddy things up like that. You look a lot less idiotic now, but you still look idiotic.

Comments are closed.