ESX 3.5

I am testing Ubuntu Lucid Beta1 this week on our ESX 3.5 servers (managed by Vcenter 4.0). The VMware tools have been an issue forever, for various reasons:

• Ubuntu kernel upgrades render the binary VMware shipped modules unusable
• Official VMware tools lag behind

The open source open-vm-tools are good, and with the recent addition of the dkms system it is possible to recompile the modules on a abi-bumping kernel upgrade.

I managed to get a bare install by using the alternate ISO, then using F4 from the boot menu (install command line system). Finally found how to correctly install open-vm-tools on Lucid:

1. Install Lucid
2. apt-get dist-upgrade
3. reboot
4. apt-get install --no-install-recommends linux-headers-virtual open-vm-dkms open-vm-tools

The trick here is to use --no-install-recommends. The GUI tools are in the Recommends of the CLI tools (don't ask me), so installing the CLI tools with just apt-get install open-vm-tools will also pull down the X stuff.

Everything seems to work just fine:

ESX 4.0

I have recently upgraded reinstalled our ESX servers so they now run ESX4.0u1. This introduces new virtual hardware (v7 instead of v4), which the open-vm-tools can use. If you want to take advantage of the new features, remove the default NIC, then add a new one of type VMXNET3. Change the SCSI controller so the type is VMware Paravirtual. After installation of the OS, tools, headers etc as per above, your VM should now have loaded the appropriate modules:

However, at this stage VCenter will not say the tools are OK anymore, but instead are Unmanaged.
This might sounds like a bummer, but it appears to be a cosmetic issue and in fact the tools are OK.
Here is what my VM looks like in VCenter. You can see that the VM is using Thin Provisioning, so that despite the VM having an 18 GB disk, it uses less than 3 GB because it is still pristine.

ESX 4.1

After I upgraded my hosts to ESXi 4.1, and our VCenter to 4.1, my 64 bit Ubuntu Lucid VMs will die each night when VCB tries to snapshot them for backup
This is a real show stopper, and the Ubuntu provided open-vm-tools are more or less rendered useless by this issue. I already filed a bugreport.
I tried using the VMware provided Operating System Specific Packages (OSPs), which should be supported according to their web site.
Upon closer inspection it turns out that this is the same old crap like it was with 8.04 LTS: only the default and hence outdated/insecure kernel is supported. Even worse, manually recompiling the kernel modules like 8.04 does not even work anymore because of broken packages.
Which leaves me no other way that to go with the option that is the most work: the tar.gz installer. This does give the 'benefit' of being supported, i.e. the status is actually "OK" in VCenter.

I guess if I want to be up-to-date and safe, VMware leaves me no other way than to just use the tar.gz installer.

Current practice for Ubuntu Lucid & ESXi 4.1

After running Ubuntu Lucid for a 6 months, I can write down a couple of things about VMware & Lucid.
I have migrated reinstalled and installed 10 systems that run 64 bit Lucid now with 'virtual' flavor kernels. All of these VMs:

• are configured to auto-upgrade as much as possible. This is what their /etc/apt/apt.conf.d/50unattended-upgrades looks like:

  Unattended-Upgrade::Allowed-Origins {
          "Ubuntu lucid-security";
          "Ubuntu lucid-updates";
  };
  Unattended-Upgrade::Mail "sysadmin@terena.org";
  Unattended-Upgrade::Remove-Unused-Dependencies "true";
  Unattended-Upgrade::Automatic-Reboot "true";
  

• need manual installation of VMware tools after kernel upgrades that include API bumps. So far this has happened once per month on average. The tar.gz way is not the most efficient way, you can automate it quite a bit. The VMs should have the source unpacked in /usr/src/vmware-tools-distrib to start with. Now, if there is a kernel upgrade, the VMs will roll this upgrade, and reboot. When they come back online, they do not run the tools. At that point, it is only a matter of running this on the just-upgraded VMs:

  #!/bin/bash
  /usr/src/vmware-tools-distrib/vmware-install.pl --default
  apt-get autoremove
  

  You might need to manually rm -rf /lib/modules/2.6.32-old-version because those directories contain the VMware modules, and hence might not be removed by apt-get autoremove.
  The good thing is that the module installation can be initiated over the network. This used to kill your sessions because of replacing network modules, but that doesn't happen any more.