Until two years or so ago I used VMware Workstation intensively for development and testing of Debian Installer, using one of the licenses generously made available to the D-I team by VMware. It was much faster than Qemu and thus very welcome.

But due to increasing problems keeping it working with new kernels on a desktop system running unstable, I switched to VirtualBox (the OSE version), which has the huge advantage of being packaged for Debian and thus automatically follows the Debian kernel packages.

That advantage has disappeared somewhat as I'm currently compiling my own kernels — I'm currently running 2.6.33 on a Lenny desktop. So far I've been able without too much trouble to find patches for the VirtualBox modules to keep them compatible with new upstream kernels.

This week I had reason to try VMware again. The Server edition this time as that has free licenses. The Server concept, where you connect to the management system and virtual machines via a web browser, is quite nice. It means I could install it on a server and keep my laptop nice and responsive.

To keep VMware separate from the rest of the system and not mix it with software installed cleanly from Debian packages, I decided to install it in /opt. And that works beautifully. There are only a few bits installed in /etc, but that's OK. I have /etc managed by etckeeper anyway [1].

More challenging was building WMware modules to match my kernel. VMware wants you to run their vmware-config.pl script every time you switch kernels and build the kernel modules on the system where it runs (which requires the kernel headers). I wanted to build the modules as part of my kernel build process, on a totally different machine. The same as I already do for VirtualBox. I save the custom modules in a tarball that has the same uname and package version as the kernel package I build and have a simple script that installs them correctly.

I succeeded by hacking the Makefiles (deleting most of their content) and then integrating them in my kernel build wrapper script.

The module source provided by VMware built fine with a Debian 2.6.26 kernel, but not with the 2.6.32.9 kernel on my server (of course). But luckily others had already run into the same problems and solved them, so with some searching I found the required patches (first a full updated source for 2.6.29, then patches needed for .31 and for .32). Isn't open source just wonderful?

So with that the VMware server started beautifully (well, the init script needed to be told that module names have changed from *.o to *.ko), but I could not connect to it from my laptop using SSL. Connecting without SSL (using an instance of iceweasel running on the server but started remotely from my laptop using X forwarding SSH) worked fine. That turned out to be a known issue too. After applying all the suggested workarounds in my iceweasel configuration (disable TLS 1.0; set cache size to zero; explicitly disable use of proxy for the server) I can now connect reliably to the VMware Server management system.

Phew.

[1] I had to exclude a fair number of VMware files for etckeeper as they are updated by VMware itself and thus really belong in /var. Example are DCHP status files...