...
ESX
...
3.5
...
I
...
am
...
testing
...
...
...
...
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
...
...
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:
...
- Install
...
- Lucid
apt-get
...
dist-upgrade
...
- reboot
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.
| Operating | VCenter | Distro provided |
|---|---|---|---|
Works with stock kernel | | | |
Works with updated kernel | | | |
Administration burden | | | |
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:
...
Code Block perl perl 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:
...
Code Block perl perl #!/bin/bash /usr/src/vmware-tools-distrib/vmware-install.pl --default apt-get autoremove
...
You might need to manuallyrm -rf /lib/modules/2.6.32-old-versionbecause those directories contain the VMware modules, and hence might not be removed byapt-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.